DocResearch面试实战：从文档解析到Agent编排的RAG项目拆解

1. 面试官到底想听什么：从“背术语”到“讲明白”的认知转变

面DocResearch这类项目，很多人栽在一个很隐蔽的坑里：把面试当成期末考试，以为把Agent、RAG、pgvector这些词准确复述出来就能过关。我面过也被人面过，实话讲，术语背得再溜，只要追问一句“你这个模块为什么这么设计”，立刻就露馅。

DocResearch本质上是一个文档研究助手类的Agent项目，核心链路是：用户丢进来一批文档，系统做解析、切分、向量化、入库，然后通过RAG检索增强，让Agent带着检索到的上下文去回答或做多步研究。技术栈通常落在Python上，向量库用pgvector，编排层可能是LangChain、LangGraph或者自研的轻量Agent框架。面试官关心的不是你知不知道RAG这三个字母展开是什么，而是你能否讲清楚：文档进来之后每一步发生了什么、为什么这么切、检索命中率上不去时你怎么办、Agent循环怎么防止跑飞。

这篇东西我想按“面试时怎么把每个模块讲明白”这个角度来写，不是给你一份标准答案去背，而是给你一套拆解思路。你照着这套思路去梳理自己的项目，面试时哪怕被问到没准备的点，也能顺着逻辑推出来。适合正在准备Agent/RAG方向面试的人，也适合刚做完一个DocResearch类项目、想把它讲清楚的中级开发者。下面我按模块拆，每个模块都告诉你面试官真正想听的那层意思。

2. 文档解析与切分模块：面试官在考察你的工程判断力

2.1 为什么解析这一步最容易被低估

很多人讲项目从“我们用RAG做检索”开始讲，直接把文档解析跳过去了。这是个巨大的失分点。DocResearch面对的是真实文档，PDF、Word、Markdown、网页快照都有，解析质量直接决定后面所有环节的天花板。面试官问“你的文档怎么处理的”，他想听的不是“我用了个库”，而是你有没有意识到解析是有损的、不同格式的坑在哪、你怎么保证解析后的文本还能保留结构信息。

我自己的做法是分层处理。纯文本和Markdown直接读，保留标题层级；PDF用解析库抽文本，但一定要同时抽版面信息，因为双栏PDF直接按流式读会把左右栏串在一起，读出来是乱的。表格单独处理，不要指望通用解析器能把复杂表格还原成结构化数据，我的经验是表格要么转成Markdown表格保留，要么单独走一条结构化抽取的链路。面试时你可以主动说：“我知道PDF解析会丢结构，所以我在解析层做了标记，标题、段落、表格分别打标签，切分的时候按标签走不同策略。”这一句话就能让面试官知道你踩过坑。

2.2 切分策略：固定长度是新手做法，语义切分才是及格线

切分这块，面试官最爱问的就是“你chunk多大”。如果你回答“我设的512”，然后没有下文，基本就凉了。因为chunk size不是拍脑袋定的，它跟你的嵌入模型、文档类型、检索粒度都相关。

我一般这么讲：先按文档结构切，标题作为天然边界，一个二级标题下的内容作为一个候选块；如果这个块太长，再按语义做二次切分，用句子嵌入算相邻句子的相似度，在相似度骤降的地方断开。这样做的好处是每个chunk语义完整，不会出现一句话被切成两半、检索出来半截话的情况。chunk大小我通常控制在256到512个token之间，重叠区留10%到15%，防止边界信息丢失。为什么是256到512？因为大多数嵌入模型在512token以内的语义表征最稳定，再长就开始稀释主题了。这个数字你要能说出理由，而不是“我看别人都这么设”。

注意：切分时一定要保留元数据，比如来源文件名、页码、所属标题路径。面试官如果问你“检索出来怎么知道是哪篇文档的哪一段”，你答不上来就很尴尬。元数据是后面做引用、做溯源的基础。

2.3 面试话术：把切分讲成一个决策过程

