企业官网建设流程全解析

有阵子我特别迷信“把文档切碎、向量化、查相似、塞给大模型”这套说法，直到自己在RAG项目里被检索结果狠狠坑了几次，才意识到RAG检索这道工序远比教程里写的复杂。简单说，检索决定了你要给大模型喂什么，生成只负责把喂进去的话说明白；喂错了，后面再强的大模型也救不回来。所以这篇不聊生成，只聊检索：检索策略怎么定、向量数据库怎么选、底层到底在做哪些搜索运算，以及我实际踩过的那些参数坑。

不管你是刚开始搭RAG知识库，还是已经上线了但总感觉效果飘忽不定，又或者单纯好奇“向量数据库凭什么能毫秒级找到相似内容”，这篇文章应该都能给你一个比较完整的视角。我尽量少写教科书式的定义，多讲实操中真正影响效果的东西。

1. 先搞清楚：RAG 里的“检索”要解决什么问题

1.1 检索在 RAG 链路里的真实位置

RAG全链路可以拆成两段：预处理阶段和查询阶段。预处理阶段包含文档加载、清洗、切分、向量化、构建索引；查询阶段则是query处理、召回、重排、拼接上下文、交给大模型生成回答。很多人把重心放在“向量化”和“大模型提示词”上，但检索真正承担的职责，是从一个可能几百万条的文档库中，用尽量低的延迟挑出最可能包含答案的几十条。

这个职责意味着它要同时满足两个看起来矛盾的目标：召回要全，精度要高。文档库动辄几十万上百万chunk，而大模型上下文窗口再大也有限，你不可能把一百个候选片段都塞进去。你给模型喂的内容质量，完全取决于检索这把筛子筛得准不准。

如果检索返回的前几名全是无关内容，大模型会一本正经地把无关信息组织成看起来合理的回答，而且语气流畅，用户根本判断不出来是检索错了还是生成错了。这就是RAG项目最迷惑人的地方：看起来在生成阶段出了问题，实际病根在检索阶段。

1.2 为什么说检索才是 RAG 的瓶颈

你去看那些“rag瓶颈”“rag知识库效果不好”的讨论，最后定位到的问题十有八九在检索侧。开源demo跑起来效果不错，是因为测试query往往是精心挑过的；一旦进入真实业务，用户问法五花八门，专有名词、口语化表达、长尾场景一上来，纯向量检索的召回率立刻跳水。

更现实的是，很多人把希望寄托在换一个更大的Embedding模型上，结果发现提升有限。原因是检索质量是一个系统工程：chunk切分是否合理、检索策略是否匹配、是否需要重排序、索引参数是否适合数据量、相似度度量是否选对，任意一环掉链子，整体效果都会被拖垮。这也是为什么我坚持认为，RAG项目里最值得花时间打磨的，不是框架选型，而是检索策略。

2. 检索策略：别只会“查相似”

2.1 关键词查得准，向量查得懂：稀疏与稠密检索

检索策略的第一道分岔，是稀疏检索和稠密检索。

稀疏检索的代表是BM25，本质上是TF-IDF的进化版，增加了词频饱和和文档长度归一化。它走的是“词项匹配”路线，query里有某个词，文档里也出现这个词，就加分。它不懂语义，但胜在精确，特别适合专有名词、编号、专利号、代码片段这类必须逐字命中的场景。拿专利检索举例，用户输入“一种无铅压电陶瓷材料”，BM25能精准锁定包含这句完整描述的文档，而向量检索反而可能被语义相近的其他陶瓷材料带偏。

稠密检索就是我们常说的“语义检索”，核心是Embedding模型把query和文档分别编码成向量，再算向量相似度。它擅长处理同义改写、不同表述、跨语言场景。比如用户问“有没有那种不污染环境又不容易衰减的陶瓷配方”，文档里写的是“无铅压电陶瓷材料及其制备方法”，字面完全不重叠，但向量空间里两者距离很近。

问题是两者都有盲区。纯靠BM25，遇到口语化query基本废掉；纯靠向量，遇到从没见过的生僻词、产品编码、精确型号，召回质量会很差。真实业务里很少能靠单一检索器通吃，这也是混合检索存在的根本原因。所以我在帮团队设计检索方案时，第一件事永远是问：你的文档里专有名词占比高不高？用户query是偏向搜索式还是聊天式？答案不同，策略组合完全不同。

2.2 混合检索与 RRF：调和两种检索结果

既然要同时用BM25和向量检索，就面临一个现实问题：两个检索器返回的分数不在一个量纲上。BM25分数是词频加权，向量分数是余弦相似度，硬加在一起没有意义。

最简单的做法是分别归一化到0-1区间再加权求和，权重自己调。但调权重的过程很容易过拟合，换个query分布效果就变了。我通常更推荐RRF（Reciprocal Rank Fusion，倒数排名融合），它不看具体分数，只看文档在各自检索结果里的排名，把排名倒数累加。核心代码很短，完全可以自己实现：

