Skip to content

Commit 88ca6f0

Browse files
committed
docs:更新专栏
1 parent af5c63a commit 88ca6f0

8 files changed

+665
-4
lines changed

Diff for: docs/.vuepress/config.js

+17-3
Original file line numberDiff line numberDiff line change
@@ -353,7 +353,7 @@ module.exports = {
353353
text: 'OAuth2.0',
354354
items: [{
355355
text: 'OAuth2.0专栏概述',
356-
link: '/md/security/01-OAuth 2.0实战-为什么要先获取授权码code.md'
356+
link: '/md/security/OAuth 2.0实战-为什么要先获取授权码code.md'
357357
}, ]
358358
},
359359

@@ -718,7 +718,7 @@ module.exports = {
718718
text: '常见攻击手段',
719719
items: [{
720720
text: '常见攻击手段概述',
721-
link: '/md/security/01-OAuth 2.0实战-为什么要先获取授权码code.md'
721+
link: '/md/security/OAuth 2.0实战-为什么要先获取授权码code.md'
722722
}, ]
723723
},
724724
]
@@ -2107,6 +2107,9 @@ module.exports = {
21072107
"qwen-QwQ",
21082108
"only-ai-flow-can-do",
21092109
"chatgpt-canva",
2110+
"mcp-fad-or-fixture",
2111+
"mcp-and-the-future-of-ai-tooling",
2112+
"llm-reasoning-limitations",
21102113
]
21112114
},
21122115
{
@@ -2198,6 +2201,17 @@ module.exports = {
21982201
children: [
21992202
"what-is-rnn",
22002203
"neural-memory-engine-for-sequence-modeling",
2204+
"long-short-term-memory",
2205+
"gated-recurrent-unit-model",
2206+
]
2207+
},
2208+
2209+
{
2210+
title: "Transformer",
2211+
collapsable: false,
2212+
sidebarDepth: 0,
2213+
children: [
2214+
"mask-tensor",
22012215
]
22022216
},
22032217

@@ -2467,7 +2481,7 @@ module.exports = {
24672481
collapsable: false,
24682482
sidebarDepth: 0,
24692483
children: [
2470-
"01-OAuth 2.0实战-为什么要先获取授权码code.md",
2484+
"OAuth 2.0实战-为什么要先获取授权码code.md",
24712485
"03-OAuth2.0实战-轻松学会使用JWT,让你的OAuth2.0实现更加安全高效!",
24722486
"07-你确定懂OAuth 2.0的三方软件和受保护资源服务?",
24732487
]

Diff for: docs/md/AI/llm/llm-reasoning-limitations.md

+82
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,82 @@
1+
# 大模型推理能力的局限性
2+
3+
## 0 前言
4+
5+
LLM凭借其生成连贯文本、翻译语言甚至进行对话的能力,彻底改变人工智能领域。然而,尽管这些模型表现出色,它们在推理和理解复杂上下文方面仍然面临重大挑战。
6+
7+
这些模型擅长识别并模仿训练数据中的模式,但当任务需要真正的理解和[逻辑推理](https://dzone.com/articles/6-ways-how-programming-helps-to-develop-abstract-t)时,它们往往遇困。可能导致:
8+
9+
- 长对话中的不一致
10+
- 难以关联分散的信息
11+
- 在长篇叙述中难以保持上下文一致性
12+
13+
深入理解这些推理问题对于改进未来 LLM 的发展和应用至关重要。
14+
15+
## 1 关键推理挑战
16+
17+
### 1.1 缺乏真正的理解
18+
19+
语言模型的工作原理是根据训练过程中学到的模式预测下一个关键词,而不像人类真正理解其所讨论的内容。因此,在需深层理解的复杂推理任务,LLM 表现不佳。
20+
21+
### 1.2 上下文限制
22+
23+
尽管现代 LLM 在短期上下文理解方面表现良好,但在长对话或大篇幅文本中保持一致性和上下文连贯性仍是挑战。当需要整合对话或文本的多个部分时,模型可能会出现推理错误。例如,在一场长时间的讨论或复杂的故事叙述中,模型可能会忘记或误解之前的信息,导致后续的矛盾或错误结论。
24+
25+
### 1.3 无法进行规划
26+
27+
许多推理任务涉及多步逻辑推导或需要跟踪多个事实。当前的 LLM 在需要长时间连贯性或多步逻辑推理的任务上表现较差,例如解答需要多个逻辑步骤的谜题。
28+
29+
### 1.4 回答无解问题
30+
31+
回答无解问题是 LLM 推理能力的一大挑战。当面对悖论、无明确答案的问题,或与已知事实相矛盾的问题时,LLM 可能难以提供有意义或连贯的回答。相较于直接承认问题无解,模型可能会基于训练数据的模式硬给出一个答案,这可能导致误导性或错误的结果。[推理能力的局限性](https://dzone.com/articles/understanding-rlaif-a-technical-overview)在这一点上尤为明显。
32+
33+
### 1.5 状态空间计算的复杂性
34+
35+
某些问题需要探索从初始状态到目标状态的所有可能路径。例如,在旅行规划中,涉及大量可能的选项,并且随着预算、交通方式等额外限制的增加,搜索状态空间可能会呈指数级增长。对于 LLM 来说,计算所有这些可能性并给出最佳方案是不现实的,因此它通常会依赖所学的启发式方法,给出一个可能并不正确的可行解。
36+
37+
## 2 现实案例:错误的推理
38+
39+
问题:
40+
41+
```
42+
"一个水壶装有 8 个单位的水,还有两个容量为 5 和 5 的空水壶。"
43+
"目标是通过倒水,使前两个水壶各包含 4 个单位的水,而第三个水壶保持为空。"
44+
"每次倒水时,水只能从一个水壶倒入另一个,直到倒水的水壶空了,或者接收水的水壶装满为止。"
45+
```
46+
47+
实际上,这问题无解,但目前 LLM 仍尝试给出解答,仿佛它们找到正确答案。
48+
49+
然而,如果问题稍作修改,将两个空水壶的容量改为 5 和 4(而非 5 和 5),所有 LLM 都能够正确回答。这表明,它们可能只是记住了某些已知问题的解决方案,而不是进行真正的推理。
50+
51+
## 3 研究人员如何改进 LLM 的推理能力?
52+
53+
目前,研究人员正在探索多种方法来提升 LLM 的推理能力,其中包括改进数据集、引入链式思维、使用外部验证器和整合专门的求解器。
54+
55+
### 3.1 改进数据集
56+
57+
一些研究人员认为,提高 LLM 训练数据的质量和多样性是关键。通过更广泛、更精细的数据集训练模型,可以增强其处理复杂推理场景的能力。
58+
59+
### 3.2 链式思维(Chain-of-Thought)
60+
61+
[这一方法](https://dzone.com/articles/chain-of-thought-prompting-for-llms) 旨在让 LLM 按照人类的逻辑思维方式,逐步进行推理。通过显式生成中间推理步骤,模型能够更准确地完成复杂推理任务,并减少逻辑错误。
62+
63+
### 3.3 使用外部验证器
64+
65+
为了解决 LLM 生成错误或误导性信息的问题,一些研究人员提出整合外部验证机制。通过与可信数据源比对或使用额外算法进行验证,这些机制可以确保最终输出的信息更加准确、可靠。
66+
67+
### 3.4 使用专门的求解器
68+
69+
另一种方法是引入专门的求解器来处理特定类型的推理任务。例如,使用数学求解器进行计算,或使用逻辑推理工具处理复杂推理问题。这些工具可以补充 LLM 的能力,提高系统整体的准确性和可靠性。
70+
71+
## 4 结论
72+
73+
尽管 LLM 在文本生成和理解方面取得了令人瞩目的进展,但由于缺乏真正的理解能力、难以保持上下文一致性,以及仅依赖从海量但可能存在缺陷的数据中提取的模式,它们仍然在复杂的多层推理任务上存在明显不足。未来的 LLM 需要更先进的架构,并结合常识推理等方面的持续研究,以提升其推理能力。
74+
75+
参考:
76+
77+
1. [水壶倒水问题](https://en.wikipedia.org/wiki/Water_pouring_puzzle)
78+
2. [用 LLM 学习推理](https://openai.com/index/learning-to-reason-with-llms/)
79+
3. [GSM-Symbolic:LLM 在数学推理方面的局限性](https://arxiv.org/abs/2410.05229)
80+
4. [PlanBench:评估 LLM 规划和推理能力的基准](https://arxiv.org/abs/2206.10498)
81+
5. [LLM 仍然无法规划,但 LRM 可以吗?](https://arxiv.org/abs/2409.13373)
82+
6. [LLM 无法规划,但可以在 LLM-模块化框架中辅助规划](https://arxiv.org/abs/2402.01817)

Diff for: docs/md/AI/llm/mcp-and-the-future-of-ai-tooling.md

+122
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,122 @@
1+
# MCP:AI 时代的工具接口标准?
2+
3+
## 0 前言
4+
5+
自从 OpenAI 在 2023 年推出函数调用(Function Calling),我一直思考,咋能真正解锁 AI Agent与工具的生态系统。随基础模型越来越智能,AI Agent与外部工具、数据和 API 的交互方式却变得越来越碎片化——开发者需**针对每一个系统单独编写业务逻辑**,让Agent能够适配不同环境。
6+
7+
## 1 标准化
8+
9+
显然,我们需要一个标准化的接口来执行任务、获取数据并调用工具。在互联网时代,API 让不同软件之间可以相互通信,成为了**软件的通用语言**。但对 AI 模型,目前还缺这样的标准。
10+
11+
2024 年 11 月,**模型上下文协议(Model Context Protocol,MCP)**发布,迅速引起关注,被认为可能成为这一问题的解决方案。本文探讨:
12+
13+
- **MCP 是什么?**
14+
- **它如何改变 AI 与工具的交互方式?**
15+
- **开发者已经用 MCP 构建了哪些应用?**
16+
- **MCP 仍然面临哪些挑战?**
17+
18+
## 2 什么是 MCP
19+
20+
MCP 是一种**开放协议**,旨在让不同系统能够为 AI 模型提供**可泛化的上下文信息**。它规定了**AI Agent如何调用外部工具、获取数据,并与服务交互**
21+
22+
**Resend MCP 服务器**可以同时与多个 MCP 客户端交互,使其具备邮件发送能力。MCP 灵感源于**语言服务器协议(LSP,Language Server Protocol)**。在 LSP 中,当用户在代码编辑器中输入时,客户端会向语言服务器请求自动补全建议或代码诊断。
23+
24+
MCP进一步拓展,采用**面向 AI Agent的执行模式**
25+
26+
- **LSP 主要是被动的**,只会在 IDE 发请求时提供反馈
27+
- **MCP 则支持 AI Agent自主决策**,可以基于上下文信息选择合适的工具,并决定调用顺序,实现复杂任务的自动化
28+
- **MCP 还支持“人类参与(human-in-the-loop)”**,允许人在关键节点提供额外信息或批准操作
29+
30+
## 3 MCP目前的热门应用
31+
32+
如有够多的 MCP 服务器,用户就能将**任何 MCP 客户端变成“万能应用”**
33+
34+
### 3.1 Cursor
35+
36+
作为一个代码编辑器,同时也是**高质量 MCP 客户端**。安装不同 MCP 服务器,可变身为:
37+
38+
- **Slack 客户端**(连接 Slack MCP 服务器)
39+
- **邮件发送工具**(连接 Resend MCP 服务器)
40+
- **AI 图像生成器**(连接 Replicate MCP 服务器)
41+
42+
更强大的,**用户可组合多个 MCP 服务器**,解锁新应用场景。如Cursor中,用户可:
43+
44+
- 使用前端 UI 生成 MCP 服务器,自动创建网页界面
45+
- 让 AI Agent调用图像生成 MCP 服务器,为网页自动生成一张配图
46+
47+
这种**跨工具协作**的能力,正是 MCP 带来突破。
48+
49+
## 4 核心应用方向
50+
51+
### 4.1 面向开发者的工作流优化
52+
53+
对开发者,MCP 一大价值是**减少切换工具的时间**
54+
55+
#### 开发者的痛点
56+
57+
> “我不想为做某个任务而离开 IDE。”
58+
59+
MCP 服务器正满足需求,如:
60+
61+
- **Postgres MCP 服务器** → 让开发者直接在 IDE 里执行 SQL 查询,而无需打开数据库管理界面
62+
- **Upstash MCP 服务器** → 让开发者在 IDE 里管理缓存索引
63+
- **Browsertools MCP 服务器** → 让代码Agent访问浏览器控制台日志,辅助调试
64+
65+
MCP 还能帮助 AI Agent**动态获取代码相关的上下文**,如:
66+
67+
- 爬取网页内容,为Agent提供实时信息
68+
69+
- 通过 API 自动生成 MCP 服务器,让 AI Agent能直接访问工具,而无需手动集成
70+
71+
即开发者可**更少写模板代码,更多专注于业务逻辑**
72+
73+
### 4.2 全新的 AI 交互体验
74+
75+
尽管 MCP 目前在开发者社区最受欢迎,但它的潜力远不限于技术领域。如:
76+
77+
- **Claude Desktop** → 让非技术用户也能轻松使用 MCP 服务器,如营销文案生成、设计、客服等任务
78+
- **Highlight MCP 客户端** → 允许用户通过 @ 命令调用 MCP 服务器,将生成内容直接输入到任何应用
79+
- **Blender MCP 服务器** → 让**不会建模的用户**,通过自然语言描述 3D 模型,AI Agent自动生成对应的图像或动画
80+
81+
社区还正在开发**适用于 Unity 和 Unreal Engine 的 MCP 服务器**,AI 生成 3D 内容的流程正在变得越来越完善。
82+
83+
## 5 MCP现状
84+
85+
MCP生态仍处早期阶段,主要趋势:
86+
87+
- **高质量的 MCP 客户端仍以开发工具为主**,但未来会有更多面向商业场景客户端
88+
- **大多数 MCP 服务器是本地优先(local-first)的**,未来可能会向远程 MCP 服务器扩展
89+
- **MCP 市场和托管解决方案正在兴起**,如 Mintlify 的 MCP 市场、Smithery 和 OpenTools,让开发者可以更容易发现和共享 MCP 服务器
90+
91+
## 6 MCP的挑战
92+
93+
### 6.1 托管与多租户支持
94+
95+
目前MCP服务器主要1对1,未来需支持**多个用户同时访问**,尤其SaaS场景。
96+
97+
### 6.2 身份验证(Authentication)
98+
99+
MCP 目前没有标准的身份验证机制,开发者需要自己实现 OAuth 或 API 令牌管理
100+
101+
### 6.3 权限管理(Authorization)
102+
103+
MCP 目前的权限是基于会话的,未来需要更细粒度的访问控制。
104+
105+
### 6.4 网关(Gateway)
106+
107+
未来 MCP 可能需要一个**集中式网关**,类似 API 网关,管理身份验证、授权、流量控制等功能
108+
109+
### 6.5 MCP 服务器发现与注册机制
110+
111+
MCP 服务器目前需要手动配置,未来可能会有一个类似 npm 或 RapidAPI 的 MCP 服务器注册中心,让 AI Agent**自动发现并集成工具**
112+
113+
## 7 MCP未来:AI Agent的 API 标准?
114+
115+
MCP目前像**2010时的 API 生态**——新颖但仍处早期阶段。若MCP 成为 AI Agent的标准接口,会咋样?
116+
117+
- **工具竞争力将取决于 AI Agent能否发现并调用它**,而不仅是 API 设计是否优秀。
118+
- **定价模式可能改变**,AI Agent可能会**动态选择最便宜、最快、最相关的工具**,而不是仅仅依赖市场占有率。
119+
- **文档将变得至关重要**,因为 AI Agent需要**机器可读的格式**来理解 MCP 服务器的功能。
120+
- **API 将不再是终点**,开发者需要围绕具体场景构建 MCP 服务器,而不是简单地开放 API 端点。
121+
122+
MCP **正在重塑 AI Agent生态**,但它的未来取决于开发者如何解决当前的基础问题。如果一切顺利,MCP 可能会成为**AI Agent调用工具的默认接口**,解锁全新的自主、多模态、深度集成的 AI 体验。

0 commit comments

Comments
 (0)