Agent驱动RAG知识库面试全链路：从文档切分到pgvector选型与Agent调度

1. 面试官问的不是术语，是你有没有真的跑过链路

DocResearch 这个项目名字听起来像个文档问答工具，但真正面过这类岗位的人都知道，面试官关心的从来不是你能不能背出 RAG 的全称，而是你能不能把一条完整的链路讲清楚：文档进来之后怎么切、切完存哪里、检索的时候怎么召回、召回之后怎么重排、重排完怎么喂给 Agent、Agent 又怎么决定要不要再查一轮。这条链路上任何一个环节含糊，面试官三句话就能把你问穿。

我面过也带过人面过，见过太多候选人把“我用了 pgvector 做向量检索”挂在嘴边，结果一问“为什么选 pgvector 而不是 FAISS 或者 Milvus”，就开始说“因为它是 PostgreSQL 的扩展，比较方便”。这个回答不算错，但太浅了。面试官想听的是：你的数据量级多大、写入和查询的比例是多少、有没有事务需求、运维成本能不能接受、团队里有没有人熟悉 Postgres。这些才是选型的真实理由，术语只是结果。

DocResearch 这类项目的核心，其实是一个Agent 驱动的检索增强系统。它和普通的 RAG 问答最大的区别在于：普通 RAG 是“一次检索、一次生成”，而 DocResearch 里的 Agent 会自己判断“这次检索够不够”“要不要换个关键词再查”“要不要拆成多个子问题分别查”。这个判断能力，才是 Agent 和普通 RAG 的分水岭，也是面试里最能拉开差距的地方。

这篇文章我想按面试的真实节奏来写，不是给你一份标准答案让你背，而是把每个模块“为什么这么设计”“我当时怎么想的”“踩过什么坑”讲透。你看完之后，应该能做到：面试官随便挑一个模块，你都能从需求、选型、实现、坑点四个层面讲出十分钟不带重复的内容。

适合谁看？如果你正在准备 DocResearch 或类似 Agent + RAG 项目的面试，或者你手上正在搭一个知识库问答系统但总觉得哪里不对劲，这篇内容应该能帮你把思路理顺。我会尽量用大白话，把那些看起来高大上的概念拆成你能直接上手的东西。

2. 文档切分：最不起眼却最容易翻车的环节

2.1 为什么固定长度切分是个陷阱

几乎所有人做 RAG 的第一步都是“把文档切成块”。很多人上来就写chunk_size=500, overlap=50，然后就开始调检索效果。我一开始也这么干，后来发现检索出来的内容经常“缺头少尾”——一个完整的段落被从中间切断，前半段在一个 chunk 里，后半段在另一个 chunk 里，检索到哪个都答不全。

固定长度切分的问题在于，它假设“文本的价值均匀分布”，但真实文档不是这样的。一份技术文档里，一个标题下面的内容是一个完整语义单元；一份合同里，一个条款是一个完整单元。你按字符数硬切，等于把语义单元打碎了。

DocResearch 里我最后采用的是结构化切分 + 语义切分结合的策略。具体做法是：

• 先按文档的天然结构切，比如 Markdown 按标题层级切，PDF 按段落和表格边界切，代码文件按函数和类切。
• 对于超长的结构块，再用语义切分做二次处理，判断相邻句子之间的语义相似度，相似度骤降的地方就是切分点。
• 最后给每个 chunk 补上“上下文头”，也就是它所属的章节标题路径，比如[第三章 > 3.2 检索策略 > 3.2.1 向量召回]。

这个上下文头非常关键。面试的时候如果你能主动提到这一点，面试官会觉得你真的调过效果。因为检索的时候，用户问“向量召回怎么做的”，如果 chunk 里只有正文没有标题，模型可能不知道这段在讲什么；加上标题路径之后，召回准确率会有肉眼可见的提升。

2.2 chunk 大小到底怎么定

这个问题没有标准答案，但有一个思考框架。chunk 太大，检索精度下降，因为一个 chunk 里混了太多主题；chunk 太小，上下文不足，模型答不全。我的经验值是：

注意这里说的是 token 不是字符。中文里一个 token 大约对应 1.5 到 2 个汉字，英文里一个 token 大约 0.75 个单词。很多人用字符数来设 chunk_size，结果中文文档切出来特别碎，因为中文字符信息密度高。

还有一个实操细节：overlap 不是越大越好。我见过有人设 overlap=200，结果检索出来的内容大量重复，反而干扰了重排。overlap 的作用是防止切分点正好落在关键句中间，一般设 chunk 大小的 10% 到 20% 就够了。

