项目四：AI 政务助手（办事指南问答 / 政策解读 / 公文辅助）

2024.11 - 2025.03 | 杭州掌奇网络科技有限公司 | Agent / RAG 开发

内部答辩底稿。正文所有效果数字统一写 <待核实>，简历示例值只出现在第六节对照表。

一、30 秒定位

这是给区级政务和数据管理部门做的本地化 AI 服务平台。政务场景和企业问答最大的不同是"答对"的定义更硬：办事指南要说清材料、窗口、时限，政策解读必须指到具体文号和条款，而且政策有版本、有效力范围、有失效日期，答一条过期政策比答不出来更严重；同时全部要在内网跑，不能调外部 API。我做的是三块：用 LangGraph 搭"入口路由 + 办事指南 / 政策解读 / 公文辅助三个领域子图"的状态机；建政务知识入库流水线，把版面解析、层级切分和元数据（版本、发布部门、效力范围、发布日期、条款位置）做成可增量重建的链路；以及 Elasticsearch BM25 加 pgvector 双路召回、RRF 融合、Reranker 精排的检索层。另外把确定性规则从模型里剥出来——字段校验、有效期过滤、公文格式检查、权限控制全部由代码判定，模型只负责意图识别、查询改写和文本生成。试点上线后建了一套覆盖三类场景的评测集来盯准确率和引用完整率，具体数值 <待核实>。

需你本人确认（重要）

这个项目的时间是 2024.11-2025.03，在掌奇网络，而简历上掌奇的岗位是"企业应用开发工程师（2022.06-2025.03）"。面试官一定会问"企业应用开发的岗位上，你怎么做起 AI 项目的"。第七节第 1 条给了说法，但团队人数、谁带这个项目、你的实际投入比例、上线部门数需要你填实。 另外简历不同版本里掌奇的离职时间写过 2024.10 与 2025.03 两个值，投递前必须统一，否则这个项目的时间会直接对不上。

二、架构与我的位置

模块	归属	我的具体交付
LangGraph 主图 + 三个领域子图	我	State 分层、条件边、澄清与重试、人工兜底分支
知识入库流水线	我	解析、层级切分、元数据模型、增量重建与失效过滤
双路召回 + RRF + Rerank	我	ES 映射与查询、pgvector 索引、融合与精排、按查询类型选策略
确定性规则层	我	字段校验、有效期过滤、公文格式检查、权限过滤条件下推
引用组装与拒答	我	引用结构（文件 / 条款 / 位置）、引用校验、拒答与转人工
前端问答与公文页面	我	这是我原岗位的强项，SSE 事件渲染与结果展示由我做
vLLM 部署与 GPU 环境	运维 + 客户方 IT（我提需求并联调）	我定并发、超时、上下文长度等参数需求，不负责机房与驱动
内网隔离、等保与信创要求	客户方 IT	我按约束做技术选型（不出网、组件国产化清单）
语料、政策口径、评测答案	政务业务方	我设计评测集结构与打分规则，正确答案由业务方确认

三、简历每条 bullet 的展开与追问树

bullet 1：基于 LangGraph 设计"入口路由 + 三个领域子图"的 Multi-Agent 状态图；主图仅维护意图、用户权限和最终结果，子图分别维护检索证据与中间状态，通过条件边完成路由、澄清、重试和人工兜底

要讲什么

• 三类应用的处理形态完全不同：办事指南是"事项字段查询"（材料、时限、窗口，字段化强）、政策解读是"条款检索 + 归纳"（必须带文号和条款）、公文辅助是"格式约束下的生成"（几乎不依赖检索，但要过格式检查）。硬塞进一张图会让条件分支和 prompt 互相干扰，所以按形态拆子图。
• 主图 State 刻意做薄：只有意图、用户权限上下文、当前子任务、最终结果与引用。这样权限判定只发生一次并能下推给检索，也避免各子图把中间证据污染成全局状态。
• 每个子图自己维护领域中间态：候选事项、召回证据与得分、改写后的 query、格式检查结果。子图之间不共享证据，跨场景需要时由主图转交结构化字段。
• 条件边承担四件事：路由（去哪个子图）、澄清（缺关键条件时反问，比如没说区县或没说申请人身份）、重试（召回为空则换检索策略再来一次，有次数上限）、人工兜底（低置信或引用不足则给人工入口并留痕）。
• 不做的事也要讲：没有让子图之间自由 handoff，路由决策集中在入口，因为政务场景要能解释"这个回答是走哪条链路产生的"。

必然被追问

