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是怎么工作的：

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

三、关键环节详解

1. 文档切片（Chunking）

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

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

常见切片策略：

实践建议：

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

2. Embedding模型选择

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

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

3. 检索策略

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

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

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

4. Prompt组装

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

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

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

参考资料：
[1] {chunk_1}
[2] {chunk_2}
[3] {chunk_3}

用户问题：{question}

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

四、AI Agent的构建原理

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

Agent的核心能力

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

常见Agent架构模式

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

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

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

2. Plan-and-Execute模式

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

3. Multi-Agent模式

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

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

技术选型建议

最小可行方案（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加时间戳，检索时优先返回最新的

七、名词速查表

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

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

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

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

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

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

本文是"肖恩的博客"系列文章之一，首发于 seanwalter.top。作者是一名从软件测试转型AI领域的开发者，记录在转型过程中的真实思考。