搭建好的 RAG 系统常常“能用却不好用”，问题多出在检索环节而非模型本身。这篇内容深入探讨影响检索质量的三个核心环节：知识库分块、向量化选型和检索策略，提供了从原理到实践的完整优化路径，帮助系统效果实现质的飞跃。
智能速览
分块策略是 RAG 效果的天花板，600-800 字符是中文场景的黄金尺寸。
中文 RAG 应首选 BGE-M3 向量模型，而非 OpenAI 的 ada-002。
混合检索配合重排序（Rerank）是提升效果最显著的“低垂果实”。
数据量低于 10 万时，无需昂贵向量库，FAISS 已足够。
GraphRAG 是未来方向，但目前成本较高，适合高精度场景。
精华内容
RAG 系统的优化，关键在于提升检索质量。与其反复调试 LLM 的 Prompt，不如回归本源，从知识库的切分、向量的选择到检索的策略，系统性解决问题。
分块定天花板
RAG 系统的效果上限，往往在知识分块阶段就已决定。若切分不当，后续的向量化和检索再精妙也于事无补。对于中文文本，600-800 字符是推荐的黄金尺寸，它在检索精度与上下文完整性之间取得了最佳平衡。
为避免在句子中间切断语义，建议设置 10-20% 的块间重叠。分块方式上，语义分块优于固定长度分块，它能优先按段落、句号等自然分隔符切分，最大程度保持语义完整性。
通用场景下，采用语义分块并设置 600 字符上限是高效的起点。而对于 Markdown、法律文件等具有清晰结构的内容，则应开发自定义分块规则，按标题、条款进行切分，效果更佳。
选对向量模型
在中文 RAG 场景中，Embedding 模型的选型甚至比 LLM 更关键。一个常见的误区是使用 OpenAI 的 ada-002 模型处理中文，导致效果不佳并误以为是其他环节的问题。
实践表明，专门为中文优化的 BGE-M3 模型是更优选择。它不仅开源免费，而且支持高达 8192 token 的输入长度，远超 BERT 系列的 512 token 限制，能够处理更长的文本段落。
BGE-M3 在纯中文及中英混合场景下均表现出色，是构建中文生产环境 RAG 系统的首选模型，能显著提升语义理解的准确性。
混合检索提分
单一检索方式存在明显短板：向量检索擅长语义理解但弱于精确匹配，而 BM25 关键词检索恰好相反。为实现效果最大化，混合检索是必经之路。
混合检索架构会并行执行向量检索和 BM25 检索，然后将两路结果合并，最后通过一个重排序模型进行精排。这一步是提升效果的“低垂果实”，仅增加一行代码，就能带来 NDCG@10 指标 15-25% 的显著提升。
推荐使用 BAAI/bge-reranker-large 作为重排序模型，它在中文场景下表现稳定，是当前投入产出比最高的优化手段。
数据库不越贵越好
向量数据库的选择应根据实际数据规模而定，避免过度设计。对于 10 万条数据以下的中小规模应用，免费的 FAISS 库已完全足够，其性能卓越且支持 GPU 加速。
当数据量达到 10 万至 100 万级别，可考虑 FAISS 的 HNSW 索引或部署轻量级 Milvus 集群。而对于千万级以上的海量数据，才需要使用 Milvus 的分布式架构。
切忌盲目追求昂贵或复杂的解决方案，从 FAISS 开始，在性能和成本之间取得平衡，是更务实的选择。
RAG 从“能用”到“好用”的跃迁，关键在于回归检索质量的根本。通过优化分块、Embedding 和检索策略，系统性能才能得到系统性提升。其中，引入重排序是当前投入产出比最高的优化手段，值得立即尝试。
