RAG实战指南：用检索增强生成解决大模型幻觉问题

最近这一两年，大模型的热度大家都有目共睹。但只要你真正把它用到业务里，大概率会遇到同一个尴尬场面：模型回答得头头是道，仔细一查，关键数据、引用来源、专有名词全是编的。业内管这个叫“幻觉”，说白了就是一本正经地胡说八道。RAG（Retrieval-Augmented Generation，检索增强生成）就是目前应对这个问题最主流、也最接地气的方案。

这篇内容我从头到尾讲清楚 RAG：它到底干了什么事、为什么能缓解幻觉、一个生产可用的 RAG 系统由哪些部件组成、怎么在本地把它跑起来，以及你大概率会踩到的坑。文章面向的是想真正上手 RAG 的开发者、AI 应用工程师和产品技术负责人，不管你是第一次听说这个词，还是已经调过几个 demo，应该都能从中拿到点能直接用的东西。

1. 大模型为什么总在胡说八道：先搞懂幻觉从哪里来

1.1 预测下一个词的本质决定了它没有“查证”能力

很多人会把大模型想象成一个“什么都知道的超级大脑”，这个印象其实是有偏差的。你用的 GPT、Claude、文心、通义、DeepSeek，本质都是在一个巨大的语料库上训练出来的概率模型，它们的核心任务只有一个：根据你给的上下文，预测下一个最可能出现的 token（你可以粗略理解为“词”）。

这套机制带来的结果就是，模型在回答问题时，并不是先去数据库里“查”一个正确答案，而是根据它见过的所有文本的统计规律，把“最像话”的一串词语拼出来。在常见问题上，这种方式非常高效，因为训练语料里已经有了大量高质量答案，模型能“背”出来。可一旦遇到下面几种情况，它就绷不住了：

• 训练数据里根本没覆盖到的冷门知识，或者覆盖得很少。
• 事实发生的时间晚于训练截止日期（比如你问它上个月的行业数据）。
• 答案高度依赖企业内部文档、个人笔记、私域资料等非公开信息。
• 问题描述含糊、有歧义，模型只能靠“猜”补全。

在这些场景下，模型不会说“我不知道”，它最擅长的是接着你的话头编一个听起来合理的答案。这就是幻觉的根源：模型没有“知之为知之，不知为不知”的能力，它的训练目标里根本没有“承认无知”这个选项。

1.2 “投喂”上下文的朴素解法，为什么不能直接用

既然模型不知道答案，那我们把答案塞给它不就行了？这个思路完全正确，也是 RAG 的核心，但直接“塞”是有技术门槛的。

最朴素的做法是把整份资料塞进 Prompt。问题来了：大模型的输入长度是有限的。早期模型 4K、8K token 的上下文窗口，根本放不下几百页的文档。即便现在很多模型支持 128K、200K 甚至更长的上下文，直接把全量资料塞进去，也会出现两个新问题：

一是成本暴涨。token 越大，每次调用花的钱越多，长上下文的推理速度也会显著下降。二是“迷失在中间”。大量实验和工程经验都表明，当上下文变得很长时，模型对中间部分内容的注意力会明显减弱，你辛苦塞进去的关键信息反而被淹没了。

所以 RAG 的思路不是“全塞”，而是“先查再塞”：先根据用户问题，从知识库里检索出最相关的几个片段，再把这几段作为上下文交给大模型组织答案。整个过程就像一个配备专职助理的专家：助理先去档案室找资料，专家只需要读助理挑出来的两三页，就能给出靠谱回答。

1.3 RAG 到底解决的是什么问题

RAG 不是让模型“变聪明”，而是给模型配了一个“外部硬盘”和“检索员”。它解决的问题可以拆成三点：

• 知识时效性：知识库可以随时更新，今天改完文档，明天模型回答就是新内容，不需要重新训练。
• 领域知识私有化：企业内部知识、个人文档不需要暴露给模型训练，只在检索时被临时引用，数据和答案可控可溯。
• 抑制幻觉：模型不再凭空编造，而是基于检索到的证据来生成，回答可以被追溯到具体的文档来源。

