如何通过构建本地知识库 RAG 彻底解决 LLM 在专业领域胡说八道的问题

把大模型直接扔进专业领域做问答，基本就是一场“概率赌博”，因为 LLM 的本质是预测下一个 Token，而不是检索事实。哪怕是 GPT-4o，在面对公司内部文档或冷门行业标准时，依然会一本正经地编造虚假事实（幻觉）。

想彻底根治这个问题，目前最稳的方案就是 RAG（检索增强生成）。简单来说，就是给 AI 配一个“开卷考试”的参考资料库。

我最近对比了三种主流的本地知识库实现方案，实测体感如下：

1. 纯向量数据库方案 (Naive RAG)
这是最基础的做法，把文档切片 → Embedding → 存入向量库（如 Milvus 或 Chroma）。
实测表现： 适合处理简单的语义查询。但遇到复杂问题（比如“对比 A 产品和 B 产品的三项核心指标”）时，经常因为检索片段不完整导致回答缺失。
缺点： 对切片长度极其敏感，切太短没上下文，切太长会引入噪声。

2. 混合检索方案 (Hybrid Search)
向量检索 + 关键词检索（BM25）。
实测表现： 在处理专业术语、产品型号、特定代码函数名时，效果远超纯向量检索。因为专业领域很多词是唯一的，不需要语义近似，只要精确匹配。
优点： 极大地降低了因为 Embedding 模型没训练过专业词汇而导致的检索失败。

3. GraphRAG (知识图谱增强)
这是最近比较火的路径，将实体关系结构化。
实测表现： 处理全局性问题（如“这份 100 页的报告核心结论是什么”）时，传统 RAG 几乎全挂，而 GraphRAG 能通过社区聚类给出总结。
缺点： 构建成本极高，索引速度慢得令人发指。

模型选择建议：
在 RAG 链路中，Embedding 模型和 LLM 是两回事。
Embedding 模型： 建议用 BGE-M3，多语言支持好且支持混合检索。
LLM 模型：

• Claude 3.5 Sonnet： 目前 RAG 的最佳拍档，指令遵循能力极强，能严格限制在给定的 Context 中回答，不乱发挥。
• DeepSeek-V2.5： 性价比极高，在处理中文专业文档的理解力上不输 GPT-4，且响应速度快。
• GPT-4o： 综合能力强，但偶尔还是会跳出上下文去用它自己的训练知识回答，需要极强的 System Prompt 压制。

一个实测有效的 System Prompt 约束模版：

你是一个专业的知识库助手。请仅根据提供的 [Context]  answering the question。
如果 [Context] 中没有相关信息，请直接回答“知识库中未记录该信息”，严禁调用你的预训练知识进行猜测。
回答时必须标注引用的片段编号，格式为 [Source X]。

核心逻辑就是：把 LLM 从“知识来源”降级为“语言组织者”，把事实定义权交还给本地数据库。