第五阶段：AI应用架构

1. Embedding（嵌入）

定义：将离散的文本、图像等数据映射到连续的低维向量空间的技术。语义相似的实体在向量空间中距离更近。

核心原理：
- 使用神经网络（如 BERT、OpenAI text-embedding-3）将文本转化为固定维度的浮点数向量（如 1536 维）。
- 向量可以计算相似度：余弦相似度、点积、欧氏距离等。

为什么重要：
- 机器无法直接理解文本，Embedding 是语义信息的数值化表示。
- 是检索、聚类、推荐、分类等任务的基础。

典型应用：
- 搜索引擎（文档与查询的向量匹配）
- 推荐系统（用户向量与物品向量相似度）
- 检索增强生成（RAG）中的召回步骤

常用模型：
- 开源：BAAI/bge-large、sentence-transformers、text2vec
- 闭源：OpenAI text-embedding-ada-002、Cohere、Google text-embedding

2. Vector DB（向量数据库）

定义：专门设计用于高效存储和检索高维向量的数据库。支持近似最近邻（ANN）搜索，能在百万/十亿级向量中快速找到最相似的 Top-K。

核心能力：
- 向量索引：HNSW、IVF、PQ 等算法，牺牲少量精度换取检索速度。
- 元数据存储与过滤：通常结合标量字段（如时间、类别）进行混合检索。
- 实时增删改查：支持动态更新向量。

与传统数据库的区别：
- 传统数据库（MySQL、PostgreSQL）对高维向量只能暴力扫描（O(n)），不可用。
- 向量数据库通过索引实现亚线性时间复杂度（O(log n)）。

常见产品：
- 开源：Chroma（轻量，适合原型）、Qdrant（Rust 写，高性能）、Milvus（功能全面）、Weaviate（内置 Embedding 模型）
- 云服务：Pinecone、Zilliz（Milvus 托管）、Azure AI Search

典型应用：
- RAG 知识库：存储文档分块后的 Embedding。
- 相似图片/商品推荐。
- 去重与聚类。

3. RAG（Retrieval-Augmented Generation，检索增强生成）

定义：一种将 LLM 与外部知识库结合的架构。先根据用户查询检索相关文档，再将查询和检索结果一起交给 LLM 生成最终回答。

工作流程：

用户 Query → Embedding → 向量检索 → 获取 Top-K 文档片段
                              ↓
            最终 Prompt = Query + 文档片段 + 指令
                              ↓
                          LLM 生成回答

为什么需要 RAG：
- 解决 LLM 的“幻觉”问题：提供事实依据。
- 引入私有/实时/领域知识：LLM 训练数据中可能没有。
- 降低频繁微调成本：无需重新训练模型。

关键组件：
- 索引阶段：知识库文档分块 → Embedding → 存入向量 DB。
- 查询阶段：Query Embedding → 检索 → 合成 Prompt → 调用 LLM。

优化技巧：
- 分块策略（重叠、按语义边界）
- 混合检索（向量 + 关键词 BM25）
- 重排序（Re-rank）提高第一页准确率

示例代码概念（使用 LangChain）：

retriever = vector_db.as_retriever(search_kwargs={"k": 4})
qa_chain = RetrievalQA.from_chain_type(llm=llm, retriever=retriever)
answer = qa_chain.run("我们的公司年假政策是什么？")

4. Agent（智能代理）

定义：一个由 LLM 驱动的、能够自主决策并执行一系列行动以完成复杂任务的系统。Agent 会观察环境（用户输入、工具返回结果），思考下一步行动，然后执行（调用工具），重复直到任务完成。

核心循环（ReAct 模式：Reason + Act）：
1. Thought：LLM 规划下一步要做什么。
2. Action：调用工具（如查询天气、搜索网页、执行代码）。
3. Observation：观察工具返回的结果。
4. 循环 → 最终输出 Answer。

与传统程序的区别：
- 传统程序：固定逻辑（if-else）。
- Agent：LLM 动态决定调用哪个工具、输入什么参数、何时停止。

典型应用：
- 个人助手：预订机票（调用航班查询 API + 支付接口）。
- 数据分析 Agent：写 SQL → 执行 → 画图表。
- 代码助手：根据问题写代码 → 运行测试 → 修正错误。

框架：
- LangChain (Agent 模块)
- AutoGPT / BabyAGI（实验性）
- LlamaIndex (Agent 与 RAG 结合)

挑战：
- 复杂任务易陷入循环、低效。
- 安全性：需要限制工具访问范围。
- 成本：多次 LLM 调用，Token 消耗大。

