RAG实战：解决大模型幻觉，构建可靠知识库问答系统

前阵子一个做内部知识库问答项目的朋友跟我吐槽：他给公司知识库接了大模型，结果业务同事问“报销需要哪些材料”，模型一本正经地列出了“需提供房产证明、婚姻状况说明”这类完全不存在的内容。业务方当场就炸了，差点把项目叫停。那一刻我突然意识到，RAG（检索增强生成）这个词虽然已经被讲烂了，但很多人其实没真正想明白它到底在解决什么问题，更没搞懂为什么“检索”这个环节比“生成”更决定效果上限。

这篇文章我打算从问题根源开始，把 RAG 从原理到实践完整拆一遍，包含可落地的选型建议、代码实现、检索优化思路，以及进阶形态的选型判断。适合三类人看：一是刚转大模型应用开发、被“幻觉”折磨的新人；二是负责给企业做知识库问答、搜索增强的工程师；三是技术负责人，需要评估 RAG 方案到底值不值得投入、边界在哪。

1. 拆解“胡说八道”：大模型幻觉的根源与 RAG 的应对逻辑

1.1 “幻觉”的本质是这个模型在预测概率，不是在查证事实

很多人把大模型想成一台超级数据库，以为它能像搜索引擎一样命中事实后返回答案。这是个非常深的误解。语言模型的核心任务是给定前文预测下一个词的概率分布，它的训练目标函数从来就不是“保证答案和外部事实一致”，而是“让生成的文本在语言分布上最自然”。

这意味着当用户问到一个训练数据里没有覆盖、或者覆盖很少的细节问题时，模型会走一条高概率路径，把符合语言习惯但毫无事实依据的内容补全出来。这就是幻觉的根源，它不是偶发错误，而是概率机制的必然结果。举个例子，训练数据里如果根本没有你公司的人事制度，模型就只能根据“通常公司会有报销制度”这类泛化知识来编，编出来自然五花八门。

知识截止日期也加剧了这个问题。模型训练完成后知识就冻结了，今年新发布的政策、新调整的流程、刚上线的产品参数，它根本不知道。很多人把企业知识库问答做失败，就是因为拿一个截止日期在去年的模型，去回答今年才更新的制度文档，不胡说才怪。

1.2 RAG 为什么有效：把闭卷考试变成开卷考试

RAG 的思路其实非常朴素：既然模型自己记不住事实，那就在它每次回答之前先查资料，然后把查到的资料塞进上下文里，让它基于资料作答。

整个过程的本质，是把语言模型从一个“记忆能力有限的闭卷考生”，改造成一个“可以随时翻书的开卷考生”。它不需要记住新知识，只需要理解查到的材料，然后组织语言输出。这带来几个关键优势：

• 事实来源可追溯。模型被要求只依据上下文作答，即使它又习惯性编造，你也能看出来它没忠实于材料，便于拦截。
• 知识实时可更新。知识库里的文档变了，直接更新索引，不需要重新训练模型。
• 领域知识注入成本低。给企业做个问答，只需要把内部文档切分、向量化，模型本身的参数不需要动。

1.3 RAG 的边界：它不解决所有问题

我得提前泼盆冷水。RAG 不是银弹，它解决的是“私域知识缺乏”和“知识过期”带来的幻觉问题。但如果幻觉来自模型推理能力不足、或者问题本身需要强逻辑链推理，RAG 的效果就会打折。比如你问一道复杂的数学应用题，检索回来的材料可能根本包含不了完整的推导线索，模型该算错还是算错。

还有一类情况是检索本身就没做好，导致返回的上下文根本不含关键答案。这种问题不是 RAG 方案的问题，而是检索链路的问题，后面我会花大篇幅讲。先记住一句结论：RAG 系统的效果下限由检索决定，上限由生成模型决定。绝大多数项目做得烂，问题都出在检索，不在生成。

2. RAG 的三阶段工作流：索引、检索、生成各自在干嘛

2.1 索引阶段：把“文档”变成“可检索的向量”

RAG 的第一步就是把知识库文档变成机器能快速查找的索引结构。很多人第一次接触时会困惑：为什么需要向量化，直接用关键词搜不行吗？

关键词搜索（BM25 这类）确实可以，但它有一个致命问题：处理不了“语义匹配”。用户问“怎么报销差旅费”，如果文档里写的是“出差产生的交通住宿费用如何申请补贴”，关键词几乎对不上，传统检索就失效了。向量检索解决的就是这个语义鸿沟。