尤其最后一点，对于企业级应用来说几乎是刚需。金融、医疗、法律、政务这些行业，回答必须有出处、可追责、能审查。模型“自由发挥”的后果，轻则闹笑话，重则产生决策风险，这也是为什么 RAG 近两年成了企业落地大模型最主流的技术栈之一。

2. RAG 核心三板斧：索引、检索、生成

RAG 的完整流程可以拆成两条链路。一条是写操作：把文档拆碎、向量化、建索引，我们叫“离线索引”。另一条是读操作：用户提问后，把问题向量化、检索、重排、交给模型生成，叫“在线查询”。

2.1 离线阶段：文档加载、切分、向量化、入库

离线阶段的目标，是把“一堆乱七八糟的原始文档”变成“一个方便快速检索的知识库”。这里面的关键动作我拆开说。

文档加载相对简单，现在主流的框架 LangChain、LlamaIndex 都内置了几十种 Loader，PDF、Word、Markdown、网页、数据库、Notion、飞书都能接。但接进来之后才是重头戏：文本切分（Chunking）。

切分是 RAG 效果好坏的第一道分水岭。为什么一定要切？因为向量检索的粒度问题。一段 5000 字的文章，如果整体向量化，它表达的主题可能是“农业物联网系统的整体架构”，但用户问的是“智能灌溉的传感器阈值设置”，这段文字的平均语义向量就会把细节信息稀释掉。反过来说，如果切得太碎，比如一句话一个 chunk，语义不完整，检索出来也是断章取义。

通用的切分策略是按固定长度 + 重叠窗口来切。比如 chunk_size = 500 字符，overlap = 50 字符，让相邻片段之间保留一定重叠，避免关键信息刚好被截断。更聪明的做法是按文档本身的语义结构来切，比如 Markdown 标题、段落、代码块、表格这些天然分隔符。生产项目中我建议优先结合两者：先按结构切，结构不明确的再用长度切。

切完之后是向量化（Embedding），也就是把每个文本片段用模型转成一串浮点数向量。这一步的核心诉求是：语义相近的文本，向量在空间里的距离也要近。以前做搜索靠关键词匹配，现在做语义检索靠向量距离，这也是 RAG 和传统全文检索最本质的区别。

最后一步是写入向量数据库。这里的选择比较多，常见的有：

• 轻量级：Chroma、FAISS、LanceDB，适合个人项目和快速原型。
• 服务级：Milvus、Qdrant、Weaviate、Elasticsearch 8.x，适合生产环境。
• 云原生：Pinecone、阿里云向量检索服务等，适合不想自己运维的团队。

选择没有绝对优劣，主要看你的数据量、并发量和团队运维能力。如果数据量在百万级以下，Chroma 和 FAISS 完全够用；如果要做高并发在线服务，建议直接上 Milvus 或 Qdrant。

2.2 在线阶段：问题向量化、召回、重排、生成

用户提问之后，系统要做这几件事：

第一步，把用户的问题用同一个 Embedding 模型转成向量。这里有个容易忽略的细节：问题向量化的模型必须和文档入库时用的模型保持一致，否则向量空间都不一样，距离计算毫无意义。

第二步，在向量数据库里做相似度检索，最常用的是余弦相似度和内积距离，返回 TopK 个最相似的文档片段。K 一般取 3 到 10，太小可能漏掉关键信息，太大又容易引入噪声。

第三步，重排（Rerank）。这是很多入门者会跳过、但生产环境不得不做的环节。向量检索已经按语义相似度排过一轮了，为什么还要重排？因为向量检索的“语义相似”不等于“答案相关”。举个我实际遇到的例子：用户问“公司年假制度”，向量检索召回的片段里可能有大量关于“休假申请流程”的内容，语义相近，但不是直接答案。重排模型（比如 BGE-Reranker、Cohere Rerank）会针对候选片段和用户问题的相关性打一个更精确的分数，把最相关的排到最前面。实践经验是，加了 Rerank 之后，回答质量往往有明显提升，值得花这个算力和延迟成本。