5. MCP（Model Context Protocol）

定义：由 Anthropic 于 2024 年 11 月提出的开放协议，旨在标准化 AI 助手与外部数据源、工具之间的连接方式。通俗讲，它是 AI 应用的“USB-C 接口”，让 LLM 能够以统一的方式访问文件、数据库、API 等。

核心要素：
- MCP Host：需要访问数据的 AI 应用（如 Claude Desktop、IDE 插件）。
- MCP Client：与 MCP Server 通信的组件。
- MCP Server：轻量级程序，暴露特定资源（如本地文件、GitHub 仓库、Slack 频道）给 AI。
- 协议传输：标准 JSON-RPC over stdio 或 SSE（Server-Sent Events）。

为什么需要 MCP：
- 之前每个 AI 工具集成外部数据都要写定制代码（如给 Claude 加上文件读写能力需要写大量 glue code）。
- MCP 定义了发现资源、读取资源、调用工具的统一范式。

工作流程：

用户提问 → MCP Host（Claude）→ MCP Client → MCP Server（如文件服务器）→ 读取文件 → 返回给 LLM

实际例子：
- 用 MCP 让 Claude 直接访问你的 PostgreSQL 数据库：无需手动导出数据，Claude 可以自己写 SQL 并执行（通过 MCP Server 安全地跑查询）。

与 Tool Calling 的关系：
- MCP 更侧重数据源连接，提供资源（文件、数据库记录）的标准化访问。
- Tool Calling 更侧重执行动作（发送邮件、创建日历事件）。

目前状态：较新，生态正在快速发展。Anthropic 开源了 MCP 规范、SDK 和参考 Server 实现。

6. Tool Calling（函数调用 / 工具调用）

定义：LLM 在生成响应时，能够输出一个结构化的“调用请求”，指示外部系统执行某个函数，并将返回结果纳入下一轮对话的能力。

工作流程（以 OpenAI 为例）：
1. 用户在对话中请求：“帮我查一下北京今天的天气。”
2. 开发者预先定义了工具列表（函数签名 + 描述）给 LLM。
3. LLM 判断需要调用 get_weather(city='Beijing')，并返回一个 JSON 结构。
4. 开发者执行该函数，得到结果 { "temp": 22, "condition": "晴" }。
5. 开发者再次调用 LLM（附上函数结果），LLM 生成自然语言回答：“北京今天晴，22°C。”

关键点：
- 不是 LLM 主动执行代码，而是输出 JSON 格式的调用请求，由外部应用执行。
- 模型必须经过微调才能生成符合函数调用的输出（OpenAI、Claude、Gemini 等都支持）。

与 Agent 的关系：
- Tool Calling 是 Agent 实现行动（Act）环节的基础能力。
- Agent 框架（如 LangChain）封装了 Tool Calling 的循环和记忆管理。

常见工具类型：
- 搜索（Google、Bing）
- 数学计算（计算器、Wolfram Alpha）
- 代码执行（Python 沙箱）
- API 调用（CRM、日历、邮件）
- 数据库查询

示例工具定义（OpenAI 格式）：

{
  "type": "function",
  "function": {
    "name": "send_email",
    "description": "发送邮件给指定收件人",
    "parameters": {
      "type": "object",
      "properties": {
        "to": {"type": "string"},
        "subject": {"type": "string"},
        "body": {"type": "string"}
      },
      "required": ["to", "subject", "body"]
    }
  }
}

概念关系图（AI 应用架构）

用户输入
   │
   ▼
┌────────────────────────────────────────────┐
│                  Agent                      │
│  ┌──────────┐     ┌────────────────────┐   │
│  │  Thought │ ←→  │ Tool Calling 循环  │   │
│  └──────────┘     └────────────────────┘   │
└────────────────────────────────────────────┘
   │                    │
   │ 需要外部知识        │ 需要执行动作
   ▼                    ▼
┌──────────┐      ┌──────────┐
│   RAG    │      │  Tools   │
│  +VDB    │      │ (API等)  │
└──────────┘      └──────────┘
   │                    │
   ▼                    │
Embedding Model        │
   │                    │
   ▼                    ▼
Vector DB          MCP Server（统一协议访问数据源/工具）

相辅相成的关系：
- Embedding + Vector DB 是 RAG 的存储与检索基础。
- RAG 给 Agent 提供长期知识库。
- Tool Calling 是 Agent 执行动作的具体接口。
- MCP 试图统一各种数据源和工具的接入方式，让 Tool Calling 和资源读取更标准化。

实践路径建议