RAG 检索与语义去重基础实践

我在行业大语言模型微调和 RAG 应用开发中，接触过业务文档解析、知识库构建和检索增强问答等工作。后来工作重心转向其他方向，没有持续追最新的 RAG 框架细节，但信息检索和语料清洗这些基础问题，在很多系统里仍然绕不开。

这篇文章整理自两篇早期 CSDN 笔记：一篇关于 BM25，一篇关于语义去重。现在重新整理时，我更关注它们在 RAG 应用中的位置，而不是把它们写成单独的算法介绍。

BM25：仍然实用的关键词召回

BM25 是传统信息检索里的经典相关性评分方法。它基于词项匹配、词频、逆文档频率和文档长度归一化，对查询和文档之间的相关性进行打分。

在大模型应用中，BM25 并没有因为向量检索出现而失去价值。很多业务问题仍然高度依赖关键词、编号、专业术语、政策条款或设备名称。这类信息如果只依赖语义向量，有时反而容易被相近表达稀释。

因此在 RAG 系统里，BM25 更适合作为基础召回方式之一：

• 对明确关键词、编号、专有名词较敏感。
• 实现简单，解释性强。
• 适合和向量召回做混合检索。
• 便于在业务方质检时解释为什么召回某段文本。

向量检索与语义召回

向量检索的优势在于能处理表达差异。两个句子字面不同，但语义相近时，embedding 模型可以把它们映射到相近位置。对问答、相似问题匹配和语义搜索来说，这一点很有用。

但向量检索也不是万能的。它依赖 embedding 模型质量，也受语料切分、字段清洗和索引构建影响。如果文档本身噪声很多，或者 chunk 切分破坏了上下文，再强的检索框架也很难稳定返回正确内容。

我更认可的实践方式是混合检索：关键词召回保证精确项不丢，向量召回补充语义相似内容，再通过重排或规则过滤控制最终上下文质量。

语义去重：让知识库更干净

很多业务语料不是天然干净的。FAQ、任务描述、工单、历史文档和人工整理材料中，经常会出现大量重复或近似重复内容。如果不清理，知识库会变得臃肿，检索结果也容易被重复片段占满。

语义去重的基本思路是：先用模型把文本转成向量，再通过相似度检索找出近似文本，最后按规则保留更完整、更规范或更新的版本。

工程上需要注意几个点：

• 去重阈值不能过低，否则容易误删不同含义的文本。
• 要保留来源、时间和字段信息，便于判断哪个版本更可信。
• 对短文本和长文本最好分开处理，避免相似度分布差异过大。
• 批量去重需要考虑索引结构和内存占用，不能简单全量两两比较。

相关实现

这部分经验对应过一个轻量工具仓库：Semantic-Text-Deduplicator。它使用 Transformer 模型生成文本向量，并结合 FAISS 索引处理 JSONL 语料中的语义重复问题。

这个工具更适合作为语料清洗阶段的基础组件，而不是完整 RAG 系统。它的作用是先把重复或高度相似的文本压下去，让后续索引构建和检索召回干净一些。

复盘

RAG 系统效果不好时，问题不一定出在大模型。检索召回、语料清洗、chunk 切分、重复内容和上下文排序，都会影响最终回答质量。

BM25、向量检索和语义去重都不是很新的技术，但它们构成了知识库应用的基础层。这部分经验更像是行业大模型应用开发中的底层工具箱：不追求概念新，但要能解释、能排查、能稳定服务。