• 三个子图为什么不合成一个图多加几个分支？ 三类任务的输入约束、检索策略、输出校验规则都不同；合并后条件边爆炸、prompt 互相污染、改一类要回归三类。拆开后独立评测、独立发布。
• 权限为什么放主图？ 权限决定"能看哪些文件、哪些效力范围"，必须在检索之前生效并作为过滤条件下推到 ES 与 pgvector 查询里；放子图会出现某个子图漏加过滤的风险。
• 澄清怎么判断该问什么？ 按事项必填条件表判断缺哪个（区县、申请人类型、办理情形），一次把缺的问全，不做多轮挤牙膏；能从用户身份推断的不问。
• 重试的终止条件？ 检索重试次数上限、最大循环次数、以及"换了策略仍无证据就拒答"三重终止。上限值 <待核实>。
• State 里放了什么，为什么不放全文？ 放引用 ID、条款位置、得分和摘要，不放全文，避免 checkpoint 膨胀和序列化开销。

追到底会问

• 主图和子图的 State schema 怎么映射？ 子图有独立输入输出模型，进子图时只注入意图 + 权限 + 用户问题，出子图时返回答案、引用列表、置信度、是否需要人工。
• 公文辅助几乎不检索，为什么也做成子图？ 它的价值在生成后的格式校验与模板约束，用图表达"生成 → 校验 → 不合规回修 → 上限后交人工"这条带回边的链路最自然。
• 如果要再加"数据申请"这类第四个场景呢？ 加子图 + 意图枚举 + 该场景的必填条件表和评测用例，主图不动。

答不上来时的兜底话术

我的拆分依据是"输入约束、检索策略、输出校验"三者是否一致，不一致就独立成子图。具体某个条件边的判定逻辑我可以按当时的必填条件表讲一下。

原理补课：LangGraph State、子图与条件边、Multi-Agent 路由与人工兜底

bullet 2：构建政务知识入库流水线，对办事事项、政策法规和公文模板进行版面解析、层级切分与元数据标注，保留文件版本、发布部门、效力范围、发布日期和条款位置，支持政策更新后的增量重建与失效数据过滤

要讲什么

• 政务语料的难点在结构：政策文件有"章-条-款-项"的层级，办事指南有强字段（申请材料、办理时限、受理窗口、法定依据），公文有模板。按固定长度切窗口会把一条完整条款切两半，也会把材料清单表格切碎，检索出来的证据没法直接支撑回答。
• 所以切分按文档结构走：政策按条款为最小单元切，长条款再按款项细分并保留父级标题链；办事指南按字段块切，一个字段块就是一个可回答单元；表格单独抽取保留结构而不是拉平成文本。
• 元数据是这个项目的核心资产，不是附属信息：文件名与文号、发布部门、发布日期、生效与失效日期、效力范围（适用区域与对象）、版本号、条款位置。检索时靠它做过滤，回答时靠它组装引用，政策更新时靠它判断谁该失效。
• 增量重建按文件维度做：新版本入库后旧版本置为失效而不是物理删除（政务需要留痕，也可能要查历史政策），检索默认只查有效版本；同一文件重复上传按内容哈希去重，只重算变化的块。
• 入库是耗时任务，走异步队列执行，状态可查、失败可重试、每一步有日志，不阻塞在线接口。

必然被追问

• 版面解析用什么？扫描件怎么办？ 需说明当时选型 <待核实>（PDF 文本层优先，扫描件走 OCR）；重点讲坑：双栏、页眉页脚、跨页表格、目录页、印章遮挡，以及"解析质量决定检索天花板"这个判断。
• 切分粒度怎么定？ 以"能独立支撑一个回答的最小单元"为准；条款级 + 父标题链 + 相邻块重叠。粒度参数 <待核实>，是靠评测集上的召回率与答案完整性调出来的，不是拍的。
• 政策更新了怎么保证不再答旧的？ 版本 + 失效日期是检索的硬过滤条件，不依赖模型判断新旧；旧版本保留但默认不可见，只有明确要求查历史时才放开。
• 元数据从哪来？靠人工标还是抽取？ 结构化来源（政务事项库）直接映射；文件类靠正则 + 位置规则抽文号与日期，抽不到的进人工确认队列。不允许"抽不到就留空"，因为留空等于绕过过滤。
• 入库失败怎么办？ 任务级重试 + 失败原因分类（解析失败、编码问题、Embedding 服务不可用），失败文件不进检索可见集合，避免半成品污染召回。

追到底会问