向量化做的事情，简单说就是通过 Embedding 模型把一段文本映射成一个几百维到几千维的浮点数数组，这个数组就是向量。向量设计上的关键特性是：语义相近的文本，向量在空间里的距离也相近。于是检索问题就变成了数学问题，给定一个查询向量，在向量库里找距离最近的 K 个向量。

这里的“距离”有几种常见算法，我在实际项目里最常用的是余弦相似度和内积。余弦相似度关注方向一致性，对向量的绝对长度不敏感，适合大多数文本检索场景；内积则受向量长度影响更大，一般在向量做过归一化处理后使用。选择哪个，往往取决于 Embedding 模型本身的推荐配置和向量库的索引类型。

2.2 检索阶段：把“用户问题”变成“查询条件”并召回

检索阶段看起来简单：把用户问题也用同一个 Embedding 模型向量化，然后查向量库。这里有两个非常容易踩坑的点。

第一个坑是，Embedding 模型不一致。用户问题用的模型、文档切分用的模型、向量库索引时用的模型，三者必须是同一个，否则向量空间都不对齐，检索结果就是噪声。哪怕是一个模型的不同版本，都会导致向量分布漂移。

第二个坑是，Top-K 的选择直接决定生成质量。K 太小，召回信息不足；K 太大，上下文充满无关碎片，模型反而被干扰。我见过很多人拍脑袋设个 K=4 就不管了，结果项目上线后效果不稳定。后面讲评估时我会说我自己的调法。

2.3 生成阶段：把“检索结果和用户问题”一起交给 LLM

生成阶段不是简单地把检索结果拼在用户问题前面就完事。Prompt 里必须明确约束模型的行为规则。我在工程上至少会包含三层指令：

• 角色与任务设定：告诉模型你是一个基于给定资料回答问题的助手。
• 忠实性约束：明确要求只依据资料内容作答，资料中没有的内容要直接说不知道，不得编造。
• 格式要求：按用户需要的格式输出，比如列表、段落、JSON。

一个典型的生成 Prompt 模板长这样（伪代码）：

code复制你是一个企业知识助手，请严格基于以下资料回答用户问题。
如果资料中找不到答案，请明确回答"根据现有资料无法回答"，禁止编造。
资料内容：
{context}
用户问题：{question}
请用简洁、准确的语言回答：

有人觉得这些指令写得越严厉越好，但实测下来语气太僵硬同样影响效果。更有效的做法是把“不编造”和“如何回答未知内容”的边界说清楚，给模型一条体面的退路，它会表现得更好。

2.4 三个阶段的实习链路图（文字版）

为了方便记忆，我把 RAG 的完整链路用文字描述一遍，各位可以对照自己的项目排查到底卡在哪一环：

文档加载 → 文档清洗 → 文档切分 → 每段向量化 → 写入向量库 → 用户提问 → 问题向量化 → 向量相似度检索 → 召回 Top-K 文本块 → 拼装 Prompt → LLM 生成 → 输出并附引用来源。

我第一次完整跑通这条链路时最大的感受是：真正花时间的地方根本不在写代码调 LLM，而在于文档怎么切、切完质量怎么保证、检索结果怎么筛选。这些都是脏活累活，但恰恰决定了一个 RAG 项目能不能从 demo 走向上线。

3. 从零手写一个最小 RAG 系统：选型、代码与效果验证

3.1 技术选型：先想清楚你的场景，再选工具

网上 RAG 相关工具多到令人眼花缭乱，LangChain、LlamaIndex、Dify、FastGPT、Navicat、向量库 FAISS、Milvus、pgvector……每个都有人推荐。我的经验是先别追新，按下面三个问题做筛选。

第一，你的知识库规模多大？一万个文本块以内，FAISS 这类轻量级库完全够用；百万级以上，再上 Milvus 这类分布式向量数据库。很多人一上来就部署 Milvus，结果数据量只有几千条，白白维护一套复杂系统。用这种选型思维可以避开绝大多数“过度设计”。

第二，你的团队更熟悉 Python 还是偏业务集成？如果只是做技术验证，LangChain 最省事；如果要深度定制检索链路，建议直接自己写，别被框架抽象绑住手脚。LlamaIndex 在文档索引上做得更细，适合知识库场景，但学习曲线也更陡。

