docs: fix broken link

.lycheeignore

@@ -14,4 +14,9 @@ https://www.tensorflow.org/
 https://www.nssctf.cn
 https://cdn.xyxsw.site
 https://vidar-team.feishu.cn/
-https://ctf.tj.cn/
+https://ctf.tj.cn/
+https://arena3-chapter0-fundamentals.streamlit.app/
+https://waytoagi.feishu.cn/
+https://copy-suppression.streamlit.app/
+https://datawhaler.feishu.cn/
+https://ryluo.oss-cn-chengdu.aliyuncs.com/

2023旧版内容/4.人工智能/4.10LLMAgent之结构化输出.md

@@ -187,13 +187,17 @@ program(description="A quick and nimble fighter.", valid_weapons=valid_weapons)
 ### lmql
 
 在 guidance 的基础上，lmql 这个项目进一步把“prompt 模板”这个概念推进到了一种新的编程语言。从官网能看到给出的一系列示例。语法结构看起来有点像 SQL，但函数与缩进都是 Python 的风格。
-![](https://marlene-1254110372.cos.ap-shanghai.myqcloud.com/blog/%7B92E71406-7249-4345-894C-AC646F47D05A%7D.png)
+
+此处本应有图片，但图床过期，暂无图片
+
 从支持的功能来看，相比 guidance 毫不逊色。例如各种限制条件，代码调用，各种 caching 加速，工具集成等基本都具备。这个框架的格式化输出是其次，其各种可控的输出及语言本身或许更值得关注。
 
 ### TypeChat
 
 TypeChat 将 prompt 工程替换为 schema 工程：无需编写非结构化的自然语言 prompt 来描述所需输出的格式，而是编写 TS 类型定义。TypeChat 可以帮助 LLM 以 JSON 的形式响应，并且响应结果非常合理：例如用户要求将这句话「我可以要一份蓝莓松饼和一杯特级拿铁咖啡吗？」转化成 JSON 格式，TypeChat 响应结果如下：
-![](https://marlene-1254110372.cos.ap-shanghai.myqcloud.com/blog/%7BECFBBC78-BFE8-45d0-99EF-5E13E30E2A18%7D.png)
+
+此处本应有图片，但图床过期，暂无图片
+
 其本质原理是把 interface 之类的 ts 代码作为 prompt 模板。因此它不仅可以对输出结果进行 ts 校验，甚至能够输入注释描述，不可谓非常方便 js 开发者。不过，近日 typechat 爆火，很多开发者企图尝试将 typechat 移植到 python，笔者认为这是缘木求鱼，因为其校验本身依赖的是 ts。笔者在开发过程中，将 typechat 融合到自己的库中，效果不错。但是它本身自带的 prompt 和笔者输入的 prompt 还是存在冲突，还是需要扣扣源码。
 
 ### Langchain
@@ -234,9 +238,13 @@ LLM 的可控性、稳定性、事实性、安全性等问题是推进企业级
 ### 位置信息
 
 是否有人注意到 llm 对于关键信息在 prompt 中的位置会对结果产生影响呢？在设计 prompt 方面，人们通常建议为语言模型提供详尽的任务描述和背景信息。近期的一些语言模型有能力输入较长的上下文，但它究竟能多好地利用更长的上下文？这一点却相对少有人知。近日，有学者研究发现如果上下文太长，语言模型会更关注其中的前后部分，中间部分却几乎被略过不看，导致模型难以找到放在输入上下文中部的相关信息。下文部分是该论文一些核心内容：
-![](https://marlene-1254110372.cos.ap-shanghai.myqcloud.com/blog/%7B59E03114-A066-4394-B1F0-B09357F76B39%7D.png)
+
+此处本应有图片，但图床过期，暂无图片
+
 这是由其本身训练和结构设计有关的，但却对于我们开发有着莫大的帮助和指导意义。
-![](https://marlene-1254110372.cos.ap-shanghai.myqcloud.com/blog/%7B9EA47A4E-3EF3-4800-99F4-109EE713746B%7D.png)
+
+此处本应有图片，但图床过期，暂无图片
+
 相比之下，在多文档问答任务上，查询感知型上下文化的影响很小。特别指出，当相关信息位于输入上下文的最开始时，它可以提高性能，但在其他设置中会稍微降低性能。借此，我们可以认为，将重要的信息放在开头，结尾放置结构化模板，或许是一种优质选择。
 
 那么如果真的为其提供这么多 token，那会真的有用吗？这个问题的答案是：由下游任务决定。因为这取决于所添加上下文的边际价值以及模型有效使用长输入上下文的能力。所以如果能有效地对检索文档排序（让相关信息与输入上下文的起始处更近）或对已排序的列表进行截断处理（必要时返回更少的文档），那么也许可以提升基于语言模型的阅读器使用检索上下文的能力。

3.AI模块/3.9【旧版】AI杂谈/3.9.5LLMAgent之结构化输出.md

@@ -187,13 +187,17 @@ program(description="A quick and nimble fighter.", valid_weapons=valid_weapons)
 ### lmql
 
 在 guidance 的基础上，lmql 这个项目进一步把“prompt 模板”这个概念推进到了一种新的编程语言。从官网能看到给出的一系列示例。语法结构看起来有点像 SQL，但函数与缩进都是 Python 的风格。
-![](https://marlene-1254110372.cos.ap-shanghai.myqcloud.com/blog/%7B92E71406-7249-4345-894C-AC646F47D05A%7D.png)
+
+此处本应有图片，但图床过期，暂无图片
+
 从支持的功能来看，相比 guidance 毫不逊色。例如各种限制条件，代码调用，各种 caching 加速，工具集成等基本都具备。这个框架的格式化输出是其次，其各种可控的输出及语言本身或许更值得关注。
 
 ### TypeChat
 
 TypeChat 将 prompt 工程替换为 schema 工程：无需编写非结构化的自然语言 prompt 来描述所需输出的格式，而是编写 TS 类型定义。TypeChat 可以帮助 LLM 以 JSON 的形式响应，并且响应结果非常合理：例如用户要求将这句话「我可以要一份蓝莓松饼和一杯特级拿铁咖啡吗？」转化成 JSON 格式，TypeChat 响应结果如下：
-![](https://marlene-1254110372.cos.ap-shanghai.myqcloud.com/blog/%7BECFBBC78-BFE8-45d0-99EF-5E13E30E2A18%7D.png)
+
+此处本应有图片，但图床过期，暂无图片
+
 其本质原理是把 interface 之类的 ts 代码作为 prompt 模板。因此它不仅可以对输出结果进行 ts 校验，甚至能够输入注释描述，不可谓非常方便 js 开发者。不过，近日 typechat 爆火，很多开发者企图尝试将 typechat 移植到 python，笔者认为这是缘木求鱼，因为其校验本身依赖的是 ts。笔者在开发过程中，将 typechat 融合到自己的库中，效果不错。但是它本身自带的 prompt 和笔者输入的 prompt 还是存在冲突，还是需要扣扣源码。
 
 ### Langchain
@@ -234,9 +238,13 @@ LLM 的可控性、稳定性、事实性、安全性等问题是推进企业级
 ### 位置信息
 
 是否有人注意到 llm 对于关键信息在 prompt 中的位置会对结果产生影响呢？在设计 prompt 方面，人们通常建议为语言模型提供详尽的任务描述和背景信息。近期的一些语言模型有能力输入较长的上下文，但它究竟能多好地利用更长的上下文？这一点却相对少有人知。近日，有学者研究发现如果上下文太长，语言模型会更关注其中的前后部分，中间部分却几乎被略过不看，导致模型难以找到放在输入上下文中部的相关信息。下文部分是该论文一些核心内容：
-![](https://marlene-1254110372.cos.ap-shanghai.myqcloud.com/blog/%7B59E03114-A066-4394-B1F0-B09357F76B39%7D.png)
+
+此处本应有图片，但图床过期，暂无图片
+
 这是由其本身训练和结构设计有关的，但却对于我们开发有着莫大的帮助和指导意义。
-![](https://marlene-1254110372.cos.ap-shanghai.myqcloud.com/blog/%7B9EA47A4E-3EF3-4800-99F4-109EE713746B%7D.png)
+
+此处本应有图片，但图床过期，暂无图片
+
 相比之下，在多文档问答任务上，查询感知型上下文化的影响很小。特别指出，当相关信息位于输入上下文的最开始时，它可以提高性能，但在其他设置中会稍微降低性能。借此，我们可以认为，将重要的信息放在开头，结尾放置结构化模板，或许是一种优质选择。
 
 那么如果真的为其提供这么多 token，那会真的有用吗？这个问题的答案是：由下游任务决定。因为这取决于所添加上下文的边际价值以及模型有效使用长输入上下文的能力。所以如果能有效地对检索文档排序（让相关信息与输入上下文的起始处更近）或对已排序的列表进行截断处理（必要时返回更少的文档），那么也许可以提升基于语言模型的阅读器使用检索上下文的能力。