在构建私有知识库问答系统时，最核心的挑战不是“让大模型会说话”，而是“让大模型说的是知识库里的内容”，原始的RAG系统存在检索不准，幻觉输出等问题，检索准确率往往不是太好。本文梳理RAG的核心原理，分析一下几种主流的优化策略。

一.RAG是什么？

1.大模型的知识来源于训练数据，存在知识截至日期。无法访问私有的，实时的数据（比如用户自己上传的技术文档）。直接让模型“记住”所有私有文档，成本又极高。

2.RAG的核心思想是：不让模型“记住”所有上传的知识库内容，而是在用户提问回答时，能够现查现用。

可用如下流程图表示：

用户提问
   ↓
将问题转成向量
   ↓
在向量数据库中检索最相似的文档片段
   ↓
将文档片段 + 原始问题 拼成 Prompt
   ↓
送给 LLM 生成最终回答

二. RAG的核心组件原理

1.Embedding（向量化）：将文本转化为高维数组向量（此项目用的阿里云的text-embedding-v3,输出1024维）。对于语义相近的文本，空间中距离更近。这是实现“语义检索”而非”关键词检索“的基础。

2.向量相似度的度量：

有三种常见的距离/相似度：

方法	公式含义	适用场景
余弦相似度	计算两个向量的夹角	文本语义匹配
欧氏距离	计算向量空间中的直线距离	图像检索
内积	向量点乘结果	信息检索

本项目使用的余弦相似度。

3.文本分块（Chunking）

分块的原因：文本太长无法整体向量化。

本项目使用TokenTextSplitter，按Token数量切分。

三. 原始RAG的缺陷

1.查询语义模糊问题

用户的提问有时会很短，很口语化，向量化后语义表达不充分，导致检索结果偏离。

2.关键词/专有名词匹配失败

向量检索擅长语义泛化，但对专有名词（pgvector，HNSW）的精确匹配反而不如关键词搜索。

3.知识库边界混乱

多用户，多知识库的场景下，不同知识库的内容有时会相互干扰，检索结果混杂。

4.幻觉问题

当检索不相关时，LLM可能“脑补”出知识库中没有的内容。

四. 优化检索策略

1.QueryRewrite(查询重写)

在检索前，先用 LLM 将用户的短查询、模糊语义扩写为更完整、更可检索的语句。

原始问题："pgvector怎么建索引"
重写后："请说明在PostgreSQL中使用pgvector扩展创建HNSW向量索引的完整步骤和参数配置"

2.混合检索

可以构建双路检索体系：向量检索（语义）+全文检索（关键词，专有名词）

之后使用RRF（Reciprocal Rank Fusion，倒数排名融合）算法将两路结果合并排序：

RRF分数 = Σ 1 / (k + rank_i)

这样准确率应能大幅提升。

3.前置过滤

向量检索前，先按知识库ID过滤，将检索范围限定在用户自己的知识库内，避免跨库干扰。

4.来源标注（可溯源性）

通过Prompt约束LLM在回答时必须标注引用的知识库片段ID，增强可信度与可追溯性，有效拦截幻觉输出。

五. 总结

原始RAG在生产环境中很难达到90%以上的准确率，通过上文介绍的优化策略，有望优化RAG检索问题。