第三，你需要本地部署还是可以走云端 API？涉及企业敏感数据，往往要求私有化。当前开源生态里，Embedding 模型有 BGE 系列，生成模型有 Qwen、DeepSeek 系列，配合 Ollama 这种本地推理工具，完全可以做到全链路本地部署。

3.2 各组件选型的横向对比

3.3 最小实现：用 LangChain + FAISS 跑通一个本地知识库问答

我不建议一上来就搞分布式高并发，先用最小代价跑通闭环，再逐步替换组件。这里给一套我验证过的组合：HuggingFace Embedding（BGE-M3）、FAISS、Ollama 上的 Qwen 模型。注意，下面代码是一个最小可运行的骨架，真实项目要加上日志、错误处理和分页。

python复制# 环境准备：pip install langchain langchain-community langchain-huggingface faiss-cpu chromadb
# 本地 Ollama 拉取模型：ollama pull qwen2.5:7b

from langchain_community.document_loaders import TextLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_huggingface import HuggingFaceEmbeddings
from langchain_community.vectorstores import FAISS
from langchain_community.llms import Ollama
from langchain.prompts import PromptTemplate
from langchain.chains import RetrievalQA

# 1. 加载文档
loader = TextLoader("./knowledge_base/company_policy.txt", encoding="utf-8")
documents = loader.load()

# 2. 切分文档
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", "。", "！", "？", "；", "，"],
)
chunks = text_splitter.split_documents(documents)
print(f"切分后的文本块数量: {len(chunks)}")

# 3. 向量化并写入 FAISS
embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-m3")
vectorstore = FAISS.from_documents(chunks, embeddings)

# 4. 初始化本地大模型
llm = Ollama(model="qwen2.5:7b", temperature=0.2)

# 5. 定义 prompt，强调忠实于检索内容
template = """请严格基于以下资料回答用户问题。
如果资料中没有相关信息，请直接回答"根据现有资料无法回答"，不要编造。

资料：
{context}

问题：{question}
请用中文简洁回答："""
prompt = PromptTemplate(template=template, input_variables=["context", "question"])

# 6. 组装 RAG 链路
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=vectorstore.as_retriever(search_kwargs={"k": 4}),
    chain_type="stuff",
    return_source_documents=True,
    chain_type_kwargs={"prompt": prompt},
)

# 7. 测试
query = "差旅报销需要提供哪些材料？"
result = qa_chain.invoke({"query": query})
print("回答：", result["result"])

写这段代码时我想提醒两点。

第一，chunk_size 和 chunk_overlap 不是随手填的。我习惯先看一眼文档的平均段落长度，再决定 chunk_size。如果文档多是长段落，512 字分会切碎逻辑单元；如果是短条目，512 又可能把多个不相关条目拼到一起。chunk_overlap 的作用是弥补切分时把原本连续的语义拦腰截断的问题，太小没效果，太大又造成重复。我常用的组合是 512 配 50，长文档项目试过 768 配 100。没有绝对正确，但一定要基于文档情况去调。

第二，bge-m3 这类模型加载后的向量维度是 1024，FAISS 支持。但切分出来的文本块如果数量到了几十万，FAISS 单机内存会吃紧。到时候再换成向量数据库也不迟，代码里的接口基本是兼容的。

3.4 效果验证：不带上检索，你根本不知道 RAG 差距多大

跑通之后不要急着上线，先做一次“有检索 vs 无检索”的对比测试。同一个问题，直接把用户问题丢给大模型问一遍，再走一遍 RAG 问答链路问一遍，把两次回答放在一起对比。

我实测过的例子来自一份内部制度文档：“员工申请年假需要提前几天？”直接问模型，它回答“一般需要提前一周申请”这种通用且完全没依据的话。走了 RAG 链路，模型从文档里定位到“须提前三个工作日申请”，并给出了来源。这就是 RAG 最直观的价值。

这个对比测试建议保留下来，作为项目汇报的素材。业务方不看技术原理，只看“同一个问题，两次回答谁更靠谱”。

4. 检索质量才是 RAG 的命门：切分、召回、重排的实战调优

4.1 切分策略：决定检索上限的第一道关卡

切分直接决定向量检索的质量上限。如果切分不合理，后面的重排、模型调优都是白费。我在多个项目里试过三种主流切分方式，效果差异非常大。