第四步，把检索到的内容拼进 Prompt，连同用户问题一起交给大模型。这里有个技巧叫“角色设定 + 上下文约束 + 引用要求”。像我常用的 Prompt 模板风格是：“你是一个智能助手，请仅根据以下参考资料回答问题，如果资料中没有答案，请直接说‘资料库中没有相关信息’，不要编造。回答时尽量注明信息来源。”这一句话就能把幻觉率压下去不少。

2.3 Embedding 模型和重排模型的选型参考

Embedding 模型的质量直接决定检索效果。目前国内能很方便用到的开源模型里，BGE（BAAI General Embedding）系列是绕不开的选择，尤其 bge-large-zh-v1.5，中文语义理解表现不错。国外的话 OpenAI 的 text-embedding-3-small / 3-large、Cohere 的 embed-v3 也很常用。如果数据有强领域属性，比如医疗、法律，强烈建议用领域语料微调过的 embedding 模型，或者在通用模型基础上做无监督微调，效果差异会非常明显。

选 Embedding 模型时，除了看评测指标（MTEB、C-MTEB），还要考虑两个工程指标：一是向量维度，维度越高占用的存储和内存越大；二是推理吞吐，有些模型虽然精度高但推理极慢，在线服务撑不住。

Rerank 模型的选型逻辑相对简单，目前开源里 BGE-Reranker-v2-m3 的性价比很高，很多生产项目都在用。如果预算充足，Cohere Rerank 3 在英文场景下表现也很好。

2.4 为什么说 RAG 是“用工程手段弥补模型缺陷”

把 RAG 整个跑通之后，你会有个很直观的感受：这哪是在调模型，分明是在调管道。确实是如此。

大模型本身的发展方向是扩大参数量、增强推理能力，但它始终绕不开“训练数据截止”和“概率生成”这两个天花板。RAG 选择不跟模型死磕，而是用工程手段把“外部知识”以结构化的方式补充给它。你不需要重新训练模型，也不需要微调参数，只是换了一套“喂数据”的方式，就能让模型在特定领域表现得像专家一样。

这也是今天 RAG 能成为企业落地首选方案的根本原因：成本低、见效快、迭代灵活。知识库内容错了，改文档就行，不用重新训练模型。这一点在业务变化快、知识更新频繁的环境里是极大的优势。

3. 从基础 RAG 到进阶形态：Hybrid、Graph、Agentic 都解决了什么

基础 RAG 能解决 70% 的问题，但如果你把它放到更复杂的真实场景里，很快会遇到新的瓶颈。这几年社区里涌现出一批进阶形态，本质上都是在补基础 RAG 的短板。

3.1 Hybrid RAG：解决向量检索的文科病

向量检索擅长理解语义，但它有个通病：对关键词不够敏感。比如用户搜的是精确型号“CL-2000A”，语义相似的向量可能把“CL2000A”（中间少了杠）给忽略了。再比如一些代码变量、产品编号、化学分子式，本质上是“精确匹配”需求，语义检索反而会帮倒忙。

Hybrid RAG 的解法很直接：把向量检索和传统全文检索（BM25）的结果做融合。BM25 是 ES 等搜索引擎长期使用的经典算法，对精确匹配极其敏感。两条路并行召回，再通过 RRF（Reciprocal Rank Fusion，倒数排名融合）或者加权分数的方式合并结果，取长补短。

这块实际调优时有一个经验：不是简单五五开就完事。不同业务要测权重，比如强代码场景、强编号场景，BM25 权重可能要加大；弱查询意图、口语化问题多的场景，向量权重应该更高。建议搭建系统时保留权重配置接口，方便后续调参。

3.2 Graph RAG：搞定多跳关系和多实体关联

基础 RAG 的另一大短板，是不擅长处理“多跳问题”。什么叫多跳？比如用户问“A 公司收购的 B 公司的核心产品是什么”，答案可能需要跨越多个文档片段拼接：先找到“A 公司收购了 B 公司”的记录，再去另一段文档找“B 公司的产品线”。向量检索按片段独立召回，很难把这些跨片段的线索串起来。