面试时不要陈述“我用了递归切分”，而要讲成决策：“我一开始用固定长度切，发现检索出来的块经常缺上下文，后来改成按标题切加语义二次切分，命中率明显上来了。”这种带对比、带迭代的讲法，面试官会觉得你是真的做过，而不是抄了个教程。你甚至可以准备一个具体数字，比如“改完之后Top3命中率从六成出头提到了八成左右”，数字不用精确到小数点，但要有个量级感。

3. 向量化与pgvector入库：参数选择背后的取舍逻辑

3.1 嵌入模型选型：不是越贵越好，是越匹配越好

DocResearch这类项目，嵌入模型的选择直接决定检索质量。面试官可能会问“你为什么用这个嵌入模型”。这时候你要从三个维度回答：语言、维度、成本。中文文档为主就选中文语义强的模型，中英混合就要看模型的多语言能力。维度方面，768维和1536维在检索效果上差距没有想象中大，但存储和检索速度差一倍，pgvector里维度越高索引越大。我的经验是，如果文档领域比较垂直，768维足够；如果是开放域问答，1024维以上更稳。

还有一个容易被忽略的点：嵌入模型要和你的切分粒度匹配。你切256token的块，用一个训练时最大长度只有128的模型，后面那部分信息就丢了。面试时主动提这个匹配关系，是加分项。

3.2 pgvector建表与索引：IVFFlat还是HNSW

pgvector是Postgres的向量扩展，面试官问这个通常是想看你懂不懂索引。建表很简单，一个vector字段加几个元数据字段。关键是索引选型。IVFFlat建索引快、占空间小，但召回率依赖lists参数，lists设成行数除以1000是个经验值。HNSW查询快、召回高，但建索引慢、吃内存。DocResearch如果文档量在十万级以下，HNSW更省心；百万级以上要考虑IVFFlat加分区。

我一般会这么讲：“我选HNSW，因为项目文档量不大，查询延迟要求高，HNSW的m和ef_construction我设的16和64，实测召回和速度平衡得不错。”这里m是每个节点的连接数，ef_construction是建索引时的候选集大小，这两个参数你要知道调大提召回、调小提速度。面试官听到你能说出参数名和调节方向，基本就认可你上手过。

CREATE TABLE doc_chunks ( id BIGSERIAL PRIMARY KEY, doc_id TEXT NOT NULL, chunk_text TEXT NOT NULL, metadata JSONB, embedding vector(768) ); CREATE INDEX ON doc_chunks USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64);

上面这段建表语句你可以直接抄，注意vector_cosine_ops对应余弦距离，如果你的嵌入模型是归一化的，用内积也行，但余弦更通用。

3.3 批量入库与去重：工程细节见真章

面试官如果问“你入库怎么做的”，别只说“循环插入”。真实项目里文档可能重复上传，chunk可能重复。我的做法是给每个chunk算一个内容哈希，入库前先查哈希是否存在，存在就跳过。批量插入用execute_values或者COPY，比一条条插快一个数量级。这些细节讲出来，面试官会觉得你考虑过生产环境。

提示：pgvector的向量字段插入时，Python里要把list转成字符串格式，比如'[0.1,0.2,...]'，用psycopg2的execute_values批量插效率最高。这个坑我踩过，一条条插十万条能等到天荒地老。

4. RAG检索模块：命中率上不去时你怎么排查

4.1 检索链路拆解：从query到context的每一步

RAG检索不是“把问题向量化然后查库”这么简单。完整链路是：query改写、向量化、向量检索、重排序、上下文组装。面试官问RAG，你就按这条链路讲，每一步都可能被追问。

query改写这块，用户问“这个文档里关于并发的内容”，直接拿这句话去检索，可能不如改写成“并发 处理 机制”命中率高。我一般会用一个小模型或者规则做关键词抽取，把口语化问题转成检索友好的查询。向量检索就是pgvector的活，取TopK，K一般设10到20。重排序是提命中率的关键，用一个交叉编码器对TopK结果重新打分，把真正相关的排前面。上下文组装要注意token预算，别把检索结果一股脑塞给LLM，要按相关性截断。

4.2 命中率低的三个常见原因和排查顺序