• 同一政策被多个文件引用，重复内容会不会重复召回？ 内容哈希去重 + 融合后按文件维度做多样性控制，避免五条结果全是同一份文件的相邻条款。
• 重建时会不会出现"新旧共存"的时间窗？ 会，所以采用先写新版本、切换可见标记、再置旧版本失效的顺序，检索侧按可见标记查询；避免中间态出现两个有效版本。
• 文档量涨十倍这条流水线撑不撑得住？ 瓶颈在解析和 Embedding，是可水平扩的队列消费者；pgvector 的索引规模与召回延迟是要观察的点，超过阈值会考虑换专用向量库。当时规模 <待核实>。

答不上来时的兜底话术

这条链路上我最关键的判断是"元数据不是附属信息，是过滤条件和引用依据"，所以宁可在入库阶段多花人工确认，也不让缺失元数据的文档进检索。

原理补课：文档解析、切分与元数据设计、异步入库与增量更新

bullet 3：设计 Elasticsearch BM25 + pgvector 向量双路召回，使用 RRF 融合后经 Reranker 精排；按查询类型动态选择原始 Query、Multi-Query 或政策条款过滤，最终返回文件、条款和来源位置

要讲什么

• 为什么必须双路：政务问题里有大量精确串——文号、事项名称、条例简称、表单名。这类查询向量检索会"语义相近但文号不对"，BM25 能精确命中；反过来"我想问社保能不能异地办"这种口语化问法 BM25 命中不了，需要向量。两类失败模式互补，所以两路都要。
• 融合用 RRF 而不是把两路分数加权相加：BM25 分数和向量相似度不同量纲、不同分布，加权相加的权重没有稳定含义，换一批数据就失效；RRF 只用排名，鲁棒得多，代价是丢掉了分数的绝对信息。
• 精排是质量的关键一跳：召回阶段放宽取更多候选（保召回），Reranker 做 query-文档对的精细打分后只留少量进上下文（保精度和 token 预算）。精排分数还兼任拒答阈值的依据。
• 查询策略按类型动态选：明确文号或事项名走原始 query + 元数据过滤（条款过滤、有效期过滤）；口语化模糊问法走 Multi-Query 改写（生成若干个不同措辞的检索式再合并）；追问类问题带上会话已确认条件重写。改写不是无条件开，因为它成倍增加检索开销和延迟。
• 返回结构不是一段文本，而是"文件 + 条款 + 位置"三元组，前端能定位到原文，这在政务场景是刚需——工作人员必须能自己核对。

必然被追问

• 为什么不只用向量检索？ 政务问题精确串比例高，向量对文号、事项全称、否定与限定词不敏感；只用向量的典型错误是召回相近政策的错误条款。
• RRF 的 k 怎么取，两路权重怎么设？ RRF 常规取 60 量级，作用是压平头部排名的过度优势；两路可以给权重但要在评测集上验证。我的取值 <待核实>。
• Reranker 用的什么模型？延迟多少？ 需核实具体模型 <待核实>。要讲的是工程约束：候选数直接决定精排耗时，所以召回条数与精排条数是一组要一起调的参数，且精排要能并发或批处理。
• 两路检索是串行还是并发？ 并发发起再融合，否则延迟叠加。这也是我在 FastAPI 里用异步的地方。
• Multi-Query 会不会引入噪声？ 会，改写越多召回越杂，所以改写结果要经过同样的融合与精排，并且只在判定为模糊问法时启用。

追到底会问

• 怎么证明双路比单路好？ 在同一评测集上分别跑单路向量、单路 BM25、融合、融合+精排四组，看 Recall@K 与最终答案准确率的差值。这套对比是我调参的依据，具体数值 <待核实>。
• 效果不好时你怎么定位是召回问题还是生成问题？ 分层看：先看正确证据是否在召回结果里（召回问题→改切分、改策略、改元数据），在里面但答错就是生成或上下文构造问题（改 prompt、改精排条数、改引用约束）。不做这个拆分就只能瞎调 prompt。
• 权限过滤怎么和检索结合，会不会先召回再过滤导致结果变少？ 过滤条件必须下推进 ES query 与向量查询的 where 条件，不能召回后再过滤；否则 top-k 被无权限文档占满，等于变相削减召回。
• pgvector 用什么索引？ 需核实 <待核实>（HNSW 或 IVFFlat）。要讲的是取舍：索引类型影响构建时间、内存与召回率，且近似检索的召回率是可调的，不能默认"向量检索一定能找到"。

答不上来时的兜底话术

检索这块我的方法是先建评测集再调参数，单路 / 融合 / 精排三组对比着看 Recall 和最终准确率，具体某个参数值我需要回去查配置，但调参逻辑我可以完整讲。

原理补课：双路召回、RRF 融合与 Rerank、权限过滤前置到检索条件

