AI Agent与知识库建设：从Embedding到RAG的完整指南

大模型很强，但它不知道你的业务。AI Agent和知识库，就是让AI从"通用助手"变成"你的专属专家"的关键。

我从测试转型做AI Agent开发，最先搞明白的一件事就是：光会调API是不够的，你得让AI能"看到"你的私有知识。

你有没有发现：不管用ChatGPT还是Claude，问它关于你自己公司产品的问题，它都答不上来？或者答得似是而非？

因为大模型的知识来自训练数据，它不知道你的文档、你的业务流程、你的私有知识。AI Agent + 知识库，就是解决这个问题的方案。

这篇文章是我做RAG系统和Agent开发的实战总结。我会把Embedding、向量数据库、RAG这些概念讲明白，让你从零开始搞清楚整套体系是怎么运作的。

---

一、先搞清楚几个核心概念

这些概念经常被混用，但它们是不同的东西。我一开始也搞混过。

大模型（LLM）

就是ChatGPT、Claude这些。本质是一个"超大的神经网络"，通过学习海量文本数据，学会了"接话"——你给它上半句，它能续下半句。

特点：

• 知识来自训练数据，有截止日期
• 不知道你的私有信息
• 一次对话的上下文窗口有限（虽然现在都到100万token了）

AI Agent（智能体）

一句话：能自主决策、调用工具、完成任务的AI系统。

普通的AI对话是"你问一句，它答一句"。Agent不一样——它能：

• 理解你的目标
• 拆解成子任务
• 决定用什么工具
• 执行、检查、修正
• 返回最终结果

类比：

• 普通AI对话 = 你问同事一个问题，他回答
• AI Agent = 你跟助理说"帮我订明天去上海的高铁，靠窗的"，他自己查车次、选座位、下单

我自己做的Agent项目，核心就是这个逻辑：用户说目标，Agent自己想办法完成。 中间调什么工具、分几步做，都是Agent自己决定的。

知识库（Knowledge Base）

一句话：把你的私有文档变成AI可以检索和引用的数据源。

你可以把它理解成给AI配了一本"参考手册"——AI回答问题时先翻手册，找到相关内容，再基于这些内容生成回答。

我做的rag-knowledge-base-demo项目，就是这个原理。把一堆Markdown文档扔进去，AI就能基于这些文档回答问题。

Embedding模型

一句话：把文字变成一串数字（向量），让计算机能计算"两段话有多像"。

这是知识库的核心技术。为什么需要它？因为AI不能直接"搜索"你的文档——它需要先把文档切成小段，每段变成一个向量，存起来。等你问问题的时候，把你的问题也变成向量，然后找"最相似"的文档片段。

直觉理解：

"今天天气真好"  →  [0.2, 0.8, 0.1, ...]   (向量A)
"阳光明媚的一天" →  [0.3, 0.7, 0.15, ...]  (向量B)
"我买了一台电脑"  →  [0.9, 0.1, 0.6, ...]   (向量C)
A和B的距离很近 → 语义相似
A和C的距离很远 → 语义不同

一开始我觉得这个概念很抽象，后来自己用FAISS跑了一遍就明白了。本质上就是把"语义"变成了"数学距离"。

向量数据库

一句话：专门存储和检索向量的数据库。

传统数据库用关键词匹配（精确查找），向量数据库用语义相似度查找（模糊但智能）。

常见选择：

• FAISS — Meta开源，纯向量检索库，我demo项目用的就是这个
• ChromaDB — 轻量级，适合原型开发
• Pinecone — 云端托管，开箱即用
• Weaviate — 开源，支持混合搜索
• Milvus — 开源，适合大规模场景

RAG（检索增强生成）

一句话：先检索相关知识，再让AI基于这些知识生成回答。

RAG = Retrieval（检索）+ Augmented（增强）+ Generation（生成）

这是目前最主流的"让AI拥有私有知识"的方案。 我做的所有知识库项目，底层都是RAG。

---

二、RAG的完整工作流程

用我实际项目的经验来说清楚RAG是怎么工作的：

【准备阶段 - 索引构建】
你的文档（PDF/Word/网页/Markdown）
│
▼
文档切片（Chunking）
把长文档切成小段（每段500-1000字）
│
▼
Embedding向量化
每段文字 → 一个向量
│
▼
存入向量数据库
【使用阶段 - 查询回答】
用户提问："产品A的退款政策是什么？"
│
▼
问题向量化
问题 → 一个向量
│
▼
向量相似度检索
在数据库中找到最相关的3-5个文档片段
│
▼
组装Prompt
"基于以下参考资料回答问题：
[检索到的文档片段]
问题：产品A的退款政策是什么？"
│
▼
LLM生成回答
基于检索到的内容，生成自然语言回答
│
▼
返回给用户（附带引用来源）

