大模型频繁胡说八道？搭建RAG知识库改善问答准确率实战指南

如果你直接问大语言模型一个具体的内部业务问题，比如“我们公司去年第三季度针对退款的处理流程是什么”，它大概率会一本正经地编造一套看似合理、实际完全错误的流程。这就是典型的模型幻觉。大模型本质上是一个基于概率预测下一个词的生成器，它只记住了预训练阶段学到的通用概率分布，并不掌握你内部私有文档里的真实细节。

解决这个问题的直接手段，就是搭建一套 RAG（检索增强生成）系统。简单来说，就是先在知识库里把相关的文档片段找出来，然后把这些片段塞进提示词里，让大模型照着资料回答。

很多人以为搭建 RAG 很简单：写个脚本把文档按字符切开，调用 Embedding 接口存进向量数据库，提问时做个余弦相似度检索，最后拼给大模型。我在两年前做内部技术文档和客服问答系统时，最初也是这么干的，结果真实问答准确率甚至不到 50%。系统经常找来一堆毫不相关的段落，或者把关键参数漏掉，大模型依然在胡言乱语。

要想让 RAG 真正可用，必须搞清楚整个链路上的关键环节。下面按照我实际踩坑验证过的步骤，把整套搭建和优化流程拆开说明。

第一步：文档清洗与结构化解析

先做数据清洗，再做内容入库，这是保证质量的前提：

1.必须用脚本过滤页眉、页脚与无关符号。这些内容会污染向量语义。

2.表格必须转为 Markdown 表格或 HTML 结构。在多项评测中，保留行列标记的结构化表格，能让检索匹配率明显好于被打散的纯文本。

3.保留段落的元数据（Metadata）。为每个切片打上“来源文件名”、“章节层级”、“更新日期”和“部门分类”等标签，后续做元数据过滤时极其有用。

第二步：文本分块（Chunking）

分块是 RAG 流程中最容易被低估的环节。Vectara 的公开研究表明，文本切分策略对最终检索效果的影响程度，丝毫不亚于 Embedding 模型的选择。

块切得太大，单个向量包含的主题过多，语义会被稀释；块切得太小，上下文支离破碎，模型根本读不懂前因后果。

核心建议是：针对普通中文业务文档，将块大小（Chunk Size）控制在 256 到 512 个 Token 之间，重叠窗口（Overlap）设置为 10% 到 20%（大约 40 到 80 个 Token）。重叠区域能防止关键实体或判断句刚好被切成两半。

下面是常见切分策略的实际对比：

切分策略	核心逻辑	优势	缺陷	适用场景
固定字符切分	按固定字符数硬切，加固定重叠	实现最简单，计算速度极快	极易在句子或词语中间切断，破坏语义	格式混乱、缺乏层级结构的纯文本草稿
递归字符切分	依次按段落符、换行符、标点符号递归尝试切分	能够保持自然段落完整性，语义连贯好	依然无法完全识别复杂排版结构	通用文档、常见技术规范与知识问答
按 Markdown 标题切分	按照文档的 H1、H2、H3 标题层级切分	逻辑边界最清晰，保留完整上下文语境	文档排版不规范时切分块大小极不均匀	结构清晰的技术文档、操作手册、API 指南
父子块索引（Parent-Child）	用小块（如 128 Token）检索，召回其所属的大块（如 1024 Token）给模型	检索精度高，且大模型能拿到完整上下文	存储成本高，索引构建复杂度增加	长篇制度规范、法律条款、分析报告

第三步：向量模型（Embedding）与向量数据库选型

切好文本后，需要调用 Embedding 模型把文字转成数值向量。很多初学者习惯直接使用英文教程里推荐的模型，结果在处理中文长句或专业词汇时效果很差。

针对中文场景，优先选择经过海量中文文本微调的模型，例如智源开源的 BGE 系列（bge-large-zh-v1.5 或 BGE-M3）。如果不想自己部署显卡服务器，直接调用商业云平台的 Embedding API 也是稳定可靠的选择。

下面是主流 Embedding 模型的特点对比：

模型名称	向量维度	最大上下文长度	中文表现	部署成本	选型建议
BGE-M3	1024	8192 Tokens	优秀	需本地或自建 GPU 服务	中文复杂长文档首选，支持密集与稀疏混合检索
bge-large-zh-v1.5	1024	512 Tokens	优秀	需自建 GPU 服务（单卡即可）	中小段落问答经典方案，延迟低，表现稳定
OpenAI text-embedding-3-small	1536（可缩减）	8191 Tokens	良好	仅按 Token 计费，无需运维	多语言混合环境、无 GPU 资源团队的首选
text-embedding-ada-002	1536	8191 Tokens	一般	仅按 Token 计费	老一代模型，性价比与中文表现均落后，不建议新项目使用

选好模型后，还需要选一个向量数据库。如果数据量在 10 万条切片以内，直接使用 Chroma 或轻量化的 Qdrant 就足够了，部署简单，占内存少。如果数据量超过百万级，或者需要严格的高可用集群，建议选用 Milvus 或在现有的 PostgreSQL 上开启 pgvector 插件。

第四步：引入混合检索与重排（Rerank）

很多团队的 RAG 准确率遇到瓶颈，根源在于只用了纯向量相似度检索。

向量检索擅长处理概念、同义词和语义模糊的匹配。但是，向量检索对具体的专有名词、手机型号、工单号、代码函数名极其迟钝。用户输入具体产品型号“ABC-2024-X”，向量检索出来的可能全都是相关类别的泛化介绍，因为这些文字在向量空间里离得很近。

要做高精度检索，必须执行两个操作：

首先，做混合检索（Hybrid Search）。同时运行 BM25 关键词检索与向量检索，然后使用 RRF（倒数排名融合算法）把两路结果合并。这样既保证了语义模糊匹配的召回率，又保住了精准专有名词的命中率。

其次，引入重排序模型（Rerank）。初始检索从数据库里召回 Top-20 或 Top-30 个候选片段，然后用交叉编码器（Cross-Encoder）结构的重排模型（如 bge-reranker-large 或 bge-reranker-v2-m3），把这 30 个候选片段与用户问题逐个打分对比，最后只挑选得分最高的 3 到 5 个片段送给大模型。

实测数据显示，引入 Rerank 环节后，送入大模型的上下文准确率通常能直接增加 20% 到 30%。这是整个 RAG 优化链路中成本最低、见效最快的一环。