bullet 4：将确定性规则与模型推理解耦——代码负责事项字段校验、政策有效期过滤、公文格式检查和权限控制，LLM 负责意图识别、查询改写、政策解读和文本生成；低置信度或引用不足时拒答并转人工

要讲什么

• 这是我在这个项目里最想讲的一条设计原则：凡是有确定答案的判断，都不交给模型。政策是否在有效期内是日期比较，用户能否看这份文件是权限查询，公文格式是否合规是规则匹配——这些交给模型就等于把确定性问题变成概率问题。
• 模型只做它擅长的三件事：把自然语言变成结构化意图、把口语问法改写成检索式、把检索到的条款组织成人能读的解释和公文初稿。
• 解耦的直接好处是可测：规则层可以写单元测试，模型层用评测集打分，出问题能立刻分清是规则错还是模型错。全靠 prompt 的系统这两件事是混在一起的。
• 拒答条件也是规则而不是模型自觉：引用为空、精排最高分低于阈值、答案句子无法被引用覆盖、意图置信度低且澄清后仍不明确——命中任一条走拒答 + 人工兜底，并给出原文片段和人工入口。
• 政务场景里"我不确定，这是原文，请你核对"是完全可接受的输出；硬答一条过期政策才是事故。这个取向要在面试里明确说出来。

必然被追问

• 为什么不让模型判断政策是否有效？它能读到日期。 能读到不等于稳定判断，还涉及"发布日期 / 生效日期 / 失效日期 / 修订版本"的组合语义；日期比较是零成本、零错误率的代码逻辑，没有理由交出去。
• 公文格式检查具体检查什么？ 需核实当时规则清单 <待核实>，讲得出的是形态：标题层级与编号、称谓与主送单位、成文日期格式、附件与落款、禁用表述与错别字词表。检查结果结构化返回，让生成节点按错误项回修，有次数上限。
• 引用不足怎么定义？ 答案中的每个事实句都要能对上至少一条引用片段；对不上的句子要么删除要么整体拒答。这需要生成时就要求模型按句标注引用 ID，生成后做校验。
• 拒答阈值怎么定？ 在评测集上画准确率与拒答率的权衡曲线，选业务能接受的点；政务场景我倾向宁可多拒。取值 <待核实>。
• 转人工怎么闭环？ 生成工单或留言给业务人员，带上问题、召回证据、拒答原因；人工答复后回填，可作为语料补充。当时的闭环形态 <待核实>。

追到底会问

• 规则和模型冲突时听谁的？ 听规则。模型说这条政策适用但规则判定已失效，直接按失效处理并提示用户查看最新文件。
• 模型按句标引用它做不到怎么办？ 三种做法：prompt 约束 + 结构化输出、生成后用检索片段做句级对齐校验、或者干脆改成"先抽取条款再模板化组织"。R1 这类推理模型格式遵循较弱时更依赖后两种。
• 这套解耦会不会让回答变得死板？ 会牺牲一些流畅度和覆盖率。政务场景我认为这个交换是对的，但我会说清楚代价，而不是假装没有代价。

答不上来时的兜底话术

我的判断标准很简单：能写成单元测试的逻辑就不要交给模型。具体某条规则的实现细节我可以按当时的校验清单展开。

原理补课：引用校验、拒答策略与降级矩阵、生成层与检索层分层评测

bullet 5：使用 vLLM 在内网部署 DeepSeek-R1，通过 Redis 管理会话和热点结果；设置模型超时、节点重试、最大循环次数和结构化降级，通过 SSE 输出节点事件并记录检索、生成、引用和异常轨迹

要讲什么

• 为什么必须内网：政务数据不能出网，这是硬约束不是选型偏好。所以模型只能本地部署，选型空间被显存和内网可获得的权重限制住。
• 选 vLLM 的理由是服务化能力：连续批处理（continuous batching）与 PagedAttention 让并发请求共享显存、提高吞吐，并且原生提供 OpenAI-compatible 接口，应用层不用为本地模型写特殊适配。GPU 与环境由运维和客户方 IT 负责，我提参数需求并联调。
• Redis 有两个用途要分清：会话状态（多轮上下文、已确认条件，带 TTL）和热点结果缓存（高频办事指南问题的答案与引用，按问题归一化后的 key 缓存）。缓存必须带版本号，政策更新后要能整批失效——否则会缓存出过期答案，这是政务场景不可接受的。
• 韧性四件套：模型调用超时、节点级重试（只对可重试错误）、最大循环次数、结构化降级。降级不是报错，而是有序退化——精排不可用降级为只用融合结果、生成不可用降级为直接返回原文条款、模型完全不可用降级为检索结果列表 + 人工入口。
• SSE 推节点事件（正在理解问题 / 正在检索 / 正在生成 / 引用就绪），并配一条完整轨迹日志：query 与改写结果、召回与精排候选及得分、最终引用、耗时分解、异常。轨迹日志的价值是能事后回答"这条错误答案是哪一环出的问题"。

