RAG知识库问答系统落地：从向量检索到上下文增强的全链路实践
别只调API了，给大模型配上"外脑"
这两年大模型火得一塌糊涂，很多人张口就是"接个API就行"。但真正落地时你会发现一个残酷现实：GPT再聪明，对你公司的内部资料也一无所知。你问它"咱们的报销流程是什么"，它只能根据通用经验开始"编"------编对了是运气，编错了就是事故。
检索增强生成（RAG）正是为解决这个问题而生的。它的核心理念很简单：先检索，后生成。用户提问时，系统先从知识库中找出相关资料，再把这些资料和问题一起喂给大模型，让它"开卷答题"。
整个过程像极了考试：向量检索是翻书找答案，大模型生成是把找到的内容组织成通顺的答案。本文将带你走通这条全链路------从文档预处理、向量化存储，到检索优化与答案生成，用代码说话。
一、离线篇：把文档变成可检索的"记忆"
RAG系统分为两条并行的流水线：离线处理文档，在线处理问答。
离线阶段的目标是：把杂乱的非结构化文档，变成向量数据库里的结构化索引。
1. 文档解析与切片
原始文档可能是PDF、Word、Markdown，需要先提取出纯文本内容。这一步看似简单，实则影响全局------解析质量决定了后续切分和检索的上限。
拿到文本后，不能整篇塞进模型------上下文窗口装不下，检索精度也差。文档切片（Chunking）是RAG最基础也最容易被忽视的环节。切得太粗，检索粒度不够；切得太细，丢失上下文信息。
一般建议初始chunk size设为300~800个中文字符，再根据业务效果调整。同时设置重叠区域（overlap），避免语义在切分边界处断层。
python
from langchain.text_splitter import RecursiveCharacterTextSplitter
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模型将文本映射到高维空间中的向量，语义相近的文本在向量空间中也彼此接近。
python
from sentence_transformers import SentenceTransformer
import numpy as np
model = SentenceTransformer("shibing624/text2vec-base-chinese")
texts = [doc.page_content for doc in docs]
embeddings = model.encode(texts) # 每个文本变成一个稠密向量
print(f"向量维度: {embeddings.shape[1]}")3. 向量存储：给知识库建"索引"
生成的向量需要存入向量数据库供后续检索。FAISS、Chroma、Milvus、pgvector都是常用选项。下面以FAISS为例，构建一个本地向量索引：
python
import faiss
dimension = embeddings.shape[1]
index = faiss.IndexFlatL2(dimension) # L2距离作为相似度度量
index.add(np.array(embeddings).astype("float32"))
print(f"向量库已入库 {index.ntotal} 条记录")至此，离线阶段完成：原始文档变成了可语义检索的向量索引。
二、在线篇：从用户问题到精准答案
4. 向量检索：找到"最相关"的知识片段
用户输入问题后，系统做三件事：把问题也转成向量，用这个向量去数据库里"按语义"搜索最相似的K个片段，再把检索到的片段作为上下文传递给大模型。
python
def retrieve(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] for i in indices[0]]
query = "报销超过5000元需要谁审批？"
results = retrieve(query)
for r in results:
print(f"- {r}")5. 上下文增强：让大模型"开卷答题"
检索到的内容不能直接给用户看，需要把它们拼接成增强后的Prompt，让大模型基于这些资料作答，而不是凭空发挥。
python
import openai
def ask(query: str):
# 检索相关内容
context_chunks = retrieve(query, top_k=3)
context = "\n".join(context_chunks)
# 构造增强 Prompt
prompt = f"""
你是一个企业知识库助手。请只根据以下资料回答问题。
如果资料中没有答案，请回答"根据已有资料无法确定"。
资料：
{context}
用户问题：{query}
"""
# 调用大模型生成答案
response = openai.ChatCompletion.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": prompt}]
)
return response["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. 来源追溯：让答案"可验真"
企业场景下，用户需要知道答案出自哪份文档的哪一页。在索引时存储每个片段的元数据（文档名、页码、章节标题），检索时一并返回，就能实现"引用来源"的功能。
sql
-- 表结构示意：为每个块存储来源元数据
CREATE TABLE document_chunks (
id SERIAL PRIMARY KEY,
content TEXT NOT NULL,
embedding vector(1536),
document_title TEXT,
page_number INTEGER,
section_title TEXT
);写在最后
RAG不是"接个API就完事"的黑盒，而是一个需要精细打磨的工程系统。它融合了信息检索 （什么文档相关）、提示工程 （怎么组织上下文）和模型调用（怎么生成答案）三个层次的知识。
一个好的RAG系统，能让大模型像专家一样回答问题------有据可依、来源可查、内容可靠。而一个粗糙的RAG系统，充其量只是个高级"拼接器"。
差异就在细节里：切块策略是否合理？Embedding模型是否匹配业务领域？检索结果是否经过了Rerank清洗？上下文是否被有效组织？把这些链路一步步走通、走深，大模型才能真正成为企业的生产力工具，而不是一个华而不实的"玩具"。