def rrf(rank_lists, k=60): """ rank_lists: 多个检索器返回的文档id列表，按相关性从高到低排列 k: RRF中的平滑常数，业界默认用60 """ scores = {} for rank_list in rank_lists: # rank从1开始，idx是0起始，所以加1 for idx, doc_id in enumerate(rank_list): scores[doc_id] = scores.get(doc_id, 0) + 1.0 / (k + idx + 1) # 按融合分数从高到低排序 return sorted(scores.items(), key=lambda x: x[1], reverse=True)

RRF的好处是不用调权重，两个列表直接融合，稳定性好。它在多路召回场景下非常实用，比如“BM25召回Top50 + 向量召回Top50”，融合后取Top10。k=60是Lucene等搜索引擎里常用的默认值，实际项目中我从10到100都试过，60左右在多数场景下表现均衡。如果你有时间精调，再考虑加权方案，但新手起步用RRF不会错。

需要注意，混合检索不是万能药。当你的query本身就是精确的型号代码，BM25已经能打得很准，向量召回反而会引入噪声；反之亦然。所以上线前一定要留一部分评测集，分别测单路和混合的召回率，用数据说话。

2.3 二阶段检索：为什么重排序不能省

混合检索给你的是“粗召回”结果，通常返回几十条或上百条候选，但真正喂给大模型的一般只有三五条。从上百条到三五条，直接按向量分数截断是常见的错误做法，因为向量相似度只能衡量“大概相关”，无法捕捉query与文档之间细粒度的逻辑关系。

第二阶段重排序通常是Cross-Encoder模型，把query和每个候选文档拼接成一句话，一起过一个模型，输出一个精确的相关性分数。对比一下：第一阶段的Embedding模型是Bi-Encoder，query和文档分别编码成向量再算相似度，速度快但粒度粗；Cross-Encoder是query跟文档在模型内部做了深度交互，精度高但慢，所以只能用在候选集不大时。

实践中的典型pipeline是：混合检索或向量检索召回Top100，重排序模型取Top5，再拼prompt。开源模型里bge-reranker-base和bge-reranker-large都值得试，前者CPU上也能跑，后者需要GPU。时间预算上，召回约50毫秒，重排序100条大约几百毫秒，整体完全可以接受。这个环节经常被新手跳过，但它往往是对最终回答质量提升最明显的一步。

2.4 chunk、元数据过滤与图文场景

很多人问“RAG知识库能存储图片嘛”，其实传统RAG知识库以文本为主，处理的是切分后的文字片段。但如果你做的项目需要图文检索，完全可以建立多模态索引：用CLIP这类模型把图片编码成视觉向量，同时把图片的OCR文本或caption作为文本字段一起入库。检索时query同时走文本向量和视觉向量，命中的图片就可以作为上下文给大模型。

chunk切分对检索质量的影响，往往比换Embedding模型更明显。固定长度切分是最省事的，但也是最容易破坏语义的。一个条款被拦腰切断，检索到的片段只看开头几句，上下文丢失，大模型理解必然跑偏。我的经验是：结构化文档优先按Markdown标题、段落来切；表格单独处理；代码按AST结构走。通用场景下，一定要设置chunk之间适当重叠，我常用chunk_size=512、overlap=50起步，再根据业务调整。

元数据过滤也是被低估的一环。知识库里的文档往往带日期、来源、部门、文档类型等属性，检索时先按这些属性过滤，再进入向量搜索，这叫pre-filter。如果先做向量召回再过滤，很容易把真正相关但被过滤条件排除的结果丢掉。比较成熟的向量数据库会把过滤条件和向量索引融合在一起执行，而不是粗暴地后置过滤，选型时可以重点测试这个能力。至于ontology RAG、知识图谱和向量知识库的区别，一句话说就是：图谱擅长结构化关系推理，向量库擅长非结构化语义召回，两者不是替代关系，复杂业务里甚至会串联使用。

3. 向量数据库与底层搜索算法

3.1 向量数据库选型，先看索引

向量数据库的本质，就是把Embedding向量和高速最近邻搜索封装成一个工程上健壮的服务。选型不能只看Star数，要先理解它支持的索引类型和过滤能力。几个常见选项各有侧重：

数据量小于10万，用FAISS或Chroma完全够。数据量到了百万级，又需要多租户隔离和复杂过滤，Qdrant或Milvus更合适。已有Postgres业务的，pgvector可以省掉一套基础设施，但查询性能和扩展性要提前压测。侧重点不是“哪个最好”，而是“哪个索引和过滤能力最匹配你的数据特征”。

3.2 暴力搜索到 ANN：用精度换时间