必然被追问

• 为什么选 DeepSeek-R1 这个推理模型做 RAG 问答？ 诚实答法：政策解读和公文起草确实受益于更强的推理与长文本组织能力，且当时内网可获得的权重里它效果最好；但它的代价很明确——输出慢、思维链占 token、格式遵循弱。所以我做了两件事：不把结构化任务（意图枚举、字段抽取）交给它按自由文本输出，而是用受限枚举 + 后处理；以及在延迟敏感的路径上考虑用小模型或规则替代。是否混用过第二个模型 <待核实>。
• 思维链要不要给用户看？ 不直接展示。政务用户看到模型"纠结推理"的过程会降低信任，还可能把中间猜测当结论；做法是折叠或只推阶段事件，最终只输出结论 + 引用。思维链保留在日志里用于排查。
• 怎么控制延迟？ 首字延迟靠 SSE 阶段事件先给反馈（检索完成就先把命中的文件和条款推给前端），生成侧限制最大输出长度、控制上下文条数、热点问题走缓存；能不走大模型的路径（字段型办事指南查询）直接模板化回答。实测延迟 <待核实>。
• 显卡型号、显存、量化、并发吞吐？ 全部 <待核实>。要讲得出的框架：显存主要被权重和 KV cache 吃掉，上下文越长、并发越高 KV cache 越大；所以 max_model_len、max_num_seqs、gpu_memory_utilization 是一组要一起定的参数；量化（如 AWQ/GPTQ）能降显存但对精度和长文本有影响，是否量化需权衡。
• 为什么不用 Ollama？ Ollama 定位是本地单机便捷推理，批处理与高并发调度能力不如 vLLM；小规模试用可以，多用户服务化场景吞吐差距明显。这是场景差异不是优劣。

追到底会问

• KV cache 是什么，为什么它决定并发？ 自回归生成要缓存每层每 token 的 key/value 避免重复计算，显存占用随并发数 × 上下文长度线性增长；vLLM 用分页管理减少碎片、支持前缀共享。并发上限本质是显存能装多少 KV。
• 并发上来显存不够会怎样？ 请求排队或被抢占（重算），表现是延迟陡增甚至超时。工程上要在应用层加并发闸门与队列，宁可排队并告知用户，也不让请求全压到推理服务后集体超时。
• 超时预算怎么分配？ 从用户可接受等待时间倒推：前端上限 → 检索预算 + 精排预算 + 生成预算，每段单独设超时，任一段超时走对应降级路径而不是整体失败。具体数值 <待核实>。
• 热点缓存的 key 怎么设计？ 归一化问题（去标点、同义词映射）+ 权限维度 + 知识库版本号。不带权限维度就会跨权限泄露答案，不带版本号就会答过期政策。
• Docker 部署在内网怎么处理依赖？ 离线镜像 + 私有仓库，模型权重与镜像分离挂载；这块是运维主导，我配合定 compose 与健康检查。

答不上来时的兜底话术

推理服务的具体硬件参数是运维同学定的，我更清楚的是应用侧怎么配合——超时预算怎么切、并发闸门放哪、降级链路怎么退，这三件事我可以完整讲。

原理补课：SSE 阶段事件与流式失败降级、Redis 缓存与 TTL、Docker 与部署

四、关键技术决策与备选方案