Graph RAG 的思路，是在向量检索之外，再构建一层知识图谱。先用 LLM 从文档里自动抽取实体（公司、人物、产品、事件）和关系（收购、任职、合作），存入图数据库（如 Neo4j），然后在检索时通过图的遍历能力把多跳关系一次性捞出来。等于给检索加了一个“关系网络”的视角，最典型的例子就是微软发布的 Graph RAG 开源项目。

不过 Graph RAG 也有代价：离线构建知识图谱非常耗时，而且依赖 LLM 的抽取质量，信息密度很低的文档强行抽图，结果往往是事倍功半。它更适合知识密集型、强关系型的领域，比如科研文献、金融研报、法律条文，不太适合做一个电商客服问答。

3.3 Agentic RAG：从被动检索升级为主动推理规划

Agentic RAG（智能体 RAG）是最近两年更进阶的方向。基础 RAG 的流程是线性的：问一句，查一次，答一次。Agentic RAG 则是把大模型从“回答问题的人”升级成“主导检索流程的调度者”。

举个例子，用户问“帮我分析一下我们公司近三个季度的销售趋势，顺便总结一下哪些区域增长最快”。如果走基础 RAG，你需要提前解析用户意图、拆解子问题、分别查数据库、再汇总。而 Agentic RAG 模式下，模型自己会做规划：先决定调用哪个检索工具，发现数据不够时再决定换个方式查，甚至能自己反思“刚才检索到的信息似乎不够深入，我应该再查一次季度环比数据”。

这种模式的本质是让 LLM 具备工具调用和计划执行能力，把 RAG 从“一个检索模块”变成“一个自主工作的检索 Agent”。生产落地的复杂度也高不少，你需要管理子任务的状态、控制调用的轮次上限、处理工具异常，稍有不慎模型就会陷入无限循环。我的建议是：如果业务问题结构固定，优先用基础 RAG 或一个简单的多路召回流程；只有问题开放、路径不明确时，才值得引入 Agentic RAG。

3.4 多路召回（Multi-Recall）工程实践

多路召回这个概念，严格来说不是某个 RAG 变体，而是工程上的“组合拳”策略。就是在召回阶段不做单一检索，而是同时跑多路检索器，比如：

• 向量召回 Top10（负责语义相似）
• BM25 全文召回 Top10（负责关键词精确匹配）
• 规则匹配召回 Top5（针对绝对关键字段，比如时间、编号、型号做硬编码过滤）

然后把多路结果合并去重，再全部交给 Rerank 统一重排。这样做的好处是鲁棒性显著提升，万一某一路检索器效果不理想，其他路还能兜底。实践中多路召回的合并策略通常配合 RRF，实现简单且不需要训练。

4. 手把手实战：在本地把一套 RAG 系统跑起来

光讲概念不过瘾，我带你完整过一遍可复现的本地部署流程。这套方案主打免费、私有、可折腾，所有组件都能在普通开发机上跑。

4.1 选型：Ollama + Embedding 模型 + 向量库

我推荐的组合是：

• Ollama：用来跑本地 LLM。
• BGE-M3 或者 bge-large-zh-v1.5：用于文本向量化。也可以直接用 Ollama 里提供的嵌入模型，比如 snowflake-arctic-embed、nomic-embed-text。
• Chroma 或 FAISS：本地向量存储。
• LangChain 或者直接手写调用：来做流程编排。

这个组合的优势是，所有模型和数据都在本机，不用联网、不泄露隐私、不花钱。如果你的本机显卡只有 8GB 显存，建议用 7B-8B 级别量化模型，比如 Qwen2.5-7B-Instruct 的 Q4 量化版本。

4.2 Ollama 部署与模型拉取

Ollama 的安装非常简单，直接去官网下载对应系统的安装包，装完在终端验证：

bash复制ollama --version

然后拉取模型。我习惯用通义千问系列做中文场景，用 Llama 系列做英文场景：

bash复制# 拉取对话模型
ollama pull qwen2.5:7b-instruct

# 拉取嵌入模型
ollama pull nomic-embed-text

