RAG检索增强生成实战：文档切分策略、向量库选型与混合检索优化

RAG（检索增强生成）是大模型应用中最常见的落地架构，但实际项目里经常出现答非所问、关键内容检索不到、幻觉率偏高的问题。这类问题的根因多数不在模型本身，而在文档切分、向量库选型和检索策略三个工程环节。围绕这三个环节，给出可直接复用的配置、代码与选型结论。

RAG系统答非所问的四个常见根因

排查一个表现不佳的RAG系统，优先检查以下四点：

• 切分粒度不当：块太大时单个chunk混杂多个主题，向量表征被稀释，召回排序失真；块太小时语义不完整，即使召回也缺少上下文。
• 纯向量检索的局限：嵌入模型对专业术语、产品型号、错误码这类精确token的区分能力弱，向量相似度高不代表语义相关。
• 结构化内容被破坏：表格、代码、配置文件被按固定长度切断后基本失去检索价值。
• 缺少评测基线：调整切分或检索参数后没有量化指标，无法判断改动是否有效。

文档切分策略：固定长度、语义切分与结构感知

固定长度切分配合重叠区间是通用起点，适合大多数纯文本文档：

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=80,
    separators=["\n\n", "\n", "。", "；", " ", ""],
)
chunks = splitter.split_documents(docs)

RecursiveCharacterTextSplitter按分隔符优先级递归切分，能尽量保持段落完整。chunk_size的经验范围是300到800个字符，需要结合嵌入模型的最大输入长度和生成上下文窗口权衡。

对Markdown、HTML这类带层级的文档，按标题切分并保留标题路径作为元数据效果更好：

from langchain_text_splitters import MarkdownHeaderTextSplitter

headers = [("#", "h1"), ("##", "h2"), ("###", "h3")]
md_splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers)
sections = md_splitter.split_text(markdown_text)
# 每个section自带h1/h2/h3元数据，检索时可按标题过滤

表格类内容单独处理：整表保留为一个chunk，同时生成一段文字摘要存入摘要索引，命中摘要后再带出原表。

向量数据库选型：pgvector、Qdrant、Milvus怎么选

选型的关键变量是数据规模、过滤需求和运维成本：

• pgvector：百万级以下向量、已有PostgreSQL的项目直接复用，支持HNSW索引，事务和标量过滤查询都是现成的，运维成本最低。
• Qdrant：千万级规模、需要复杂标量过滤（多租户、时间范围）时的首选，过滤性能和内存占用表现稳定。
• Milvus：亿级向量、多副本高可用场景，分布式架构扩展性强，但组件多、运维复杂度高。
• Elasticsearch：已有ES集群且需要关键词与向量原生混合检索的场景，可以省去自建融合层。

混合检索：向量召回加BM25关键词召回

解决”错误码、型号查不到”最有效的手段是混合检索：向量通道负责语义泛化，BM25通道负责精确词匹配，两路结果用RRF（Reciprocal Rank Fusion）融合：

def rrf_fuse(result_lists, k=60, top_n=10):
    scores = {}
    for results in result_lists:
        for rank, doc_id in enumerate(results):
            scores[doc_id] = scores.get(doc_id, 0) + 1.0 / (k + rank + 1)
    ranked = sorted(scores.items(), key=lambda x: -x[1])
    return [doc_id for doc_id, _ in ranked[:top_n]]

final_ids = rrf_fuse([vector_channel_ids, bm25_channel_ids])

融合之后可以再接一层rerank模型（bge-reranker这类Cross-Encoder结构），对top 30到50条重排后取前10，通常能明显提升最终排序质量，代价是增加一次模型调用的延迟。

检索质量评测：先建评测集再调参数

从真实用户问题中抽取50到200条，标注每条问题应命中的文档出处，构造评测集。核心指标两个：

• 命中率（Hit Rate）：标准出处是否出现在top-k召回结果中，衡量召回能力。
• 忠实度（Faithfulness）：生成答案是否忠于召回内容，可用RAGAS等工具自动评估。

调整切分大小、是否混合检索、是否加rerank，每一项改动都跑一遍评测集对比指标，避免凭感觉迭代。RAG系统的效果上限由检索质量决定，评测集建得越早，后续迭代成本越低。