决策点	我的选择	备选方案	为什么这么选	代价
模型部署位置	内网本地部署	云端 API、混合（脱敏后出网）	政务数据不出网是硬约束，没有讨论空间	受显存与内网可获取权重限制，运维成本高，模型迭代慢
模型选型	DeepSeek-R1（推理模型）	同尺寸 Instruct 模型、大小模型混用	政策解读与公文起草需要较强推理与长文组织；当时内网可得权重中效果最好	输出慢、思维链耗 token、格式遵循弱，结构化任务需额外后处理
推理服务	vLLM	Ollama、TGI、llama.cpp	连续批处理 + 分页 KV cache 支撑多用户并发，OpenAI-compatible 接口降低接入成本	部署与调参复杂，对显存与驱动环境要求高
检索架构	BM25 + 向量双路 + RRF + Rerank	纯向量、纯 ES、向量后接关键词过滤	政务问题精确串与口语化问法并存，两类失败模式互补	组件多、链路长、延迟叠加，需要并发发起
融合方式	RRF（基于排名）	加权分数相加、级联召回	两路分数量纲与分布不同，加权权重不稳定；RRF 只用排名更鲁棒	丢失分数绝对信息，需要精排分数来做拒答阈值
向量存储	pgvector	Milvus、Qdrant、ES 自带向量	政务运维偏好组件少、可备份、走已有 PG 运维体系；规模在可控范围内	大规模下召回延迟与索引构建是瓶颈，需要预留迁移方案
切分策略	按条款 / 字段块层级切分 + 父标题链	固定长度窗口、按页切	条款是政务问答的最小可引用单元，切碎就无法溯源	解析规则与文档格式耦合，新格式要补规则
有效期与权限判定	代码规则 + 检索条件下推	交给模型判断、召回后再过滤	日期比较与权限查询是确定性问题；后过滤会让 top-k 被无权文档占满	元数据必须完整，缺失元数据的文档不能进检索
引用输出	结构化"文件 + 条款 + 位置" + 引用校验	模型自由写来源、只给文件名	政务用户必须能核对原文，文件名级引用无法定位	生成侧约束更强，模型格式遵循差时需要后处理兜底
思维链呈现	不展示，仅推阶段事件，思维链入日志	全量展示、完全隐藏且无事件	中间推理会误导用户，但完全无反馈体验更差	需要额外设计事件协议
兜底策略	分级降级（精排→融合→原文→人工）	直接报错、低置信也强答	政务场景答错代价高于答不出	拒答率是业务方敏感指标，需要数据解释

五、故障与取舍

全节需替换

以下是这类项目通常会遇到的问题形态。⚠️ 需替换为你真实遇到的问题，尤其是政策更新和解析类问题——面试官会追问你怎么发现、怎么定位的。

故障 1：政策更新后仍答出旧版本内容 ⚠️ 需替换为你真实遇到的问题

• 现象：新版办事指南上线后，问答仍返回旧材料清单，业务方直接反馈"答错了"。
• 定位：三处都可能——旧版本 chunk 没置失效、检索没带有效期与版本过滤、热点缓存里存着旧答案。查轨迹日志看召回到的 chunk 元数据即可分辨。
• 处理：把版本与有效期做成检索的硬过滤条件；重建按"写新版本 → 切换可见标记 → 置旧版本失效"的顺序避免中间态双有效；缓存 key 带知识库版本号，更新即整批失效。
• 沉淀：知识更新链路必须做端到端验证，不能只验证"新文档能被搜到"，还要验证"旧文档搜不到"。

故障 2：推理模型输出的结构化结果解析失败 ⚠️ 需替换为你真实遇到的问题

• 现象：要求返回意图枚举或引用标注的 JSON，模型在思维链后夹杂说明文字，解析报错，节点重试后仍失败。
• 定位：推理模型对严格格式遵循不稳定，尤其在长上下文与复杂指令下；单纯加"只输出 JSON"这类 prompt 约束不可靠。
• 处理：受限枚举 + 容错解析（提取最后一个合法 JSON 块）+ 二次抽取兜底；把强格式要求的环节改成规则或小模型处理；解析仍失败走结构化降级路径而不是把异常抛给用户。
• 沉淀：选推理模型要为"格式不稳定"预留后处理成本，这是选型时就该算进去的代价。

故障 3：跨页表格被解析成乱序文本，材料清单答不全 ⚠️ 需替换为你真实遇到的问题

• 现象：问"办这个事要带哪些材料"，回答漏项或顺序错乱，但原文材料清单是完整的表格。
• 定位：版面解析把跨页表格拉平成一行文本，表头与单元格错位；切分又把它切断，召回到的片段本身就是残缺的。
• 处理：表格单独识别并保留结构化形式，表格块不参与常规长度切分；表头随每个表格块保留；解析后加抽样人工校验，解析异常的文件不进可见集合。
• 沉淀：RAG 效果差先怀疑解析，不要一上来调 prompt——检索质量的天花板在入库阶段就定了。

故障 4：并发上来后请求集体超时 ⚠️ 需替换为你真实遇到的问题

• 现象：多个部门同时试用，响应从可接受变成长时间无返回，甚至前端连接断开。
• 定位：推理服务并发受显存与 KV cache 限制，请求在服务端排队；应用层没有闸门，所有请求都压进去一起变慢；同时长时间无 SSE 事件被网关判定空闲断连。
• 处理：应用层加并发上限与排队，超限直接返回"排队中"提示；SSE 加心跳；检索完成先推证据事件让用户有反馈；高频问题走缓存绕过生成；与运维一起调 max_num_seqs 与上下文长度上限。
• 沉淀：本地部署模型的容量是硬上限，容量控制必须做在应用层，不能指望推理服务自己扛。

