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