2.3 表格和图片怎么处理

这是面试里经常被追问的点，因为热词里就有“rag知识库能存储图片嘛”。答案是：能，但不是你想的那种存法。

图片本身不能直接做向量检索，你需要把它转成文本描述或者向量。DocResearch 里的做法是：

• 表格：用解析库把表格转成 Markdown 格式，保留行列结构，然后作为一个独立 chunk 存储。表格的检索往往靠关键词匹配更有效，所以我会给表格 chunk 同时建向量索引和全文索引。
• 图片：用多模态模型生成图片描述，把描述文本作为 chunk 内容，同时保留图片的原始路径。检索到描述之后，前端可以根据路径把原图展示出来。
• 图表：如果图表里有数据，尽量用 OCR 或者结构化解析把数据抽出来，转成文字描述。

提示：图片描述的质量直接决定检索效果。我试过用通用描述“这是一张架构图”，结果完全检索不到；后来改成“这是 DocResearch 的检索链路架构图，包含文档解析、向量化、pgvector 存储、Agent 调度四个模块”，效果立刻不一样。描述要包含“这张图在讲什么主题”，而不只是“这张图长什么样”。

3. 向量存储选型：pgvector 到底适合什么场景

3.1 pgvector 的真实定位

热词里有“pgvector windows precompiled下载”，说明很多人卡在安装这一步。但面试官不会问你安装，他会问你“为什么用 pgvector”。这个问题的答案，取决于你的项目规模和团队情况。

pgvector 的本质是给 PostgreSQL 加了一个向量类型和向量索引。它的优势不是性能最强，而是你不需要额外维护一套数据库。如果你的项目已经在用 Postgres 存业务数据，那向量数据放在同一个库里，可以用 SQL 直接 join，事务也能保证一致性。这对中小规模项目来说，运维成本低得不是一点半点。

但它的边界也很清楚：

• 数据量超过千万级向量，查询延迟会明显上升，这时候要考虑专用向量库。
• 需要极致的召回性能（比如毫秒级、亿级向量），pgvector 不是最优解。
• 如果你的团队完全没用过 Postgres，那“省一套数据库”的优势就不存在了。

我在 DocResearch 里选 pgvector，就是因为项目本身用 Postgres 存文档元数据，向量放同一个库，检索的时候一条 SQL 就能把“向量相似度 + 元数据过滤”一起做完，不用在应用层做两次查询再合并。这个设计在面试里讲出来，比单纯说“pgvector 方便”有说服力得多。

3.2 索引类型的选择逻辑

pgvector 支持两种索引：IVFFlat 和 HNSW。很多人建索引的时候随便选一个，结果查询慢得离谱。这两个索引的区别，用大白话讲：

• IVFFlat：把向量空间划分成若干个簇，查询的时候只查最近的几个簇。建索引快，内存占用小，但召回率依赖簇的数量，需要调参。
• HNSW：建一个多层图，查询的时候在图上走。查询快，召回率高，但建索引慢，内存占用大。

我的选择逻辑是：数据量小、写入频繁、对召回率要求不是极致 → IVFFlat；数据量中等、查询频繁、召回率要求高 → HNSW。DocResearch 里文档更新不频繁但查询很频繁，所以我选了 HNSW。

建索引的时候有个坑：HNSW 的m和ef_construction参数直接影响索引质量和构建时间。m是每个节点的连接数，越大召回率越高但内存越大；ef_construction是构建时的候选集大小，越大索引质量越好但构建越慢。我一般从m=16, ef_construction=64开始调，数据量大的时候会加到m=32, ef_construction=128。

查询的时候还有一个ef_search参数，控制查询时的候选集大小。这个参数可以在查询时动态调整，不需要重建索引。如果发现召回不够，先调这个，别急着重建。

3.3 元数据过滤和向量检索怎么配合

这是 pgvector 相比专用向量库的一个隐藏优势。假设你要查“2023 年之后的、关于检索策略的文档”，用专用向量库你可能需要先做向量检索拿到一堆结果，再在应用层过滤年份，效率很低。用 pgvector 可以直接写：

SELECT content, 1 - (embedding <=> query_embedding) AS similarity FROM doc_chunks WHERE doc_date > '2023-01-01' ORDER BY embedding <=> query_embedding LIMIT 10;

这条 SQL 里，<=>是向量距离操作符，WHERE是元数据过滤，Postgres 的查询优化器会决定先过滤还是先算距离。这个能力在面试里讲出来，面试官会觉得你确实用过，而不是只看过文档。