拉取完成后，你可以先用命令行验证一下：

bash复制ollama run qwen2.5:7b-instruct "你好，简单介绍一下你自己"

如果终端能正常输出，说明本地模型部署成功。Ollama 默认对外提供服务端口是 11434，后续代码可以直接通过 HTTP 接口调用，非常方便。

4.3 文档处理与向量化入库

我假设你已经有一批文档，比如产品说明、内部制度、课程讲义之类的，格式是 PDF 或 Markdown。下面是一段以 LangChain 为核心的 Python 代码逻辑，完整跑通“加载-切分-向量化-入库”：

python复制from langchain_community.document_loaders import PyPDFLoader, DirectoryLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_ollama import OllamaEmbeddings
from langchain_community.vectorstores import Chroma

# 1. 加载文档目录下的所有 PDF
loader = DirectoryLoader("./docs/", glob="**/*.pdf", loader_cls=PyPDFLoader)
documents = loader.load()

# 2. 切分文本：按长度 500，重叠 50
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50,
    separators=["\n\n", "\n", "。", "！", "？", " ", ""]
)
chunks = text_splitter.split_documents(documents)

# 3. 向量化并入库
embeddings = OllamaEmbeddings(model="nomic-embed-text")
vector_store = Chroma.from_documents(
    documents=chunks,
    embedding=embeddings,
    persist_directory="./chroma_db"
)
print(f"成功入库 {len(chunks)} 个文本块")

这里有几个细节想单独强调。

切分器的 separators 顺序很重要，它决定了切分优先级。我会把换行、段落、句号、问号、感叹号放在前面，优先按完整句意切分，实在不行才按字符硬切。如果文档结构统一，建议把 chunk_size 提高到 800-1000，因为更长的片段能保留更多上下文，但也别太长，超过 1500 之后检出来的内容经常跑偏。

向量化模型这里用的是 nomic-embed-text，它支持 768 维向量，处理中文效果及格。如果要追求更高的中文效果，可以用 BGE-M3，它在很多中英文语义任务上都有更好的表现，只是对硬件要求略高一些。实际项目中我建议先跑通流程，再回头替换更强的 Embedding 模型。

4.4 检索问答：把召回结果交给本地大模型

入库完成之后，就可以实现用户提问、检索、生成的完整流程：

python复制from langchain_ollama import OllamaLLM
from langchain_core.prompts import ChatPromptTemplate

# 加载已有向量库
vector_store = Chroma(
    persist_directory="./chroma_db",
    embedding_function=OllamaEmbeddings(model="nomic-embed-text")
)
retriever = vector_store.as_retriever(search_kwargs={"k": 4})

# 定义提示词模板
prompt = ChatPromptTemplate.from_messages([
    ("system", "你是一个严谨的智能助手。请只依据以下资料片段回答问题。\n"
               "如果资料中没有足够信息，请直接回答“知识库中未找到相关信息”。\n"
               "不要编造，不要添加资料之外的内容。\n\n"
               "资料片段：\n{context}"),
    ("human", "问题：{question}")
])

llm = OllamaLLM(model="qwen2.5:7b-instruct")

def ask_rag(question):
    docs = retriever.invoke(question)
    context = "\n\n".join([doc.page_content for doc in docs])
    chain = prompt | llm
    answer = chain.invoke({"context": context, "question": question})
    return answer, docs

# 测试
answer, docs = ask_rag("我们公司的年假是怎么规定的？")
print("回答：", answer)
for i, doc in enumerate(docs):
    print(f"\n引用片段 {i+1}: {doc.page_content[:80]}...")

跑通这个流程，你就拥有一个最小可用的本地 RAG 系统了。实测下来，在 16GB 内存 + 8GB 显存的机器上，单次问答延迟大概在 3 到 10 秒，答案质量对于常见文档问答场景已经可用。

“引用片段”的输出很重要。千万不要省略这个步骤，它不仅是溯源审计的需要，也是你排查“模型为什么答错”的关键线索。你可以清楚地看到模型是“没检索到正确文档”还是“检索到了但没正确利用”，从而准确定位问题出在索引、召回还是生成环节。