面试官很爱问“检索效果不好怎么办”，这题考的是排查思路。我按顺序查三件事：第一，切分是不是把答案切碎了，如果答案跨两个chunk，检索单个chunk就答不全；第二，嵌入模型是不是不适合这个领域，通用模型在专业术语上表征可能不准；第三，TopK是不是太小，相关块排在后面没被取到。

排查方法也简单：拿几个已知答案的问题，看正确chunk在检索结果里排第几。如果排在第15位而你的K是10，那就是K的问题；如果压根没进前50，那是嵌入或切分的问题。这个“用已知答案反查排名”的方法，面试时讲出来非常加分，因为它体现你有量化排查的意识，而不是瞎调参。

4.3 混合检索：向量加关键词才是生产级方案

纯向量检索在专有名词、代码、编号上经常翻车，因为这些词的语义表征不稳定。生产级方案一般是向量检索加关键词检索，用BM25或者Postgres的全文检索，两路结果做融合。融合算法用RRF，就是按排名倒数加权，简单有效。面试时你可以说：“我做了混合检索，向量路负责语义，关键词路负责精确匹配，RRF融合后命中率比单路高不少。”这句话信息量很大，面试官会顺着问RRF怎么算，你答“每个结果得分是1除以排名加常数，两路得分相加再排序”就够了。

5. Agent编排模块：让LLM带着检索结果做多步研究

5.1 Agent循环的本质：状态机加工具调用

DocResearch里的Agent不是简单的一问一答，而是多步研究。用户问一个复杂问题，Agent要决定先检索什么、看到结果后决定下一步检索什么、什么时候停止并给出答案。面试官问Agent，你就把它讲成一个状态机：状态包括当前问题、已检索的上下文、已执行的步骤；动作包括检索、总结、回答；终止条件是模型认为信息足够或者达到最大步数。

这个讲法比“我用了ReAct”要实在得多。ReAct是论文里的框架，面试官更想听你怎么落地。你可以说：“我用的是ReAct思路，但自己控制了循环，每步把检索结果追加到上下文，让模型决定下一步动作，最多跑五步防止死循环。”最大步数这个细节很重要，Agent跑飞是常见问题，设上限是最简单的防护。

5.2 工具定义与调用：检索工具怎么写才稳

Agent调用检索工具，工具的描述和参数定义直接影响调用准确率。工具描述要写清楚“这个工具用来在文档库中检索相关段落，输入是一个查询字符串，输出是若干相关段落”。参数名用query而不是q，因为模型对完整单词的理解更稳。返回结果要截断，别把整个文档返回去，返回Top3段落加来源就行。

我踩过的坑是工具返回格式不稳定，有时候返回JSON有时候返回纯文本，导致模型解析失败。后来我强制工具返回固定结构，比如每段前面加“来源：文件名 页码：X”，模型看到这个格式就知道怎么引用。面试时讲这个坑，面试官会觉得你处理过真实问题。

5.3 防止Agent跑飞：步数、超时、循环检测

Agent跑飞的表现是反复检索同一个东西、或者陷入无意义的思考循环。防护手段有三层：第一，最大步数限制，超过就强制输出当前最优答案；第二，单步超时，检索或模型调用超过一定时间就跳过；第三，循环检测，如果连续两步的查询字符串高度相似，就打断并提示模型换方向。这三层讲出来，面试官对你的工程严谨性会有正面评价。

注意：Agent的每一步都要记日志，包括输入、输出、耗时。面试时如果被问“你怎么调试Agent”，你就说“我每步都打日志，出问题能回放整个决策链”。这是真实项目里必须做的事，也是面试官想听的。

6. 并发与性能：Agent项目怎么扛住真实流量

6.1 瓶颈在哪：模型调用和向量检索

DocResearch的并发瓶颈通常不在Python本身，而在两个地方：LLM API调用和向量检索。LLM调用是网络IO，用异步或者线程池能显著提升吞吐。向量检索如果走pgvector，连接池要配好，每个查询占一个连接，并发高了连接不够就排队。我的做法是FastAPI加异步，LLM调用用asyncio，数据库操作用连接池，pgvector查询走索引后单次在几十毫秒级，不是瓶颈。