注意：元数据过滤的字段最好建 B-tree 索引，否则全表扫描会拖慢查询。另外，如果过滤后的结果集太小，向量索引可能反而不如全表扫描快，这时候查询优化器会自动切换，你不用手动干预。

4. 检索策略：从单路召回走向多路融合

4.1 纯向量检索的瓶颈在哪

向量检索的本质是“语义相似”，它擅长找“意思相近”的内容，但不擅长找“精确匹配”的内容。比如用户问“DocResearch 里 pgvector 的索引参数怎么设”，向量检索可能召回一堆讲向量数据库的文章，但真正包含“pgvector 索引参数”这个精确短语的 chunk 反而排不到前面。

这就是热词里说的“rag瓶颈”之一：单一检索方式无法覆盖所有查询意图。用户的问题有时候是语义型的（“怎么提高检索准确率”），有时候是精确型的（“HNSW 的 m 参数默认值是多少”），有时候是混合型的。

DocResearch 里的解决方案是多路召回 + 融合重排：

• 向量召回：负责语义匹配，用 embedding 相似度。
• 全文召回：负责精确匹配，用 PostgreSQL 的全文检索或者 BM25。
• 关键词召回：负责专有名词匹配，用倒排索引。

三路召回各自拿一批候选，然后用 RRF（Reciprocal Rank Fusion）做融合。RRF 的公式很简单：每个文档的得分是1 / (k + rank)，k 一般取 60。这个方法的妙处在于，它不需要知道每路召回的分数分布，只看排名，所以不同检索方式的结果可以直接融合。

4.2 重排模型值不值得上

多路召回之后，候选集可能有几十上百个，直接喂给大模型会超上下文，而且噪声太多。这时候需要重排。

重排模型（Reranker）和 embedding 模型的区别是：embedding 是“双塔”结构，query 和 document 分别编码再算相似度，快但精度有限；Reranker 是“交叉编码”结构，query 和 document 拼在一起过模型，精度高但慢。所以典型流程是：向量召回拿 top 100，Reranker 精排拿 top 5。

面试里经常被问“Reranker 值不值得上”。我的回答是：看你的场景对准确率的敏感程度。如果答错一个问题的代价很高（比如法律、医疗），那 Reranker 必须上；如果是闲聊型问答，Reranker 的收益可能抵不上它带来的延迟。

DocResearch 里我上了 Reranker，因为文档问答的场景下，用户对答案准确性的期望很高。实测下来，加了 Reranker 之后，top 5 的命中率从 60% 左右提升到了 80% 以上。这个提升在面试里是可以量化的，比说“效果变好了”有说服力。

4.3 查询改写：让 Agent 决定怎么查

这是 DocResearch 区别于普通 RAG 的核心模块。普通 RAG 是用户问什么就查什么，但用户的问法往往和文档的写法不一致。比如用户问“怎么让检索更准”，文档里写的是“提升召回率的策略”，直接拿用户问题去检索，效果可能不好。

Agent 在这里的作用是查询改写：

• 把口语化的问题改写成文档里可能出现的表述。
• 把复杂问题拆成多个子问题，分别检索再合并。
• 根据第一轮检索的结果，判断要不要换关键词再查一轮。

这个“判断要不要再查”的能力，就是 Agent 和固定流程的区别。实现上，我会给 Agent 一个工具集：search(query)、rerank(results)、read(chunk_id)，然后让它自己决定调用顺序。Agent 的 prompt 里会明确告诉它：“如果第一轮检索的结果和问题不相关，尝试用不同的关键词再查一次。”

提示：Agent 的查询改写不要过度。我见过有人让 Agent 把每个问题都拆成五个子问题，结果检索次数暴涨，延迟从 2 秒变成 10 秒，效果还没提升多少。拆分的粒度要控制，一般一个问题拆成 2 到 3 个子问题就够了。

5. Agent 调度：DocResearch 真正的技术分水岭

5.1 Agent 和普通 RAG 的本质区别

热词里有“harness和agent区别”“agent架构”“ai agent搭建”，说明大家对 Agent 的理解还比较模糊。用一句话讲清楚：普通 RAG 是“检索一次、生成一次”的固定流程，Agent 是“自己决定下一步做什么”的动态流程。

在 DocResearch 里，Agent 要做的决策包括：

• 这个问题需不需要检索？有些问题（比如“你好”）根本不需要查文档。
• 检索几轮？第一轮结果不够好，要不要再查？
• 用哪个检索工具？向量检索、全文检索、还是两个都用？
• 检索到的内容够不够回答问题？不够的话要不要换个角度再查？
• 什么时候停止？不能无限查下去。

