做应用开发这两年，我身边几乎每个团队都在琢磨同一个问题：怎么让大模型真正回答“我们自己”的业务问题。模型参数越做越大，能力也确实强，但当你问它公司内部最新的审批流程、产品手册里的参数细节、项目文档里的历史决策，它要么一句“我不确定”，要么就一本正经地给你编一个看起来合理、实则完全经不起推敲的答案。这就是大模型知识库问答最核心的痛点。RAG（Retrieval-Augmented Generation，检索增强生成）就是冲着这个问题来的——先从一个外部知识库里把和问题相关的资料检索出来，再把这部分资料作为上下文交给大模型生成答案。这篇文章是我从零搭一套知识库问答系统的完整记录，包含架构拆解、代码实现、参数调优和踩坑经验，适合正在做RAG应用开发、被模型幻觉和知识过期问题反复折磨的开发者，也适合产品和技术负责人用来判断方案是否可行。
1. 先想清楚一件事：为什么非要用RAG搭建问答系统
很多人一上来就选技术栈、写代码，结果搭出来的系统效果稀烂，回头才发现根因是没想明白RAG到底在解决什么。所以这一节先从本质说起。
1.1 大模型直接做问答，痛点比想象中多
先说最直观的问题：知识过期。任何模型的训练数据都有截止时间，你拿上个月的行业政策、公司内部刚发布的规范去问它，它不可能知道。第二个问题是私有数据隔离。企业内部的知识库、研发文档、客户对话记录，这些数据不可能也不应该进入模型的训练集，模型天然接触不到。第三个问题最致命——幻觉。大模型的本质是概率生成，它会在不确定的时候自动“补全”一个最合理的答案，而不是诚实地告诉你“我不清楚”。我见过最典型的一个案例：有人拿一套内部报销制度问模型，模型非常流畅地回答了报销额度、所需材料、审批时长，连表格格式都画出来了，但里面一半内容是它自己编的。这种答案如果被当成制度执行，后果非常严重。
这三个痛点不是调大模型参数能解决的。你把模型从几百亿参数换到上千亿参数，它依然不知道你公司内部文档长什么样；你给它写再多系统提示词约束“不要胡说”，它在面对未知信息时还是会倾向编造，因为它的训练目标就是生成通顺的文本，而不是查证事实。
1.2 RAG的本质：把闭卷考试变成开卷考试
RAG解决上述问题的方式非常朴素：模型不需要“记住”你的知识，你直接把知识递到它面前。具体流程分两步——第一步是检索，用户提问后，系统先从知识库里找出和问题最相关的若干段文本；第二步是生成，把检索到的文本和原始问题拼成一个Prompt，交给大模型，让它基于给定的材料回答。这就像考试时，闭卷和开卷的区别。闭卷时学生只能靠记忆硬编，编不出来就只能胡写；开卷时学生手边有教材，回答自然有据可依。
这个设计带来的实际好处有三点。第一，知识实时可更新。知识库里的文档变了，重新索引一遍就行，模型本身不用动，成本和风险都低。第二，答案可溯源。你可以把模型引用的原文片段一并展示给用户，回答错了能追责、能定位。第三，成本可控。相比用大量业务数据做微调，RAG只需要维护一套检索系统，不需要训练资源。基于这些原因，RAG几乎是现阶段做知识库问答、智能客服、文档辅助阅读等应用的主流选择。
1.3 RAG和微调怎么选，别一上来就走错路
我经常被问“我这个场景到底该用RAG还是微调”，这其实是个伪选择题。两者解决的问题不在一个维度：RAG解决的是“模型不知道这些知识”，微调解决的是“模型不擅长按这种风格/格式输出”。判断标准很简单——如果核心诉求是让模型知道更多内容，选RAG；如果核心诉求是让模型以特定口吻、特定格式完成某种任务，选微调。比如要求模型把答案统一输出成JSON结构、咨询话术要贴合品牌风格，微调更直接；要求模型回答企业内部的制度问题，RAG更合适。
我个人的建议是，大部分业务场景优先RAG，因为它的迭代成本低、效果可解释。只有当RAG的检索质量已经做到极限、但生成效果仍然不达标，或者你发现模型需要掌握的规范本身已经固化、几乎不变更时，再考虑微调。两个方案不冲突，可以叠加使用：先用微调让模型学会输出格式，再用RAG给它补充知识。
2. RAG核心架构拆解：五个环节决定最终效果
一个成熟的RAG系统，从搭建到上线会经过五个核心环节：文档加载与清洗、文本切分、向量化、向量存储与检索、生成组装。任何一个环节出了问题，最终答案质量都会断崖式下降。下面逐个拆。
2.1 文档加载与清洗：源头决定上限
知识库里的源文件永远比你想象得脏。PDF有扫描版、有文字版，扫描版要OCR，文字版又经常带页眉页脚；Word文档里有批注和隐藏内容；网页导出的HTML里全是标签；表格数据在提取时经常丢掉行列关系。如果这些脏数据不处理，后面所有环节都会继承问题。做题切分时，可能把页眉“公司内部资料-请勿外传”和正文混在一起，最终检索到的是一堆无意义文本；做向量化时，噪声还会稀释真正的语义信息。
所以文档加载阶段一定要建立清洗规则。我常用的思路是：统一编码格式，去掉页眉页脚、水印和页码；把表格单独识别出来，尽量转成保留行列结构的Markdown表格，而不是拍扁成纯文本；对扫描版PDF先做OCR识别，至少要有预案；最后抽取每篇文档的标题、作者、日期等元数据，这些后面做过滤非常好用。这个阶段没什么高深技术，但直接影响上限，值得花时间。
2.2 文本切分：Chunk大小是第一个火葬场
把长文档切成小段是RAG里坑最多的环节。切小了，一段文本承载的语义不完整，检索召回的片段信息量不够，模型拿到手也不知道你在说什么；切大了，一段文本里混杂多个主题，向量化之后语义被稀释，检索时匹配不上精确内容。我见过一个团队用固定的每段1024字去切技术手册，结果一条操作说明跨在两个chunk里，怎么检索都缺一半，生成出来的步骤自然没法用。
正确的做法是“结构化优先”。如果文档本身有章节结构，比如Markdown文件按标题切分、PDF按段落切分，优先按结构边界切，而不是按字符数硬切。其次再设置一个合理的chunk大小，比如256到512个token之间，同时给相邻chunk加一部分重叠（overlap），避免切断语义。重叠的具体数值可以设为chunk大小的10%到20%，它的作用是让跨越边界的信息至少在一个chunk内是完整的。切完之后记得抽样检查：随便打开几十个chunk，看它们是不是都能独立读懂，这是最直接的验证方式。
2.3 向量化：Embedding模型决定了语义理解的边界
文本切好之后，下一步是把每段文本转成向量。Embedding模型的本质是把一段文字映射到一个高维向量空间，让语义相近的文本在空间里距离更近。这个环节决定了系统“理解语义”的能力上限——向量化能力不行，后面检索再优化也白搭。
选Embedding模型时，中文场景和英文场景差别很大。英文模型对中文的支持往往一般，评测指标好看，实际检索中文文档时效果很差。我建议优先选择在中文语料上训练或经过中文优化的模型，并且在自己的业务文档上实测。向量维度也需要关注：维度越高，表达能力越强，但存储和计算开销越大。常见的中文Embedding模型维度从几百到几千都有，小规模知识库感受不到差异，一旦文档量到百万级，维度差距会直接反映在索引构建速度和检索延迟上。
2.4 向量存储与检索索引：速度和精度之间的平衡
向量存到哪、怎么索引，是RAG系统能不能从小规模Demo走向生产环境的门槛。几十万条向量随便暴力遍历都能接受，到了百万级、千万级，就必须用ANN（近似最近邻）索引。开源的向量数据库里，HNSW是效果最稳的一种索引算法，它在图结构上跳转搜索，检索速度快、召回率高，代价是构建索引时内存开销大；IVF则先聚类再在类内搜索，节省资源但精度略低。实际项目里我通常会先用HNSW把效果跑通，再根据数据规模考虑换策略。
检索时还有两个细节容易被忽略：一是元数据过滤，比如只查某个部门文档、某个时间段内容，先缩小候选集再算相似度，能大幅提升速度和准确率；二是混合检索，光靠向量匹配在精确关键词场景下会吃亏，比如查“RPA-2024-001”这样的编号，向量检索很难精确命中，但传统的关键词检索一搜一个准。所以生产级方案经常是“关键词召回+向量召回”并行，再把结果合并去重。
2.5 生成层的组装：检索结果怎么变成Prompt
检索做得好，结果进不了生成层也一样白搭。生成层的核心工作有两件：一是从召回的Top-K条结果里筛出真正有用的内容，二是把它们组织成让模型“只说范围内的话”的Prompt。
Top-K的选择需要平衡：K太小，上下文信息不足；K太大，无关片段混进来，反而干扰生成。我通常把K初始设为4到6，再根据效果调整。更进阶的做法是加一个重排序（Rerank）环节：召回阶段先用向量粗筛出几十条候选，再用一个专门的重排序模型精排，挑出最相关的几条送进Prompt。这多花一次模型调用，但效果提升非常明显，尤其适合文档量大、内容重叠多的场景。
Prompt模板要明确三件事：第一，给出完整的上下文材料；第二，明确指令——“只根据以下资料回答，如果资料中没有答案，直接说明不知道”；第三，要求附上引用来源的编号。这样既减少幻觉，又让答案可溯源。
3. 从零搭建RAG问答系统：完整实操路线
这一节直接上代码。我以Python为例，环境准备到检索生成全流程走一遍。代码是经过简化的，但骨架完全可以用在生产项目里，你只需要把其中标注的模型服务地址和数据路径换成自己的。
3.1 环境准备与基础配置
开始之前先确认三样东西：Python 3.10以上环境、一个可用的Embedding模型接口、一个大模型生成接口。Embedding模型可以用开源的中文模型本地部署，也可以用API服务；生成模型同理。基础依赖装这几个就够。
pip install numpy pip install 向量数据库客户端库 pip install 大模型SDK pip install pypdf配置信息集中放一个文件里，方便调试：
# config.py EMBEDDING_API_URL = "http://your-embedding-service/v1/embeddings" EMBEDDING_MODEL = "your-chinese-embedding-model" EMBEDDING_DIM = 768 LLM_API_URL = "http://your-llm-service/v1/chat/completions" LLM_MODEL = "your-llm-model-name" VECTOR_COLLECTION = "business_knowledge_v1" TOP_K = 5 CHUNK_SIZE = 400 # 按token估算 CHUNK_OVERLAP = 60CHUNK_SIZE这里设置成400左右，对大部分文档来说语义完整性和匹配精度比较均衡。
3.2 第一步：知识库预处理Pipeline
预处理管线的职责是“文档进来，向量出去”。加载、清洗、切分、向量化、入库，按顺序走。
from config import * def load_and_clean_pdf(file_path): # 用PDF解析库提取文本，保留换行信息 raw_text = extract_text(file_path) # 清洗：去页眉页脚、统一空白、去特殊字符 lines = [l.strip() for l in raw_text.split("\n") if not is_header_or_footer(l)] return "\n".join(lines) def split_into_chunks(text, chunk_size=CHUNK_SIZE, overlap=CHUNK_OVERLAP): chunks = [] start = 0 tokens = tokenize(text) # 按token切分，中文可按字或词 while start < len(tokens): end = min(start + chunk_size, len(tokens)) chunks.append(deserialize(tokens[start:end])) start = end - overlap if end < len(tokens) else end return chunks切分这里我特意保留了overlap逻辑。你把起始位置回退一段再切下一个chunk，就能保证被切断的句子大概率在下个chunk的开头重新出现，信息不容易丢。
向量化和入库也很直接：
def embed_and_store(chunks, metadata_list): vectors = [] for c in chunks: vec = call_embedding_api(c, EMBEDDING_MODEL) vectors.append(vec) # 写入向量数据库，metadata里带上文档名、章节、页码 collection.insert( ids=[f"{doc_id}_{i}" for i in range(len(chunks))], embeddings=vectors, documents=chunks, metadatas=metadata_list, )这里强调一点：metadata一定要写全。文档名、二级标题、页码、更新时间，这些字段将来在过滤和溯源展示时都非常有用，现在嫌麻烦少写了，后面排查问题会花更多时间。
3.3 第二步：检索模块实现
检索模块接收用户问题，返回候选文档片段。核心逻辑是：把问题向量化，去向量数据库里做相似度搜索，再合并可选的关键词召回结果。
def retrieve(query, top_k=TOP_K): # 问题向量化 q_vec = call_embedding_api(query, EMBEDDING_MODEL) # 向量检索，默认按余弦相似度排序 hits = collection.query( query_embeddings=[q_vec], n_results=top_k * 2, # 先多召回，后面可以过滤 include=["documents", "metadatas", "distances"], ) # 按相似度阈值过滤掉明显无关的结果 filtered = [ h for h in hits if h["distance"] < 0.35 # 阈值需要按实际分布调整 ] return filtered[:top_k]如果加了关键词检索，就把两边结果做加权合并。一个经验值：关键词命中的结果相似度给固定加分，最终排序用“向量分×0.7 + 关键词命中分×0.3”这类公式，具体权重按业务调。
3.4 第三步：Prompt构造与答案生成
检索结果到手后，把它们拼进Prompt里，调用大模型。
def build_prompt(query, retrieved): contents = [] for i, r in enumerate(retrieved): contents.append(f"[{i+1}] {r['document']}") context = "\n\n".join(contents) prompt = f"""你是一个知识库问答助手。请只根据以下资料回答问题。 资料： {context} 问题：{query} 要求： 1. 只能依据上述资料回答，不得使用资料之外的信息； 2. 如果资料中没有答案，直接回答“资料中未找到相关信息”； 3. 在答案末尾标注引用的资料编号，如[1][2]。 """ return prompt def generate_answer(query, retrieved): prompt = build_prompt(query, retrieved) response = call_llm_api( LLM_MODEL, messages=[{"role": "user", "content": prompt}], temperature=0.2, stream=False, ) return response["choices"][0]["message"]["content"]这里temperature设成0.2，是为了在保留一定灵活性的同时，减少模型自由发挥。如果你发现答案还是偏发散，可以继续调低到0。另外一个细节是要求模型标注引用编号，这不光是为了展示，更重要的是逼着模型逐条对照资料，降低编造概率。
3.5 端到端跑通一次问答
把所有模块串起来，就是完整的问答链路：
def answer_question(query): retrieved = retrieve(query) if not retrieved: return "未在知识库中找到相关信息。" answer = generate_answer(query, retrieved) return {"answer": answer, "sources": retrieved}跑一个真实的例子，假设知识库里有一份《员工差旅报销制度》，你问“出差住宿标准是多少”，链路会经历：问题向量化 → 向量检索召回制度里“住宿标准”所在的那几个chunk → Prompt组装 → 模型基于这些chunk给出具体金额和超标说明 → 标注引用编号[2][3]。这样的回答哪怕细节有出入，你也可以马上回头检查对应chunk的内容，定位根因。
4. 常见问题与排查技巧实录
这一节是我实际踩坑最多的地方。RAG系统的坑不会写在任何官方文档里，只能靠一个问题一个问题磨出来。
4.1 检索结果不相关：先查切分和Embedding
症状是召回的前几条结果跟问题完全不搭边。排查顺序我固定是：先看切分，再查Embedding，最后查阈值。
切分出问题最常见。文档是按固定长度硬切的话，一个chunk里可能混着三个不同主题，向量化后成了一个“四不像”向量，什么都能沾点边，什么都匹配不准。这时先换成结构化切分，让每个chunk对应一个完整章节或段落。Embedding出问题的情况更多出现在中文场景：你用了英文友好的Embedding模型，对中文口语化提问匹配能力很差。换一个中文优化的模型，或者尝试在chunk文本末尾加上文档标题作为补充语义，都能改善。阈值则是另一个隐藏坑：有的系统把相似度阈值定得太高，导致什么都召不回；定得太低，又什么垃圾都进Prompt。建议把检索结果的相似度分布打出来看一眼，再决定阈值。
4.2 答案还是胡说八道：问题出在上下文约束
明明检索出来的资料是对的，生成答案还是不对，甚至出现了资料里根本没有的内容。先说结论：八成是你Prompt里的约束不够硬。只写“请回答”是远远不够的，模型会把你的资料当成可选项而非唯一依据。我处理这类问题的方法是三重收紧：一是在Prompt里显式声明“你只能使用以下资料”；二是要求“如果资料中没有相关信息，请直接说明，不要编造”；三是通过引用编号机制，逼模型把答案锚定在具体资料上。
还有一种情况是检索出来的资料本身就不对，但你被“看起来相关”骗了。比如一个chunk里既有住宿标准又有餐饮标准，检索命中是因为那段文本同时提到了两个话题，模型分不清该用哪部分。这种情况的解法是回到切分环节，把chunk再切细一些，或者用重排序模型把真正与问题高度相关的chunk排到前面。
4.3 响应太慢：性能优化三板斧
问答系统响应延迟主要来自三个环节：检索、Embedding调用、大模型生成。首屏体验从几秒到十几秒的差距，基本都出在这三块。
第一板斧是缓存。同一个问题或语义相近的问题，在检索层面做结果缓存，能省掉大量重复计算。我实现过一个简单缓存：把问题的Embedding向量做近似去重，命中缓存就直接走生成，实测检索延迟降低近八成。第二板斧是异步和并发。文档加载、向量化入库这些集群操作全部异步化，不要让用户在一条链路里等全量处理；大模型生成用流式输出，先把首字吐出来，再用流式补全，用户体感会好很多。第三板斧是把检索范围缩小。利用metadata过滤，把百万级候选先压到十万级，再去做向量计算，速度快一个量级。还有一个细节：对访问频次高的热门文档，把它们Embedding预加载进内存，避免每次都走磁盘索引。
4.4 效果没法量化：搭建一套最小评估集
很多团队做完RAG只靠“点几个问题试试”来判断效果，这非常危险。你试的这五个问题恰好是知识库里最规整的，上线后真实用户五花八门的问题一来，效果立刻崩。正确的做法是维护一个最小评估集，包含三类问题：知识库内能找到答案的问题、跨章节多跳问题、知识库内根本没有答案的问题。每类准备20到30条，每条标注标准答案和对应的源文档位置。
评估指标建议同时看两个层面：检索层面看命中率，也就是标准答案对应的chunk有没有被召回；生成层面看忠实度，也就是模型答案和检索资料是否一致，有没有编造内容。每改一次切分参数、换一次Embedding模型、调一次Prompt，都拿这套评估集跑一遍，分数涨没涨一目了然。这套评估集规模不用大，但要持续迭代，我自己的经验是维护到100条左右，就足够指导绝大多数调优决策了。
5. 个人实操体会与后续可以扩展的方向
这套系统从零到上线，我最大的体会是：RAG的效果好不好，七成取决于数据工程，三成取决于模型选择。很多人迷信换个更强的生成模型就能解决一切，实际上绝大多数问题出在前面——文档脏、切分烂、检索弱，再强的模型也只能在垃圾上下文里做文章。反过来，你把知识库的组织做好、检索做精准，哪怕生成模型不是顶配，出来的答案也足够可靠。
还有一点想提醒大家：RAG不是一次性工程。知识库在持续增长，用户提问方式在不断变化，系统上线那天只是开始。我后来在项目里又加了两个能力，效果提升明显：一是query改写，用户问“住宿超标了怎么处理”这种不精确问题时，先让模型把问题拆解或改写成几个明确的检索子问题，再去知识库里查，召回质量直接上一个台阶；二是增量更新机制，新文档进来只对新chunk做Embedding入库，不做全量重建，配合定期对旧文档做一致性检查，保证知识库不腐化。
如果你准备在自己的项目里落地RAG，我的建议是不要一上来就追求大而全的架构。先拿几十篇核心文档，把“加载-切分-向量化-检索-生成”这条最小链路跑通，用评估集把效果调到合格，再逐步加混合检索、重排序、query改写这些进阶组件。每一步加完都要回测，确认它是真的在加分，而不是在制造复杂度。这样搭出来的系统，可靠性和可维护性都会好很多。
