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清洗？上下文是否被有效组织？把这些链路一步步走通、走深，大模型才能真正成为企业的生产力工具，而不是一个华而不实的"玩具"。