这些决策串起来，就是一个 Agent 的“思考-行动-观察”循环。面试的时候，如果你能把这个循环画出来（口头描述也行），并且说清楚每一步的输入输出，面试官基本就能判断你真的实现过。

5.2 工具设计：Agent 的手和眼

Agent 的能力边界，取决于你给它什么工具。DocResearch 里我设计了四个核心工具：

工具设计的原则是：每个工具只做一件事，输入输出明确，错误处理清晰。不要设计一个“万能检索工具”让 Agent 自己选检索方式，那样 Agent 反而容易懵。把选择权交给 Agent，但把每个选项做简单。

还有一个细节：工具的返回结果要包含足够的元信息，比如 chunk 的来源文档、章节路径、相似度分数。Agent 根据这些信息判断“这个结果可不可靠”。如果只返回一段文本，Agent 没法判断质量。

5.3 怎么防止 Agent 陷入死循环

这是 Agent 开发里最实际的问题。Agent 可能会一直觉得“检索结果不够好”，然后无限查下去。防护措施有三层：

• 最大轮次限制：硬性限制 Agent 最多查 3 轮，超过就强制生成答案。
• 结果去重：如果新一轮检索的结果和上一轮高度重叠，说明再查也没用，直接停止。
• 超时控制：整个 Agent 流程设置总超时，比如 15 秒，超时就用已有结果生成。

这三层防护在面试里讲出来，面试官会觉得你考虑过生产环境的问题，而不是只跑通了 demo。

5.4 Agent 的并发问题

热词里有“ai agent 怎么扛并发”，这是个好问题。Agent 的并发瓶颈通常不在 Agent 本身，而在它调用的工具上。向量检索、Reranker、大模型生成，每一个都是耗时操作。

DocResearch 里的做法是：

• 向量检索和全文检索可以并行发起，用异步 IO 同时查，减少等待时间。
• Reranker 是 CPU/GPU 密集型，用批处理，一次重排多个 query 的候选集。
• 大模型生成用流式输出，用户不用等全部生成完才看到内容。
• Agent 的会话状态存在 Redis 里，支持多实例水平扩展。

这些优化手段，面试的时候不用全讲，但至少要能说出“瓶颈在哪、怎么定位、怎么优化”的思路。

6. 面试里怎么把模块讲成故事

6.1 用“问题-方案-结果”结构组织回答

面试官问“你这个检索模块怎么做的”，最忌讳的回答是“我用了向量检索和全文检索，然后做了融合”。这是陈述，不是故事。好的回答结构是：

• 问题：一开始只用向量检索，发现精确匹配的查询召回不好，比如用户问某个具体参数名，向量检索召回的都是泛泛而谈的文章。
• 方案：加了全文检索做多路召回，用 RRF 融合，又加了 Reranker 精排。
• 结果：top 5 命中率从 60% 提升到 80%，延迟从 1.5 秒增加到 2.2 秒，在可接受范围内。

这个结构的好处是，面试官能听到你的思考过程，而不只是最终方案。而且“结果”部分有数据，可信度立刻上来了。

6.2 主动暴露一个坑，比完美回答更加分

面试里最加分的时刻，往往是你主动说“这里我踩过一个坑”。比如：

“切分的时候我一开始用固定长度，结果检索出来的内容经常缺上下文。后来改成按结构切分，并且给每个 chunk 加上章节标题路径，召回准确率明显提升。这个改动看起来小，但效果比换 embedding 模型还明显。”

这段话里有问题、有方案、有对比、有量化，面试官会觉得你是真的做过，而不是背的。

6.3 被问到不会的怎么办

DocResearch 涉及的技术栈很广，面试官可能会问到你没用过的部分，比如“你们有没有考虑过用知识图谱”。这时候不要硬编，可以说：

“知识图谱这块我们评估过，但当时的数据量级和查询类型用向量检索加全文检索已经能覆盖，引入图谱会增加不少复杂度。如果要做的话，我会从实体抽取和关系抽取入手，把图谱作为一路召回，和现有的多路召回融合。”

这个回答承认了没做，但展示了你知道怎么做，以及为什么当时没做。面试官通常能接受这种回答。

7. 几个容易被忽略但面试常问的细节

7.1 embedding 模型怎么选

热词里有“rag框架”“rag教程”，但很少有人讲 embedding 模型的选择。DocResearch 里我对比过几个模型，选择逻辑是：

• 中文为主：选中文语料训练充分的模型，不要直接用英文模型。
• 维度：维度越高表达能力越强，但存储和检索成本也越高。768 维和 1024 维在实际效果上差距不大，但存储差 30%。
• 推理速度：如果文档量大，embedding 的生成速度直接影响入库时间。
• 是否支持长文本：有些模型只支持 512 token，超过就截断，这对长 chunk 不友好。