4.5 用 Dify 这类工具快速搭建界面和流程

如果不想写代码，或者业务团队想快速验证效果，目前市面上有很多开源低代码平台可用，最典型的是 Dify。

Dify 这类工具的价值在于，把“文档上传、切片配置、Embedding 模型选择、向量库配置、Prompt 编排、日志观测”这些环节全部图形化，业务人员也能很快上手。很多政务、企业内部的 RAG 知识库项目，都是用 Dify 这类平台快速搭出来的。你不需要自己维护向量库和编排代码，平台帮你封装好了，只需要专注在知识库内容和效果调优上。

用 Dify 建知识库的核心步骤大致是：

• 创建知识库，上传领域文档。
• 选择 Embedding 模型，可以填你本地部署的 Ollama 地址。
• 配置分段设置（chunk size、overlap）和索引方式。
• 创建应用，选择“聊天助手”或“Agent”类型。
• 在提示词编排里把知识库检索加进去。
• 最后把大模型 API 配置指向你的本地 Ollama，就能跑起来。

这套方案在组织内部的规章制度问答、企业知识分享、制度查询等场景非常落地。但要注意，低代码平台虽然快，一旦深度定制需求出现（比如复杂权限、特殊召回策略），平台本身的抽象层反而可能成为掣肘。建议小团队或验证阶段用 Dify，核心业务还是要留好自研后路。

5. 效果调优与评测：怎么让自己做的 RAG 越来越准

搭好一套 RAG 不难，难的是让它在各种刁钻问题上都答得漂亮。这一节集中讲我在实际项目中反复踩过的坑，以及对应的排查和调优方法。

5.1 检索质量差，先别急着换模型，检查这三个环节

如果模型回答经常说“资料里没有”，或者答非所问，我的排查顺序永远是：

先看召回内容。把用户问题对应的检索结果直接打印出来，人眼判断召回的片段相不相关。如果召回的片段本身就跑题，那问题一定在索引阶段，而不是生成阶段。

再看切分粒度。一个很容易犯的错：一个 chunk 太长，比如一篇 2000 字的文档整体作为一个向量，细节信息被稀释；或者太短，一句话一个 chunk，语义破碎。调试方法很简单，多切几组不同 chunk_size，跑同一批测试问题，对比效果。

再看 Embedding 模型与数据的匹配度。通用模型在专业术语丰富的领域（医学、法律、代码）表现通常一般。一个可操作的判断标准：拿 50 个典型问题，人工标注召回结果，如果召回的 Top1 正确率低于 60%，就该考虑领域适配了。

5.2 Rerank：性价比最高的效果提升手段

很多初学 RAG 的人会把大量精力花在调 Prompt 上，但真正常被忽视的瓶颈是召回的排序质量。向量检索的 TopK 结果里，前几名可能相关，后面几名就开始跑偏。如果直接把 TopK 全部塞给大模型，大模型很容易被不相关信息干扰。

Rerank 的价值就在这里。它不是重新检索，而是在“已有候选集”内部做一次更精细的相关性排序。我的常用配置是：先向量召回 Top20，再用 Rerank 模型取前 5 名作为最终上下文。这样既能保证候选集的召回率，又能在最后关头保证精度。

BGE-Reranker 的用法很简单，HuggingFace 上直接可以加载：

python复制from sentence_transformers import CrossEncoder

reranker = CrossEncoder("BAAI/bge-reranker-v2-m3")
pairs = [[question, doc] for doc in candidate_docs]
scores = reranker.predict(pairs)
top_indices = sorted(range(len(scores)), key=lambda i: scores[i], reverse=True)[:5]

加上 Rerank 之后，很多项目的效果提升肉眼可见，而且改动量很小。如果让我给 RAG 优化建议排序，我会把“加 Rerank”放在前三。

5.3 建立评测集，用数据而不是感觉来调优

个人项目或小团队做 RAG，最常见的误区是“感觉变好了”。今天改一下切分，明天换一个 Embedding 模型，完全凭感觉判断好坏，最后根本不知道哪个改动起了作用。想要把 RAG 做好，一定要建立属于自己的评测集。