几乎所有向量检索算法，都是围绕一件事：精确找到K个最近邻太难，所以退一步找“足够近”的K个。精确搜索需要把query和库里每个向量都算一遍距离，时间复杂度O(N)。100万条128维向量，每次查询就是上亿次浮点运算，算完一次可能要几百毫秒，RAG线上根本扛不住。

于是有了近似最近邻搜索（ANN），思路是在精确度上做一点让步，换取检索速度的数量级提升。优秀的ANN算法在召回率0.95以上的同时，延迟可以从几百毫秒压到十几毫秒以内。理解ANN的关键，是理解它的三种主流路子：基于倒排的、基于图的、基于量化的。向量数据库和传统搜索引擎在这一点上殊途同归，底层都在用“倒排索引”的思想做没有必要全文遍历。

3.3 IVF：聚类分桶与倒排思想

IVF（Inverted File）是倒排思想最直观的体现。它先把整个向量空间用K-means聚类切成nlist个桶，每个桶有一个质心。查询时先算query离哪些质心最近，只在这些桶里搜索。比如建了1000个桶，检索时只看最相近的16个桶，相当于把扫描范围缩小到全库的1/60。

图书馆类比很好用：你要找一本“算法”相关的书，不会每本书都翻一遍，而是先定位到计算机类书架，再在书架里翻。IVF的检索质量受两个参数影响：nlist和nprobe。nlist是聚类的数量，一般按数据量平方根量级取，100万条向量可以设1000左右；nprobe是检索时探查的桶数，越大召回越高但越慢。

IVF有一个明显弱点：落在聚类边界附近的向量容易被分到错误的桶，导致召回偏低。提升nprobe可以缓解，但代价是延迟上升。所以IVF适合对内存敏感、能接受一定召回损失的场景，而追求极致检索质量时，HNSW往往是更稳的选择。

3.4 HNSW：分层近邻图

HNSW（Hierarchical Navigable Small World）是目前向量数据库里最主流的索引算法。它在近邻图的基础上加了一个层次结构：底层包含全部节点，边连接得又细又密；越往上节点越少，只保留一些“高速通道”。搜索时从顶层开始，先通过稀疏的通道快速跳到目标区域附近，再逐层往下细化，最终在底层找到精确的近邻。

这个思路用写字楼导航来理解非常贴切：你想找某个工位，先站在楼栋指示牌前确定去几楼，到了楼层再确认去哪个区，进入区里再找具体工位。HNSW搜索的过程就是不断缩小范围、逐层逼近的过程。相比IVF，HNSW召回质量更高，尤其查询分布不均匀时表现更稳定。

HNSW关键参数有三个：M是每个节点的最大连接数，越大图越密、召回越高、内存越大，通常取16到64；efConstruction是建图时的动态候选集大小，决定建图质量，常用200左右；efSearch是查询时的候选集大小，越大召回越高但越慢。FAISS里用起来很简单：

import faiss d = 768 # 向量维度 index = faiss.IndexHNSWFlat(d, 32) # M=32 index.hnsw.efConstruction = 200 index.add(vectors) # vectors: [N, d] 的 float32 数组 index.hnsw.efSearch = 128 # 查询时动态调整也可以 # 搜索 scores, indices = index.search(query, k=10) # 返回 Top10

刚用HNSW的人最容易踩的坑是忽略内存。HNSW的图结构开销很大，100万条768维向量的原始数据就要约3GB，加上图连接信息，内存占用可能再翻一倍。数据量特别大且对内存敏感时，考虑PQ量化，下面讲。

3.5 PQ乘积量化：压缩与近似

PQ（Product Quantization，乘积量化）的思路是把高维向量切成m段，每段单独训练一个码本，每一段用最近的码本中心点编号来表示。这样，一个768维向量就被压缩成m个短编号，内存占用大幅下降。检索时不需要精确计算原始向量距离，而是用码本里的中心点做近似距离估计，也就是ADC（非对称距离计算），在精度损失可控的前提下省下大量内存和算力。

FAISS里用IndexIVFPQ可以直接体验：

import faiss d = 768 nlist = 1000 quantizer = faiss.IndexFlatL2(d) # 量化器的基准 index = faiss.IndexIVFPQ(quantizer, d, nlist, 8, 8) # m=8, nbits=8 index.train(vectors_train) # PQ需要训练码本 index.add(vectors) index.nprobe = 32 scores, indices = index.search(query, k=10)

这里的m=8表示把768维切成8段，每段96维；nbits=8表示每段用256个中心点。训练需要用有代表性的向量集合做K-means，样本太少了码本会不准。PQ的典型场景是内存紧张、需要大规模检索、同时能接受5%-10%的召回损失；如果你有条件上HNSW，通常优先HNSW。

3.6 相似度度量怎么选