就这么简单。核心逻辑就三步：切片→向量化→检索+生成。

---

三、关键环节详解

1. 文档切片（Chunking）

切片质量直接决定回答质量。切太大，检索不精准；切太小，丢失上下文。

我踩过的坑：一开始把chunk_size设成2000字，结果检索出来的片段太长，包含了很多不相关的内容，AI回答经常跑偏。后来改成500字+100字重叠，效果好了很多。

常见切片策略：

| 策略 | 做法 | 适用场景 |

|------|------|---------|

| 固定长度 | 每500字切一段 | 通用文档 |

| 按段落 | 以自然段落为单位 | 结构化文档 |

| 按语义 | 用AI判断话题边界切换点 | 高质量需求 |

| 递归切分 | 先大块再小块，逐级细分 | 长文档 |

实践建议：

• 每段500-1000字，保留100-200字的重叠（overlap）
• 切片时保留标题和章节信息作为元数据
• 表格和图片单独处理

2. Embedding模型选择

这个选择直接影响检索效果。我试过好几个模型，总结如下：

| 模型 | 维度 | 特点 | 推荐场景 |

|------|------|------|---------|

| BGE-M3 | 1024 | 中文效果好，开源 | 中文场景首选 |

| OpenAI text-embedding-3-large | 3072 | 效果好，API调用 | 英文为主的场景 |

| OpenAI text-embedding-3-small | 1536 | 性价比高 | 预算敏感 |

| Jina Embeddings v3 | 1024 | 多语言，长文本支持好 | 多语言场景 |

中文场景强烈推荐BGE-M3。 我对比过OpenAI的embedding和BGE-M3，在中文语义理解上BGE-M3明显更准。而且它是开源的，可以本地跑，不花钱。

3. 检索策略

不只有"向量相似度"一种检索方式：

• 向量检索（Semantic Search） — 找语义最相似的片段
• 关键词检索（BM25） — 传统的关键词匹配
• 混合检索（Hybrid Search） — 向量 + 关键词结合，效果最好
• 重排序（Reranking） — 先粗检索出20条，再用模型精排取Top 5

实践建议：混合检索 + 重排序是目前效果最好的组合。 单用向量检索有时候会漏掉关键词精确匹配的结果，混合检索能互补。

4. Prompt组装

检索到内容后，怎么组装Prompt也很关键。这个很多人忽略，但其实很重要：

你是一个专业的客服助手。请基于以下参考资料回答用户问题。
规则：

只基于参考资料回答，不要编造信息
如果参考资料中没有相关内容，明确告知用户
回答要简洁、准确
引用来源时标注出处

参考资料：
[1] {chunk_1}
[2] {chunk_2}
[3] {chunk_3}
用户问题：{question}

关键是第一条："只基于参考资料回答，不要编造信息"。 不加这条约束，AI很容易"幻觉"——编造文档里没有的内容。

---

四、AI Agent的构建原理

知识库是Agent的"记忆"，但Agent还需要更多能力。

Agent的核心能力

1. 感知（Perception）
接收用户输入（文字/语音/图像/文件）

规划（Planning）

将复杂任务拆解为可执行的步骤
技术实现：ReAct、Plan-and-Execute、Tree of Thoughts

记忆（Memory）

短期记忆：当前对话上下文
长期记忆：向量数据库存储的历史知识

工具使用（Tool Use）

调用外部API、搜索引擎、代码执行器、数据库等

行动（Action）

执行具体操作，获取结果

反思（Reflection）

检查结果是否符合预期，必要时修正

我做Agent开发最大的体会是：Agent的核心不是模型有多强，而是工具调用和任务拆解的逻辑设计得好不好。 模型是大脑，但手脚得你自己搭。

常见Agent架构模式

1. ReAct模式（推理+行动）

思考：用户问的是退款政策，我需要先查知识库
行动：调用知识库检索"退款政策"
观察：找到了3条相关内容
思考：内容足够回答问题了
回答：根据我们的退款政策……

这是我最常用的模式。简单、可靠、容易调试。

2. Plan-and-Execute模式

用户目标：帮我写一份竞品分析报告
│
▼
规划：
步骤1：确定竞品列表
步骤2：收集各竞品信息
步骤3：对比分析
步骤4：生成报告
│
▼
逐步执行每个步骤

适合复杂任务。先规划再执行，比ReAct更适合需要多步协作的场景。

3. Multi-Agent模式

┌──────────┐  ┌──────────┐  ┌──────────┐
│ 研究Agent │  │ 写作Agent │  │ 审核Agent │
└─────┬────┘  └─────┬────┘  └─────┬────┘
│             │             │
▼             ▼             ▼
收集资料    撰写初稿     检查质量
│             │             │
└─────────────┴─────────────┘
│
▼
最终输出结果