固定长度切分简单粗暴，按字符数硬切，代码好写，但经常切断句子甚至切断词。递归字符切分是 LangChain 默认方案，按分隔符优先级逐层尝试，比如先按双换行切，再按单换行切，最后按句号逗号切，逻辑上更友好。结构化感知切分则是针对特定文档格式做的，比如 Markdown 按标题层级切，HTML 按标签切，PDF 按段落边界切。三种方式我以前在一个问答项目里对比过，Markdown 格式的文档用结构化切分，答案命中率明显高于另外两种。

我的建议是：不要迷信某一种方式，先跑几个测试问题看召回结果。如果检索回来的 chunk 经常“差一口气”，答案明明在附近却没被召回，优先调整切分策略而不是去调模型。

关于 chunk 长度，一个经验数据：面向大模型问答的场景，单 chunk 控制在 300 到 800 字之间比较合适。太短，上下文碎片化，模型看不到完整逻辑；太长，向量包含太多噪声，检索精度下降，而且浪费模型上下文窗口。

4.2 混合检索：BM25 + 向量的组合才是多数场景的最优解

我在 3.1 里提过关键词搜索的问题：它解决不了语义匹配。但实际做了几年检索增强，我越来越确认一个反直觉但真实的结论：向量检索最擅长的语义匹配，在长尾真实业务问题上是查不全的，纯向量方案的结果往往不如“关键字 + 向量”混合方案。

原因在于：向量检索基于整体语义计算相似度，对于包含精确专有名词的查询（比如工单编号、产品型号、法律条文号），它可能把“ABC-DEF-123”看成一段普通文本，丢失精确匹配的强信号。BM25 则恰恰擅长这个，一旦查询里出现稀有词，它能给出很高的得分。二者的优缺点刚好互补。

工程上最常用、接近零成本实现的手段是 RRF（Reciprocal Rank Fusion，倒数排名融合）。它不需要重新训练模型，而是把两种检索结果按排名融合：

python复制# RRF 融合伪代码
# score(doc) = sum(1 / (k + rank_i(doc)))，i 表示第 i 路召回
# k 通常取 60

def rrf_fusion(ranked_lists, k=60):
    scores = {}
    for rank_list in ranked_lists:
        for rank, doc_id in enumerate(rank_list):
            scores[doc_id] = scores.get(doc_id, 0) + 1.0 / (k + rank + 1)
    return sorted(scores.items(), key=lambda x: x[1], reverse=True)

融合之后拿 Top-K 结果去给生成模型当上下文。实测下来，混合检索在内部文档问答场景里，答案命中率比纯向量检索高 10 到 20 个百分点，代价只是多一次 BM25 查询的开销，非常划算。

4.3 重排（Rerank）：从“召回几百”到“精选 Top 5”的关键一锤

不少项目在检索阶段召回了几十个 chunk，一股脑全塞给大模型，几个 1024 维的语义向量要托起整个知识库的精度，撑不住。

理想的做法是“粗排 + 精排”两段式：先用双塔或向量模型快速召回几百个候选，再用一个更重但更准的 Cross-Encoder 重排模型，把这几百个候选逐对与 query 计算相关性，精排到 Top 3 到 Top 5。重排模型里的 CrossEncoder 不像双塔那样把 query 和文档编码成两个独立向量求相似度，而是把 query 和文档拼接后送进同一个 Transformer，所以能捕捉更深层的交互信息，精度更高。

具体到中文场景，目前 bge-reranker 系列用的比较广。我给一个调用示例：

python复制from FlagEmbedding import FlagReranker

reranker = FlagReranker("BAAI/bge-reranker-v2-m3", use_fp16=True)

query = "差旅报销需要提供哪些材料"
candidates = ["报销标准适用于...", "年假申请流程...", "出差费用包括交通费..."]  # 来自向量库的 Top 50

pairs = [(query, cand) for cand in candidates]
scores = reranker.compute_score(pairs, normalize=True)

# 按分数从高到低排序，取前 5 个作为最终上下文
best_indices = sorted(range(len(scores)), key=lambda i: scores[i], reverse=True)[:5]

重排环节在业务里带来的体感提升比换一个大模型更明显。因为大模型能力再强，拿到的上下文是噪声也白搭。

4.4 元数据过滤：被大量项目忽视的检索加速器

真实知识库永远不会只有一种文档。制度、手册、公告、培训资料，混在一起。如果不做元数据过滤，检索时系统会在全部文档里撒网，查询“员工年假”时，很可能把无关渠道的政策碎片一并捞出来，白白占掉上下文。

解决方案是在切分阶段给每个 chunk 打上元数据标签，比如部门、文档类型、发布时间、适用范围。检索时，根据问题类型或用户属性，先过滤元数据，再在限定范围里做检索。