六、数字口径待核实

使用规则

面试中一律先说口径再说数字。未经核实的示例值不要在面试中说出来。硬件与部署参数即使记不清具体值，也必须能讲清"这些参数之间是什么关系、为什么要一起调"。

简历表述	简历示例值	真实值	该怎么算	证据在哪
评测集规模	180 条	<待核实>	三类场景各多少条、谁出题、正确答案谁确认、是否包含应拒答用例	评测集文件与标注记录
办事指南回答准确率	91%	<待核实>	正确条数 / 总条数。必须先定"正确"的判定规则（关键字段全对？允许表述差异？漏一项算不算错）与判定人	评测跑批结果 + 业务方确认记录
政策引用完整率	93%	<待核实>	引用齐全且指向正确条款的条数 / 需要引用的条数。要定"完整"含义（文号 + 条款 + 位置是否都要有）	引用校验脚本输出
公文初稿处理时间：小时级 → 分钟级	小时级 → 分钟级	<待核实>	需给出对照基线：原来人工起草平均耗时怎么测的、样本多少、是否含审核环节	业务方访谈或试点记录；若无记录建议改为定性表述
常规政策解读耗时	小时级 → 分钟级	<待核实>	同上，需明确是端到端答复时间还是系统响应时间	同上
上线试点范围	三类应用	<待核实>	覆盖部门数、用户数、日均问答量	试点记录、访问日志
知识库规模	未写	<待核实>	文档数、条款/chunk 数、总字数	入库统计表
检索指标	未写	<待核实>	Recall@K、精排后命中率；建议给单路 / 融合 / 融合+精排三组对比	检索评测脚本
拒答率与转人工率	未写	<待核实>	拒答会话 / 总会话，并按原因分类（无证据、低置信、权限不足）	轨迹日志聚合
端到端延迟（首字 / P95）	未写	<待核实>	首个 SSE 事件延迟与完整回答 P95，分解到检索 / 精排 / 生成	耗时埋点
GPU 型号与显存	未写	<待核实>	卡型号、张数、单卡显存	运维配置或你的记录
模型规格与量化方式	DeepSeek-R1	<待核实>	具体参数规模与是否量化（AWQ/GPTQ/FP16），上下文长度上限	vLLM 启动参数
vLLM 并发与吞吐	未写	<待核实>	max_num_seqs、max_model_len、gpu_memory_utilization、实测并发与 token/s	vLLM 启动配置与压测记录
项目团队规模与我的角色	未写	<待核实>	总人数、是否有算法同学、我的实际投入比例与起止时间	你本人回忆（与第七节身份问题口径一致）

七、这个项目会被挑战的地方

1. "企业应用开发工程师"的岗位上，你怎么做起 AI 项目的

这是这个项目最容易被问住的地方，也是唯一必须提前想好措辞的问题。

• 面试官的疑虑：岗位与项目不匹配，怀疑这个项目是挂名、是别人做的、或者干脆是编的。
• 可用的诚实说法（骨架，需你填实细节）：公司当时承接区里的政务信息化项目，AI 服务平台是里面的试点方向，团队是从现有交付团队里抽人组的，没有单独的 AI 岗编制，所以我的岗位名称一直没变。我最初进这个项目是做前端交付（问答界面、流式渲染、结果展示），这部分本来就是我的职责；后来因为项目缺后端和 RAG 的人，我承接了入库流水线、检索链路和状态图编排，从 2024 年 11 月开始主要投入在这块。岗位名称没改，实际做的事变了——这也是我后来专门跳到 AI 应用开发岗（亿达）的原因。
• 为什么这个说法站得住：它解释了岗位不变的原因（无编制、内部抽调），承认了起点是前端（与简历一致），给了角色转换的动因（项目缺人），并且和下一段经历形成因果（所以我换了工作）。比"我一直在做 AI"可信得多。
• 必须能答的追问：项目几个人？谁带？有没有算法同学？你的代码占比？上线在哪几个部门？这个时间段你还在做原来的前端项目吗（如果是并行，要如实说投入比例）？——这些答不上来，前面的说法就崩了。<待核实>
• 不要说的话：不要说"我主导了整个项目"，不要把客户方 IT 和运维做的部署说成自己做的。

简历自查

掌奇的离职时间在不同简历版本里出现过 2024.10 和 2025.03 两个值。这个项目跨到 2025.03，如果简历写 2024.10 离职，时间直接矛盾。投递前必须统一，建议统一为 2022.06-2025.03。