向量库和索引都只是工具，真正决定“什么叫相似”的是度量函数。三个最常见的度量是余弦相似度、欧氏距离（L2）和内积（IP）。它们各有适用场景：

语义搜索场景下，大多数Embedding模型推荐的余弦相似度；但如果模型输出向量已经归一化，余弦相似度和内积在排序效果上完全等价，后者计算更快。还有个容易被忽略的知识点：向量归一化之后，欧氏距离的排序结果和余弦相似度也会变成单调对应关系，所以有些场景直接选L2也能得到等价排序。

4. 实操调优：让检索从“能跑”变“好用”

4.1 用暴力搜索标定召回上限

项目初期最值得做的一件事，是先不用任何ANN索引，在测试集上用暴力精确搜索跑出一个“召回率天花板”。这个数字非常有价值：如果暴力搜索状态下的Recall@10都只有0.6，那问题大概率出在Embedding模型选择或chunk切分方式上，换索引、调参都救不回来；如果暴力搜索能达到0.95，你接下来所有调参都有的放矢。

方法很简单：准备20到50条真实query，标注出每条的正确答案所在文档/片段，先用暴力索引搜索，统计Recall@K；再把索引换成HNSW或IVF，同样测Recall@K，看差距。FAISS里暴力搜索只需要一个IndexFlatL2或IndexFlatIP：

index_flat = faiss.IndexFlatL2(d) index_flat.add(vectors) scores, indices = index_flat.search(query, k=10)

这一步能帮你把所有变量拆开。别再纠结“为什么效果差”了，先用暴力搜索定位到底是“表示层”的问题还是“索引层”的问题。

4.2 调参顺序与典型参数

确认暴力搜索的召回达标后，再切换到ANN索引，并按固定顺序调参。我的习惯是：先调efSearch或nprobe这类查询参数，调到召回率恢复到暴力搜索的95%以上；再考虑是否减小M或增大量化压缩力度来降内存；最后才调混合检索权重和重排序规模。

以HNSW为例，实测下来一些初始经验值：efSearch从50调到200，召回通常能提高两三个百分点，延迟可能从5毫秒涨到20毫秒，这个交换对RAG来说非常划算。IVF的话，nprobe从8调到32，召回提升明显，再往上边际收益递减。每次只改一个参数，保留同一份评测集，把指标记录下来，避免凭感觉调参。

还有一点容易忽略：线上query分布和评测集不一致时，参数需要重新校验。我见过项目在公开数据集上召回率漂亮，一到真实业务数据就崩，因为真实query的领域词汇分布完全不同。所以评测集必须从真实业务里采样，不要只依赖公开数据集。

4.3 检索效果诊断速查表

实操和线上排障时，我经常用下面这张表做快速定位：

这张表不能覆盖所有问题，但它能帮你把“效果差”这个大问题拆成几个可独立验证的小问题，逐个击破。

5. 一些我踩过的坑和最后的小建议

5.1 工具不是核心，策略才是

项目里见过太多人花大量时间对比“rag框架”选型，今天换LangChain，明天换LlamaIndex，后天又换自研pipeline，折腾一圈发现检索效果原地踏步。框架只是胶水，决定检索质量的是chunk切分、检索策略、重排序这“铁三角”。框架的差异在项目早期体现不出来，数据量和query复杂度上来之后，你真正要解决的永远是检索策略问题，而不是换框架能解决的。

5.2 本地文本拆解与向量化的小方案

有朋友问“有没有本地的RAG文本拆解工具”，如果你介意把文档传到外部服务，可以完全本地化跑：文本切分用LangChain里的RecursiveCharacterTextSplitter或更细粒度的MarkdownHeaderTextSplitter，Embedding用ollama跑nomic-embed-text或bge模型，向量存储先用FAISS或SQLite+pgvector顶住验证阶段。一套流程下来，文档不出机器就能完成知识库搭建。本地方案的好处是数据安全，缺点是Embedding模型效果不如云端大模型，适合对保密要求高的场景，也适合先把流程跑通再替换模型。

5.3 先小后大，先精确后近似

最后分享一个我个人很受用的做法：跑任何RAG项目之前，我会先手工写20到50条最难检索的query，标好答案，作为固定回归集。检索调优如果没有回归集，基本靠感觉，改完参数也不知道变好还是变坏。有了这几十条用例，每次调参都能看到召回率数字变化，项目心里踏实很多。

另一点就是不要一上来就在百万级数据上折腾ANN索引。先在几千条数据上跑通全流程，用暴力搜索确认召回天花板，再扩大到全量数据切到近似索引。调试阶段几百毫秒的检索延迟完全不是问题，等逻辑稳定了再考虑性能优化，效率会高很多。RAG检索这件事，真正拉开差距的不是哪个框架更先进，而是你有没有把每个环节拆开、量化、逐步逼近它的上限。