python复制# 写入元数据示例
from langchain_core.documents import Document

doc = Document(
    page_content="员工年假申请流程...",
    metadata={"doc_type": "制度", "department": "HR", "year": 2025}
)

这套机制在知识库规模大到一定程度后，作用堪比“分库分表”。不做元数据隔离，检索精度上不去，做复杂查询时还会明显变慢。

5. RAG 的进阶形态：GraphRAG、Agentic RAG、Hybrid RAG 怎么选

5.1 为什么传统 RAG 在多跳问题上会卡壳

普通向量检索有个天然缺陷：全局相关性。它根据 query 和 chunk 的向量相似度召回，但拆解“公司今年在华东区的营收情况如何，相比去年变化原因是什么”这种多跳问题，答案分布在一个文档的营收数字、另一个文档的业务解释、第三个文档的市场分析里，单跳检索不可能一次找全。

传统 RAG 给的“答案”往往只见树木不见森林，更糟的是模型拿到残缺上下文后可能自己脑补连接逻辑。要解决这类问题，光调检索不够，得换架构。

5.2 GraphRAG：给文档建图谱，处理实体关系和多跳问题

GraphRAG 的思路是：不仅存文本块，还把文本里的实体（人物、组织、产品、概念）和关系（事件影响、包含关系）抽取出来，构建知识图谱。查询时先在图谱上定位相关实体和关系路径，再结合原始文本块生成答案。

这个东西在回答“A 与 B 是什么关系”“哪些因素影响了某个指标”这类关系型、多跳型问题上，优势非常明显。代价是实现复杂度高，需要做实体抽取、关系抽取、图谱存储，基础设施成本不小。微软开源的 GraphRAG 项目把整套流程标准化了，但第一次跑通仍然比普通 RAG 费事。

我的判断是：如果你的问答场景大量涉及“多实体、多关系”的全局分析，值得投资 GraphRAG；如果只是查制度、查说明书这种单点问答，GraphRAG 属于杀鸡用牛刀。

5.3 Agentic RAG：让模型自己决定“怎么查、查几次”

普通 RAG 是线性流水线：查询 → 检索 → 生成，一次走完。Agentic RAG 则把决策权交给 Agent，模型可以在回答过程中动态决定要不要检索、检索哪个知识库、是否需要改写查询、一次不够要不要再查一次。

比较常见的 Agentic RAG 实现方式是 ReAct 模式。模型收到一个复杂问题后，先拆解成子任务，每执行一个子任务就去检索一次，拿到结果再判断是否继续。这个模式的实用场景包括：跨多个数据源获取信息的问题、需要先做意图识别再决定查哪个库的问题、以及用户把问题描述得模糊需要主动澄清的问题。

但 Agentic RAG 也有明显代价：每次 Agent 决策都有一次 LLM 调用，延迟和成本成倍增加，同时流程的不可控性上升，容易出现 Agent 在错误的检索路径上来回打转。我建议在项目早期先用稳定、可控的普通 RAG，等业务方明确提出了“一个户请求要在不同库里来回查”的需求，再考虑 Agentic 化。

5.4 Hybrid RAG 的组合实践

Hybrid RAG 不是一个新的独立技术，它更像是一种工程组合策略：把向量检索、BM25、知识图谱、Agent 决策等多条检索路径组合起来，按 query 类型动态路由到合适的通路。

• 简单事实型问题（“报销材料有哪些”）→ 直接走混合检索 + 重排流水线，快速稳定。
• 关系分析型问题（“A 和 B 有什么关系”）→ 走图谱通路。
• 跨库汇总型问题（“各个渠道的反馈分别是什么”“整体趋势如何”）→ 走 Agentic 通路，多轮检索汇总。

做路由层有很多方式，可以基于分类模型，也可以直接让 LLM 做意图识别。工程上我建议先画一张“问题类型 × 检索通路”的决策矩阵，把规则钉死，再逐步引入 Agent 做兜底。不要把整个系统一次改成全动态路由，出问题时可排查性会很差。

6. 上线前的评估与避坑清单：用数据说话，别凭感觉

6.1 先建立评测集：没有评测集，一切优化都是无底洞

我给每个 RAG 项目定的第一条铁律：动手调优前，先攒一个评测集。没有评测集，你改一个参数很难判断效果是真变好了，还是碰巧在某个测试问题上更顺眼。评测集不需要一开始就做很大，20 到 50 个真问题就够起步。关键是问题要有代表性，覆盖不同难度，并且每个问题都要有标准答案或关键知识点，标注命中与否。