多个Agent各司其职，协作完成任务。适合大型项目，但调试起来比较头疼。

---

五、从零搭建一个知识库问答系统

技术选型建议

| 组件 | 轻量方案（原型） | 生产方案 |

|------|----------------|---------|

| LLM | DeepSeek API | Claude/GPT-5.5 API |

| Embedding | BGE-M3（本地） | OpenAI/Cohere API |

| 向量数据库 | ChromaDB / FAISS | Pinecone/Weaviate |

| 框架 | LangChain / LlamaIndex | LangChain + 自定义 |

| 前端 | Gradio / Streamlit | Next.js 自建 |

最小可行方案（MVP）

用Python + LangChain + FAISS，几十行代码就能跑起来。我自己的demo项目就是这么搭的：

from langchain.document_loaders import DirectoryLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import HuggingFaceEmbeddings
from langchain.vectorstores import FAISS
from langchain.chains import RetrievalQA
from langchain.llms import DeepSeek
# 1. 加载文档
loader = DirectoryLoader('./my_docs/', glob="*/.md")
documents = loader.load()
# 2. 切片
splitter = RecursiveCharacterTextSplitter(
chunk_size=500, chunk_overlap=100
)
chunks = splitter.split_documents(documents)
# 3. 向量化 + 存储
embeddings = HuggingFaceEmbeddings(
model_name="BAAI/bge-m3"
)
vectorstore = FAISS.from_documents(chunks, embeddings)
# 4. 创建问答链
qa_chain = RetrievalQA.from_chain_type(
llm=DeepSeek(),
retriever=vectorstore.as_retriever(
search_kwargs={"k": 3}
)
)
# 5. 提问
answer = qa_chain.run("产品A的退款政策是什么？")
print(answer)

跑通这个demo，你就理解RAG的完整流程了。然后在这个基础上慢慢加功能：混合检索、重排序、多文档类型支持……

---

六、常见问题和优化方向

问题1：回答不准确，检索到的内容不对

原因： 切片质量差或Embedding模型不匹配

优化：

• 调整chunk_size和overlap（我建议先试500+100）
• 中文场景换用BGE-M3
• 加入Reranking重排序

问题2：回答"编造"了文档中没有的内容

原因： Prompt没有约束好

优化：

• 在Prompt中明确要求"只基于参考资料回答"
• 要求AI标注引用来源
• 加入"如果资料中没有，说不知道"

问题3：检索速度慢

原因： 向量数据库没有做好索引

优化：

• 使用HNSW等近似最近邻算法
• 对向量做降维处理
• 分片存储，按业务域隔离

问题4：知识库更新后回答还是旧的

原因： 没有增量更新机制

优化：

• 建立文档变更监听，自动触发重新索引
• 给每个chunk加时间戳，检索时优先返回最新的

---

七、名词速查表

写给跟我一样刚入行时被这些名词搞晕的人：

| 名词 | 一句话解释 |

|------|-----------|

| LLM | 大语言模型，如GPT-5.5、Claude，AI的"大脑" |

| Agent | 能自主决策和执行任务的AI系统 |

| Embedding | 把文字变成数字向量，让计算机能计算语义相似度 |

| 向量数据库 | 专门存储和检索向量的数据库 |

| RAG | 检索增强生成，先搜知识再回答 |

| Chunking | 把长文档切成小段，便于检索 |

| Reranking | 对检索结果重新排序，提高精准度 |

| Fine-tuning | 用特定数据微调模型，让模型"学会"你的领域知识 |

| Prompt Engineering | 提示词工程，通过优化输入来提升AI输出质量 |

| Token | AI处理文本的最小单位，大约1个汉字≈1-2个token |

| Context Window | 上下文窗口，AI一次能"看到"的文本长度 |

| Hallucination | 幻觉，AI编造不存在的信息 |

| ReAct | 一种Agent架构，推理+行动交替进行 |

---

八、什么时候用RAG，什么时候用Fine-tuning？

这个问题我被问过很多次。简单说：

| 维度 | RAG | Fine-tuning |

|------|-----|-------------|

| 适合场景 | 知识经常更新、需要引用来源 | 需要改变模型的风格或能力 |

| 数据需求 | 文档即可 | 需要大量训练数据 |

| 成本 | 低（只需向量化） | 高（需要GPU训练） |

| 更新知识 | 更新文档即可，实时生效 | 需要重新训练 |

| 可解释性 | 高（可以追溯引用来源） | 低（黑盒） |

结论：80%的场景用RAG就够了。 只有当你需要AI"改变行为模式"（比如学会你的写作风格）时，才考虑Fine-tuning。

我自己的所有知识库项目都是RAG，没碰过Fine-tuning。成本低、效果好、更新方便。

---

大模型是引擎，Agent是汽车，知识库是地图。三者结合，AI才能真正为你所用。