面试的时候，如果你能说出“我对比过 A 模型和 B 模型，在中文技术文档上 A 的召回率高 5 个百分点”，这比说“我用了某某模型”有说服力得多。

7.2 怎么评估检索效果

这是很多人忽略的环节。你改了切分策略、换了 embedding 模型、加了 Reranker，怎么知道效果变好了？靠感觉是不行的。

DocResearch 里我建了一个小规模的评估集：人工标注了 100 个问题和对应的正确 chunk。每次改动之后，跑一遍评估集，看 top 5 命中率、MRR（平均倒数排名）这些指标。这个评估集不用很大，100 条就能看出趋势。

面试的时候提到“我建了评估集来量化效果”，面试官会觉得你有工程思维，而不是只会调参。

7.3 成本控制

Agent + RAG 的成本主要来自三块：embedding 生成、向量存储、大模型调用。DocResearch 里的控制手段：

• embedding 只在文档入库时生成一次，查询时复用。
• 向量存储用 pgvector，省了一套数据库的运维成本。
• 大模型调用做缓存，相同或相似的问题直接返回缓存结果。
• Agent 的轮次限制，避免无限调用大模型。

这些在面试里不用全讲，但至少要知道成本花在哪，以及怎么控制。

8. 我踩过的几个真实坑

第一个坑是chunk 的元数据丢失。一开始我只存了 chunk 内容和向量，没存来源文档和章节路径。后来发现检索出来的内容没法溯源，用户问“这个答案从哪来的”答不上来。加上元数据之后，不仅溯源方便了，检索时还能按文档类型过滤。

第二个坑是Reranker 的输入长度超限。Reranker 模型通常有最大输入长度限制，query 加 document 超过限制会被截断。我一开始没注意，长文档的 chunk 被截断后重排效果很差。后来在切分阶段就控制了 chunk 大小，确保 query 加 chunk 不超过 Reranker 的限制。

第三个坑是Agent 的 prompt 太长导致指令遵循下降。Agent 的 system prompt 里塞了太多工具说明和规则，结果 Agent 经常忽略某些规则。后来我把 prompt 精简到只保留核心指令，把详细说明放到工具描述里，效果反而更好。

第四个坑是pgvector 的索引在数据量小的时候反而拖慢查询。数据量低于一万条的时候，全表扫描比走索引还快，因为索引本身有开销。Postgres 的查询优化器有时候会选错，需要手动分析执行计划。这个坑在面试里讲出来，面试官会觉得你真的在生产环境跑过。

9. 如果重新做一遍，我会怎么调整

如果让我重新搭一遍 DocResearch，我会在几个地方做得不一样。

第一，评估集先行。一开始就建好评估集，而不是做到一半才想起来要量化效果。有了评估集，每次改动都能快速验证，不用靠感觉。

第二，切分策略做成可配置。不同文档类型用不同的切分参数，而不是一套参数打天下。配置化之后，调优不用改代码。

第三，Agent 的工具设计更克制。工具不是越多越好，每个工具都要有明确的适用场景。工具太多，Agent 的选择成本反而高。

第四，日志和可观测性从第一天就加上。Agent 的每一步决策、每次检索的结果、每个工具的耗时，都要有日志。出了问题能快速定位，而不是靠猜。

这些调整看起来是工程细节，但面试的时候，如果你能说出“如果重做我会怎么改”，面试官会觉得你有反思能力，而不是只会执行。

10. 面试前最后检查清单

面 DocResearch 这类项目之前，我会建议你对着下面这些问题自测一遍。每个问题都要能用“问题-方案-结果”的结构讲出来，而不是一句话带过。

• 文档切分为什么不用固定长度？你的切分策略是什么？
• 为什么选 pgvector？它的边界在哪？
• 向量索引选的哪种？参数怎么定的？
• 检索用了几路？怎么融合的？
• Reranker 上了没有？效果提升多少？
• Agent 在流程里做了什么决策？怎么防止死循环？
• 检索效果怎么评估的？有没有量化数据？
• 整个链路的延迟是多少？瓶颈在哪？
• 踩过最大的坑是什么？怎么解决的？
• 如果重新做，你会改什么？

这十个问题如果能答清楚，面试基本就稳了。答不清楚的地方，就是你需要补的地方。面试不是考你背了多少术语，而是考你有没有真的把一条链路跑通、跑好、跑出数据。术语谁都能背，但踩过的坑和量化过的效果，只有真正做过的人才有。