我一般会把问题按难度分成三类：直接型（答案集中在一个段落，问“是什么”“怎么走流程”）、推理型（答案跨多个段落，需要模型结合多段信息回答，如“需要满足什么条件才能申请”）、未知型（知识库里根本没有答案，用来验证模型是否真的会拒绝作答而不是硬编）。

6.2 核心指标：命中率、MRR、忠实度怎么算

• 命中率（Hit Rate）：Top-K 检索结果里是否有包含标准答案的段落。这个指标最直观，它能告诉你“检索环节是否在正确的区域找活”。
• MRR（Mean Reciprocal Rank）：标准答案在检索结果里的排序位置取倒数，衡量“好结果排得有多靠前”。排序越靠前，MRR 越高，既考虑有没有，也考虑位置好不好。
• 忠实度（Faithfulness）：生成答案里有多少内容是依据检索上下文得出的，而不是模型自创的。计算方式可以把答案和上下文交给另一个更强的模型打分，或者人工抽检。

把这三个指标分开看，能帮你精确定位问题。Hit Rate 低，问题在检索；Hit Rate 高但忠实度低，问题出在“模型没忠实使用检索结果”，该调 Prompt 或换模型。

6.3 我踩过的五次高频坑，逐个排给你看

第一次，切分过细导致上下文碎片化。文档被切成 200 字的小块，答案的关键信息被拆到两个块里，检索只召回其中一个，模型答了一半。后来改用结构化切分并增大块长度，配合 chunk_overlap，问题解决。

第二次，Embedding 模型和查询场景不匹配。一个英文项目用了面向通用领域的中文 Embedding 模型，英文检索效果惨不忍睹。换回 multilingual 或者对应语言的模型之后，反馈立刻正常。换模型是要重建整个索引的，这个成本开局就得想清楚，别等索引建完再换。

第三次，元数据过滤没有做，导致不同类别的文档互相干扰。我的知识库里有服务和投诉两类文档，检索“售后服务时效”时，投诉类文档频繁混进来，上下文充满负面言论，生成质量被严重拖累。加了 doc_type 过滤后，情况直接翻转。

第四次，重排环节放在最后却只排了十几个候选，作用被大幅削弱。重排的价值取决于第二路“粗召回”的覆盖面有多广。后来我先用混合检索召回 Top 50，再做精排选 Top 5，效果明显比只精排十几条更稳。

第五次，评测时盲目相信 LLM 打分。拿一个 LLM 给另一个 LLM 的答案打分，精简、指标名称会成了很大的诱惑。改了两轮之后发现分数非常不稳，后来加了固定打分 prompt、多次采样取均值，并保留人工抽检，数据才可信。

6.4 安全与权限：私域知识库必须考虑的合规问题

RAG 项目往往涉及企业内部文档，不能把所有文件无差别塞进同一个库里检索。不同权限级别的用户，能检索到的文档范围必须做隔离。最简单的方式是在切分文档时，给每个 chunk 打上权限级元数据，检索阶段根据用户身份过滤。别等出了越权事故再补救。

还有一点容易被忽略：文档里可能包含未公开的内部决策过程、薪资数据等敏感信息，即使做了权限隔离，生成模型也可能在回答时泄露上下文里不该被这个用户看到的信息。Prompt 里同样要做边界约束，并在评测集里添加“敏感问题拒绝作答”的用例。

最后分享一点个人经验

做了这么多 RAG 项目，我最大的体会是：技术选型和参数调整其实只占三成工作量，真正决定项目生死的是数据治理、评测体系、边界设定这些看起来不酷的脏活。

从我自己的落地经验看，一个稳妥的路径是：先拿 100 篇典型文档构建最小闭环，跑通 RAG 三步流程，建立 30 个问题规模的评测集；然后集中精力把切分策略和混合检索调到 Hit Rate 达标，再做重排和 Prompt 优化；最后才根据实际遇到的复杂问题，评估要不要引入 GraphRAG 或 Agentic RAG。这个顺序能帮你避开“系统很复杂但答不对题”的尴尬。

如果这篇文章能给你帮上忙，建议你对照自己的项目，先回答三个问题：我的知识库文档切得合不合理？我的检索是单路还是混合？我有没有一个可以说服业务方的评测集？这三个问题的答案，往往已经决定了项目能走多远。