2. 为什么用推理模型做 RAG 问答

• 质疑点：R1 这类推理模型输出慢、思维链长、不擅长严格遵循格式，做检索问答属于"用错工具"；同尺寸的 Instruct 模型更快更听话。
• 应答方向：分任务看——政策解读和公文起草确实需要更强的推理与长文组织，这是选它的理由；但结构化环节（意图枚举、字段抽取、引用标注）我没有依赖它的自由输出，而是用受限枚举 + 后处理 + 校验兜住。同时主动说代价：首字延迟高、token 成本高、格式解析需要容错。如果重做，我会考虑大小模型分工——小模型做路由与结构化，推理模型只做解读与生成。
• 加分点：主动说"当时内网可获得的权重有限"这个真实约束，比事后包装成完美决策可信。

3. 思维链和延迟

• 会问：思维链给不给用户看？延迟怎么控？
• 应答方向：不展示思维链（会误导、降低信任），只推阶段事件，思维链保留在日志用于排查；延迟靠"检索完成先推证据"、限制输出长度、热点缓存、字段型问题绕过大模型这四招。数值 <待核实>。

4. vLLM 与硬件细节答不全

• 会问：什么卡、多少显存、量化没有、并发多少、KV cache 怎么算、为什么不用 Ollama。
• 应答策略：坦白具体数值需要核实（部署由运维负责），但必须讲清参数关系——显存 = 权重 + KV cache，KV cache 随并发 × 上下文长度增长，所以 max_model_len / max_num_seqs / gpu_memory_utilization 要一起定；量化省显存但影响精度；Ollama 适合单机便捷推理，多用户服务化吞吐不如 vLLM。能讲清关系比记住数字更能证明你真做过。

5. 政务合规、内网隔离与信创

• 会问：数据怎么隔离？有没有等保要求？组件是否满足信创？日志里有没有个人信息？
• 应答方向：数据不出网是前提，模型与全部组件内网部署；权限过滤前置到检索；日志里对办事人身份信息脱敏。等保与信创清单由客户方 IT 提出，我的工作是在这些约束下做选型（比如倾向组件少、可离线部署、走已有 PG 运维体系）。不要冒充懂等保条款细节，说清"约束由谁给、我怎么落"即可。

6. 评测集只有百余条，够不够

• 质疑点：样本量小，准确率的置信区间宽；而且是自己出题自己判分。
• 应答方向：如实承认这是试点阶段的规模，作用是"防退步"而不是"证明达到多高水平"；结构上按三类场景分层、包含应拒答用例、正确答案由业务方确认。改进方向是把线上真实问题和被拒答/被人工纠正的样本持续回灌扩充。
• 别做的事：不要为了显得严谨而临时编一个更大的数字。

7. 准确率的判定标准会被抠

• 会问：办事指南"回答准确"是关键字段全对还是大意对？漏一项材料算不算错？谁判？
• 应答方向：给规则——关键字段（材料、时限、窗口、依据）逐项比对，漏项即错；表述差异不算错；判定由业务方确认的标准答案 + 脚本比对，主观项抽样人工复核。如果当时判定较粗，就承认并说明这会让数字偏乐观。

8. pgvector 的规模上限

• 会问：数据量涨上去 pgvector 撑得住吗？为什么不用专用向量库？
• 应答方向：讲选型依据（政务运维偏好组件少、走已有备份与运维体系、当时规模在可控范围）、讲观察指标（索引构建时间、召回延迟、召回率）、讲迁移触发条件（延迟或召回率退化到阈值就换 Milvus/Qdrant）。承认这是有规模上限的选择，不是最优解而是当时最合适的解。

9. 只做了五个月，深度够不够

• 应答方向：说清这五个月的交付边界——三类场景试点上线、入库与检索链路、规则解耦、评测集。不夸大成"完整生产级平台"。同时把它和亿达的两个项目连起来讲：政务这段让我把 RAG 的入库与检索做透，客服那段让我把 Agent 的工具安全与人工兜底做透，这两条正好是 Agent 开发岗要的两半。

附：面试前 5 分钟速记

• 一句话定位：内网可交付的政务 RAG，政策有版本有效力，答案必须指到条款。
• 三个必须答住的硬点：为什么双路召回 + 为什么 RRF、政策更新后怎么保证不答旧的、确定性规则为什么不交给模型。
• 一个必须提前背好的说法：企业应用开发岗位上怎么做起 AI 项目（第七节第 1 条）。
• 一个不要硬撑的地方：GPU 与 vLLM 参数讲关系、不编数值。