评测集不需要很大，50-100 条典型问题就够。建议覆盖四类：

• 高频常见问题：用户最常问的那些。
• 复杂推理问题：需要多段信息拼合才能回答的。
• 边缘情况：知识库中确实没有答案的问题，看系统会不会不懂装懂。
• 时效性问题：验证知识库更新后，答案是否随之变化。

评测指标可以分两块看。第一块是检索质量指标，用 Recall@K 和 MRR（Mean Reciprocal Rank）；第二块是生成质量指标，人工打三个分：答案准确性、帮助性、来源可追溯性。每次改动完模型或流程，拿同一套评测题跑一遍，记录分数对比。做到这一步，你的 RAG 项目就已经超过绝大多数停留在“能跑”阶段的团队了。

5.4 常见问题速查表

我把高频问题和排查方向整理成一张表，方便你对照：

5.5 Query 改写：一个容易被忽略的细节

再说一个实用技巧：用户真实问法往往非常口语化，比如“咱这加班咋算钱”，知识库原文可能是“根据《薪酬管理制度》第三章，工作日在法定标准工作时间以外延长工作时间的，按照本人小时工资标准的 150% 支付加班工资”。这两个句子在语义向量上距离不算近，直接检索容易召回失败。

常见的解法是在检索前让 LLM 把用户问题改写成一个更完整、更规范的查询语句，或者采用 HyDE（Hypothetical Document Embeddings）的思路：先让 LLM 生成一个假设性回答，再用这个回答的向量去检索，从而提高召回匹配率。代价是多一次 LLM 调用，换来的是检索效果提升，在很多场景下值得。

6. 关于 RAG 和微调，谁更适合你的场景

聊到最后，很多人都会问一个问题：我有领域知识，到底应该做 RAG，还是微调大模型？

我的看法是：先想清楚你的目标是“让模型知道某件事”还是“让模型用某种方式做事”。

RAG 擅长解决“知识问题”。它负责给模型提供它原本不知道的事实，比如你们公司的制度、某个产品的手册、最新发布的研究报告。这些内容更新频繁、形式多样，用 RAG 管理最灵活，成本最低。

微调擅长解决“行为问题”。比如你希望模型的输出风格固定为客服话术、希望模型严格输出 JSON 格式、希望它学会某个特定领域的推理模式和行话表达。这些“行为习惯”层面的东西，靠 Prompt 或者 RAG 很难稳定约束，微调是更合适的手段。

实际生产中，两者不是二选一，而是配合使用。常见做法是：用微调让模型“懂规矩”（格式、语气、基础领域素养），再用 RAG 给它“递资料”（事实、数据、最新信息）。我自己经手的项目里，大多数效果最好、上线最稳的架构都是这种“双轨制”。

还有一个经常被追问的取舍问题：RAG 会不会让回答失去模型原有的“聪明”能力？答案是有可能。因为加了检索上下文之后，Prompt 变长，模型注意力会被分散，所以在设计 Prompt 时要格外注意：给出的资料片段必须高度相关，不要一股脑塞五六个无关片段进去“凑数”。资料宁缺毋滥。

另外要认清一点：RAG 也不是万能的。如果知识库本身质量差、内容互相矛盾，检索出来的“证据”本身就不可靠，那模型再强大也只能跟着错。知识库的治理是 RAG 效果的天花板，这一点怎么强调都不为过。我见过太多项目在模型和流程上反复调优，最后发现源头是文档本身写得乱。先把文档结构理清楚，再谈 RAG 调优，顺序不能反。

根据我个人的项目经验，最稳妥的落地路径是：先拿一个最小的数据集，把全流程跑通，验证 RAG 能解决你的核心问题；再逐步扩充知识库，不断用评测集迭代调优；最后再考虑上微调、Agent 这些进阶手段。别一上来就追求大而全的架构，RAG 这事的复杂度是随着数据量和问题类型慢慢长出来的，你留好扩展空间，后面才不会推倒重来。