RAG知识库问答系统落地：从向量检索到上下文增强的全链路实践
RAG知识库问答系统落地：从向量检索到上下文增强的全链路实践
别只调API了，给大模型配上“外脑”
这两年大模型火得一塌糊涂，很多人张口就是“接个API就行”。但真正落地时你会发现一个残酷现实：GPT再聪明，对你公司的内部资料也一无所知。你问它“咱们的报销流程是什么”，它只能根据通用经验开始“编”——编对了是运气，编错了就是事故。
检索增强生成（RAG）正是为解决这个问题而生的。它的核心理念很简单：先检索，后生成。用户提问时，系统先从知识库中找出相关资料，再把这些资料和问题一起喂给大模型，让它“开卷答题”。
整个过程像极了考试：向量检索是翻书找答案，大模型生成是把找到的内容组织成通顺的答案。本文将带你走通这条全链路——从文档预处理、向量化存储，到检索优化与答案生成，用代码说话。
一、离线篇：把文档变成可检索的“记忆”
RAG系统分为两条并行的流水线：离线处理文档，在线处理问答。
离线阶段的目标是：把杂乱的非结构化文档，变成向量数据库里的结构化索引。
1. 文档解析与切片
原始文档可能是PDF、Word、Markdown，需要先提取出纯文本内容。这一步看似简单，实则影响全局——解析质量决定了后续切分和检索的上限。
拿到文本后，不能整篇塞进模型——上下文窗口装不下，检索精度也差。文档切片（Chunking）是RAG最基础也最容易被忽视的环节。切得太粗，检索粒度不够；切得太细，丢失上下文信息。
一般建议初始chunk size设为300~800个中文字符，再根据业务效果调整。同时设置重叠区域（overlap），避免语义在切分边界处断层。
fromlangchain.text_splitterimportRecursiveCharacterTextSplitter text=open("knowledge.txt","r",encoding="utf-8").read()splitter=RecursiveCharacterTextSplitter(chunk_size=500,# 每块500字符chunk_overlap=100# 块间重叠100字符，保持语义连贯)docs=splitter.create_documents([text])print(f"切分为{len(docs)}个文本块")2. 向量化：把文字变成可计算的数字
计算机不懂语义，但向量可以表达语义。Embedding模型将文本映射到高维空间中的向量，语义相近的文本在向量空间中也彼此接近。
fromsentence_transformersimportSentenceTransformerimportnumpyasnp model=SentenceTransformer("shibing624/text2vec-base-chinese")texts=[doc.page_contentfordocindocs]embeddings=model.encode(texts)# 每个文本变成一个稠密向量print(f"向量维度:{embeddings.shape[1]}")3. 向量存储：给知识库建“索引”
生成的向量需要存入向量数据库供后续检索。FAISS、Chroma、Milvus、pgvector都是常用选项。下面以FAISS为例，构建一个本地向量索引：
importfaiss dimension=embeddings.shape[1]index=faiss.IndexFlatL2(dimension)# L2距离作为相似度度量index.add(np.array(embeddings).astype("float32"))print(f"向量库已入库{index.ntotal}条记录")至此，离线阶段完成：原始文档变成了可语义检索的向量索引。
二、在线篇：从用户问题到精准答案
4. 向量检索：找到“最相关”的知识片段
用户输入问题后，系统做三件事：把问题也转成向量，用这个向量去数据库里“按语义”搜索最相似的K个片段，再把检索到的片段作为上下文传递给大模型。
defretrieve(query:str,top_k:int=3):# 1. 问题向量化query_vec=model.encode([query])query_vec=np.array(query_vec).astype("float32")# 2. 相似度检索distances,indices=index.search(query_vec,top_k)# 3. 返回最相关的文本片段return[texts[i]foriinindices[0]]query="报销超过5000元需要谁审批？"results=retrieve(query)forrinresults:print(f"-{r}")5. 上下文增强：让大模型“开卷答题”
检索到的内容不能直接给用户看，需要把它们拼接成增强后的Prompt，让大模型基于这些资料作答，而不是凭空发挥。
importopenaidefask(query:str):# 检索相关内容context_chunks=retrieve(query,top_k=3)context="\n".join(context_chunks)# 构造增强 Promptprompt=f""" 你是一个企业知识库助手。请只根据以下资料回答问题。 如果资料中没有答案，请回答"根据已有资料无法确定"。 资料：{context}用户问题：{query}"""# 调用大模型生成答案response=openai.ChatCompletion.create(model="gpt-4o-mini",messages=[{"role":"user","content":prompt}])returnresponse["choices"][0]["message"]["content"]print(ask("报销超过5000元需要谁审批？"))此时大模型输出的不是“猜”的答案，而是“基于资料”的答案。这正是RAG的核心价值：用检索结果约束生成范围，从根本上抑制幻觉。
三、落地进阶：让RAG真正“好用”
上面是最简实现，但真实项目90%的精力都花在优化上。下面是几个常见优化方向：
1. 检索质量优化：HyDE与多路召回
传统检索的问题是：用户问法和文档写法对不上，检索就漏了。HyDE（Hypothetical Document Embeddings）的思路是：检索前先用大模型生成一份“假设答案”，然后用假设答案去做向量检索，而不是直接用原始查询。这样检索的是“理想答案长什么样”的语义，而不只是关键词层面的匹配。
此外，混合检索（向量检索 + BM25关键词检索）可以兼顾语义匹配和精确匹配，再用Rerank模型对多路召回结果统一排序，进一步提升命中质量。
2. Chain策略：平衡效果与成本
LangChain提供了几种不同的“检索-生成”组合策略：
| Chain类型 | 调用次数 | 特点 | 适用场景 |
|---|---|---|---|
| stuff | 1次 | 把所有块一次性喂给模型 | 块数少、总token可控时效果最佳 |
| map_reduce | N+1次 | 每块单独处理后再归纳 | 需要处理大量文档时 |
| refine | N次 | 串行迭代优化答案 | 对答案精度要求极高时 |
默认的stuff方式效果最好、成本最低，前提是检索到的块数不要撑爆上下文窗口。
3. 来源追溯：让答案“可验真”
企业场景下，用户需要知道答案出自哪份文档的哪一页。在索引时存储每个片段的元数据（文档名、页码、章节标题），检索时一并返回，就能实现“引用来源”的功能。
-- 表结构示意：为每个块存储来源元数据CREATETABLEdocument_chunks(idSERIALPRIMARYKEY,contentTEXTNOTNULL,embedding vector(1536),document_titleTEXT,page_numberINTEGER,section_titleTEXT);写在最后
RAG不是“接个API就完事”的黑盒，而是一个需要精细打磨的工程系统。它融合了信息检索（什么文档相关）、提示工程（怎么组织上下文）和模型调用（怎么生成答案）三个层次的知识。
一个好的RAG系统，能让大模型像专家一样回答问题——有据可依、来源可查、内容可靠。而一个粗糙的RAG系统，充其量只是个高级“拼接器”。
差异就在细节里：切块策略是否合理？Embedding模型是否匹配业务领域？检索结果是否经过了Rerank清洗？上下文是否被有效组织？把这些链路一步步走通、走深，大模型才能真正成为企业的生产力工具，而不是一个华而不实的“玩具”。