面试官问并发，你就按“瓶颈识别、异步化、连接池、缓存”这个顺序讲。缓存这块可以提一句：相同query的检索结果可以缓存，用Redis或者内存LRU，重复问题直接命中缓存，省一次嵌入和检索。

6.2 批量请求的处理策略

如果一次来一批文档要入库，不要同步做，丢到后台任务队列，用Celery或者简单的线程池。入库是IO密集加计算密集，嵌入计算可以批处理，一次算一批比一条条算快很多。面试时你可以说：“嵌入我做了批处理，batch size设32，再大显存或内存吃紧，再小吞吐上不去。”这个32不是绝对的，但你要能说出调节方向。

6.3 监控与降级：生产环境必须有的兜底

面试官如果问“线上出问题怎么办”，你要有降级方案。LLM调用超时或失败，降级到只返回检索结果不做生成；向量检索失败，降级到关键词检索；数据库连接不上，返回缓存结果或友好提示。这些降级策略讲出来，说明你考虑过可用性，而不是只跑通demo。

7. 面试实战：怎么把模块串成一个完整故事

7.1 项目介绍的黄金三分钟

面试开场让你介绍项目，不要从技术栈开始念。按“问题、方案、效果”讲：先说这个项目解决什么问题，比如“帮研究人员从大量文档里快速找到答案并做多步分析”；再说方案，按数据流讲，文档进来怎么解析切分入库，查询进来怎么检索重排生成；最后说效果，用一两个数字，比如“检索命中率八成以上，单次问答延迟两秒内”。三分钟讲完，面试官就知道你脑子里有完整链路。

7.2 被追问细节时的应对框架

被追问某个模块，用“是什么、为什么、怎么做、遇到什么问题”四步回答。比如问切分，先说切分是什么，再说为什么这么切，然后说具体参数，最后说踩过的坑。这个框架能保证你回答有结构，不会东一句西一句。如果真被问到不会的，别硬编，说“这块我当时用的是默认配置，没深入调，我的理解是……”然后给出你的推理。面试官能接受你不会，但不能接受你瞎说。

7.3 反向提问：展示你对项目的思考深度

面试最后让你提问，别问“公司用什么技术栈”这种泛泛的。问“你们现在的RAG检索命中率大概什么水平，主要瓶颈在哪”或者“Agent这块你们怎么控制成本和延迟”。这种问题显示你懂行，也显示你关心真实问题。我面人的时候，候选人问出这种问题，印象分直接拉高。

8. 我踩过的坑和给你的实操建议

第一个坑是过度依赖框架。我一开始用LangChain的默认链，出问题根本不知道哪一步错了，后来把检索、重排、生成拆成独立函数，每个函数可测可调，排查效率高了一个量级。面试时你可以说“我后来把链路拆开了，方便定位问题”，这是成熟开发者的做法。

第二个坑是忽略元数据。早期入库只存了文本和向量，检索出来不知道来源，做引用的时候抓瞎。后来加了doc_id、页码、标题路径，引用和溯源都顺了。这个改动不大，但面试时讲出来很显专业。

第三个坑是Agent步数不设限。有次测试一个问题跑了二十多步，烧了一堆token还没答案。后来设了最大五步，超了就输出当前结果，成本可控。面试官问成本控制，这就是现成的例子。

第四个坑是pgvector索引没建对。一开始没建索引，几万条数据查询要好几秒，建了HNSW之后降到几十毫秒。索引这个事，数据量小的时候感觉不到，一大就暴露。面试时提一句“我建了HNSW索引，查询延迟从秒级降到毫秒级”，很有说服力。

最后分享一个小技巧：准备面试时，拿一张白纸，把DocResearch的数据流画出来，从文档输入到答案输出，每个节点标注你用的技术、参数、遇到的问题。画完这张图，面试时不管问哪个模块，你都能定位到图上那个点，然后展开讲。这比背一百个术语都管用。我每次准备项目面试都这么干，画三遍，讲的时候脑子里有图，嘴上就不慌。