简历复盘记录

面试回答

我们这条链路里，文件上传之后还要解析、分块和向量化，处理耗时比较长，所以需要把上传接口和后台任务解耦。我选择 Kafka，主要看中它的分区日志、消息保留和消费位点，任务失败后可以重新消费消息，消费者组也便于扩展处理能力。

上传完成后，系统发布文档入库任务，消费者根据数据库里的阶段状态继续处理。Kafka 负责消息传递和重放，具体恢复到哪一个阶段仍由业务 checkpoint 决定。RabbitMQ 也能完成这种异步任务，它的队列和路由语义更直接；我们这套方案更侧重消息重放和消费进度管理，因此使用 Kafka，并在业务侧补齐幂等和失败恢复。

面试回答

整体分成创建会话、上传分片、合并确认和触发入库几个阶段。用户发起上传后，后端先校验文件和权限，再向 MinIO 创建 Multipart Upload，拿到 uploadId。客户端按分片序号上传，保存每片的 ETag，Redis Bitmap 用来快速记录哪些分片已经完成。

网络中断后沿用原来的上传会话，先与 MinIO 的实际分片列表核对，再补传缺失部分，避免只相信缓存进度。全部分片上传成功后，后端按序号和 ETag 请求合并，并确认目标对象可用。之后在数据库中更新文档状态、写入 Outbox 事件，再由发布器投递 Kafka。后台完成解析、分块和索引后，文档才会标记为可检索。

面试回答

我按消息可能重复到达来设计消费逻辑，先用文档版本和处理阶段组成稳定业务键。消费者拿到消息后，先检查数据库里的阶段状态，已经完成的直接跳过，处理到一半的根据持久化 checkpoint 从未完成的位置继续。

对于最终的索引写入，我给每个子块生成稳定的 chunk ID，使用 upsert，重复处理时更新同一条记录，避免新增重复索引。每个阶段都在产物和状态落库后再提交消费进度。这样即使处理成功后提交位点失败，消息再次到达，也可以根据已有状态安全跳过。Redis 可以辅助加速判断，但持久化状态才是恢复依据。

面试回答

消费失败后，我先判断错误能否通过重试恢复。模型超时、存储暂时不可用这类临时故障采用退避重试；文件格式错误、内容为空这类确定性问题，继续重试没有意义，就记录原因，停止自动重试并转人工或死信流程。

恢复依赖数据库里的阶段 checkpoint。解析、分块和向量化各阶段完成后，先保存产物和状态，再提交消费进度。Worker 重启或者消息重放时，先读取已完成阶段，从失败位置继续，避免每次重新处理整个文件。重复到达的消息仍然走同一套幂等逻辑，所以重试和恢复可以配合使用。

面试回答

这里涉及数据库和 Kafka 两个系统，我使用 Transactional Outbox 保证任务不会因为发送失败而丢失。MinIO 文件合并确认成功后，在同一个数据库事务里更新文档状态，同时写入一条待发布事件，事务提交后再由独立发布器发送 Kafka。

Kafka 暂时不可用时，事件仍然保留在数据库，发布器后续继续重试；收到 Kafka 确认后才标记已发布。如果发送成功但标记前进程崩溃，事件可能再次投递，这部分交给消费端幂等处理。这样通过持久化待发布事件解决漏投递，通过幂等解决可能的重复投递。

面试回答

我先区分分片不完整、合并明确失败和合并结果不确定几种情况。合并前校验分片序号和 ETag，并和 MinIO 的分片列表核对；如果缺片，就保留上传会话，让客户端补传后再合并。

如果调用合并接口超时，不能直接认为文件没有生成。我会先查询目标对象，核对文件是否已经完整可用；已经成功就推进后续入库，确实未成功且原上传会话仍有效时再重试。会话已经失效就重新创建上传。只有确认原文件可用后才触发入库，失败过程中保留状态和原因，便于续传或清理遗留分片。

面试回答

固定切块加 overlap 可以补偿切分边界附近的信息，但政策的适用范围和例外说明可能相隔比较远，只增加相邻重叠，不一定能把这些条件一起带回来。overlap 过大还会增加重复文本，让相似片段占用召回名额。

所以我采用父子分块，让较小、主题集中的子块负责精确召回和重排，命中后再按父子关系补回完整条款。这样既能定位用户问的具体条件，也能让模型看到同一条款的前置条件和例外。子块仍然可以保留适量 overlap，两种方法配合使用，只是补充上下文的范围更多依据文档结构来确定。

面试回答

我们优先按文档结构切分，再设置长度上限。父块尽量对应一个完整条款或章节中的独立主题，子块再沿段落、句子边界细分，保证检索时主题集中。调参参考范围是子块约 200 到 400 tokens，父块约 800 到 1500 tokens，具体仍要结合条款结构。

选择大小时，我同时看检索效果和回答完整性。子块太大可能混入无关主题，太小又可能失去必要指代；父块太大则会增加上下文成本。我们通过离线测评比较不同粒度下的召回、排序、适用条件覆盖以及 token 开销，再选择合适的切分配置。

面试回答

这套方案里，MySQL 保存文档版本、父子块正文和关联关系，子块上记录 parentId、章节路径和页码。用于检索的是子块，全文索引保存子块文本供 BM25 使用，Milvus 保存 BGE-M3 编码后的子块向量和必要过滤字段。

检索、融合和重排确定子块后，再根据文档版本和 parentId 从 MySQL 回查父块，补充完整上下文。父块读取走关联关系，不需要再做一遍父块向量检索。回查时还会核对当前版本和权限，避免索引更新滞后时，把已失效或无权访问的正文交给模型。

面试回答

我们先对子块重排，再回溯父块。子块内容比较集中，Reranker 更容易判断它是否直接回答问题，输入长度和计算成本也比较可控。等相关子块筛选出来后，再补回它所在的完整条款，供后续生成答案使用。

如果先扩展为父块，同一父块可能被多个候选重复带入，正文长度也会明显增加，反而容易把真正相关的内容截断。不过子块也不能完全失去上下文，所以切分时会保留标题、章节路径和必要指代信息，让重排模型能够理解这一段在讲什么。

面试回答

我先按文档版本和 parentId 聚合，同一个父块只放进上下文一次，同时保留命中的子块和位置。父块排序主要使用其中相关性最高的子块得分，不把所有子块分数简单相加，避免长章节因为子块多就天然排在前面。

如果同一父块的多个命中分别覆盖问题的不同条件，装配时会保留这些证据范围。重排后的十个子块也可能只对应两个父块，所以去重后还会检查证据是否过于集中，必要时从后续候选中补充不同父块，但仍然受相关性和上下文预算限制。

面试回答

父块过大时，我不会直接从开头截一段，而是围绕命中的子块补充所属条款，优先保留标题、适用条件和例外说明。同一父块中多个相邻或重叠的命中范围先合并，减少重复，不同父块再根据相关性分配 token 预算。

如果回答依赖的必要条件仍然装不下，就通过后续读取或补充检索分步查证，不能为了满足长度限制把关键条件删掉。证据仍不充分时，就缩小当前回答范围。这样控制的是上下文开销，同时保留足以支持结论的完整依据。

面试回答

我按解析后的条款和表格结构切分，页码主要用于引用定位。一个条款即使跨了两页，只要编号、标题和正文是连续的，仍然需要关联起来，同时保留每个片段的来源页码。

表格要保留表名、表头、单位和附注。表格过大需要拆开时，每组数据行都带上必要表头，否则一个金额数字脱离照护等级和每人每月的单位就没有完整含义。跨页表格还要检查列结构和表头是否一致，不能只因为位置相邻就合并。最终引用指向真正支持结论的页面，涉及多页时保留多页来源。

面试回答

我用控制变量的方式比较。固定同一批文档和版本、同一测评集，以及 embedding、检索和重排配置，主要改变分块与上下文补充方式。检索侧看 Recall@10、MRR@10，回答侧检查适用条件和例外是否遗漏、引用是否支持结论，同时记录上下文 token 数与耗时。

这里使用我们构建的 200 余道题测评集。因为不同分块方案的 chunk ID 会变化，标准证据标到原文条款或范围，再判断各方案有没有找到。简历里 0.71 到 0.89 的 Recall@10、0.62 到 0.78 的 MRR@10 是整套检索改进的结果，父子分块的贡献要看它自己的对照实验，不能直接用整体增幅代替。

面试回答

养老资料查询有两类表达需要同时照顾。一类包含明确的政策名称、条款编号或专业术语，BM25 的关键词匹配比较合适；另一类是用户用日常语言描述需求，和文档原文用词差异很大，需要 BGE-M3 的语义检索补充。

比如用户问“老人自己吃饭穿衣都困难，能申请什么帮助”，文档可能写的是生活自理能力、失能等级和照护补贴，纯关键词检索容易漏掉。反过来，纯向量检索也可能找到主题相近但条件不符的内容。所以我让两路并行召回，再用 RRF 融合和 Reranker 筛选，扩大证据覆盖后进一步判断相关性。

面试回答

BM25 是基于倒排索引的关键词相关性计算，主要看查询词出现的频率、词的区分度和文档长度。少见且准确命中的词通常更有价值，同一个词重复出现带来的加分会逐渐饱和，避免长文档单纯靠重复词占优势。

BGE-M3 在这里使用 dense 向量能力。入库时把子块编码成向量，查询时把用户问题用兼容的模型和编码方式生成向量，再交给 Milvus 查找相近结果。BM25 更直接利用词面匹配，BGE-M3 补充不同表达之间的语义关联，两路返回后按同一子块 ID 进行融合。

面试回答

BM25 分数和向量相似度的含义、数值范围都不同，直接相加会让数值范围更大的通道主导结果。我使用 RRF，把各路结果转换成排名贡献，再按稳定的子块 ID 合并，减少对原始分数尺度的依赖。

一个子块如果在两路里都排名靠前，就会得到两路加分；只被一路召回的候选也能保留。它的局限是看排名时会丢掉原始分数差距，无法区分第一名比第二名强很多还是只强一点。因此 RRF 用于融合候选，后面继续用 Reranker 联合读取问题和正文，做更细的相关性判断。

面试回答

RRF 依据候选在两路中的排名来融合，不能直接判断正文是否完整回答了问题。BGE Reranker 会把问题和候选子块作为一对输入，让模型联合读取，进一步判断它们的相关性。

比如两段内容都讨论补贴，语义上都接近，但用户问的是申请材料，Reranker 可以更细地判断哪一段真正列出了材料要求。因为这种联合评分成本较高，我们只对融合后的有限候选使用。地区、权限、时间和版本仍然由硬条件过滤处理，相关性分数再高也不能让不适用的资料进入回答。

面试回答

收到问题后，先确定用户可访问的知识库、地区和时间范围，把能够提前确定的过滤条件下推到两路检索。BM25 和 BGE-M3 并行召回子块，按子块 ID 对齐后做 RRF 融合，再交给 BGE Reranker 精排。

候选返回后，还会回查当前文档状态、版本和权限，防止索引更新滞后。确认可用后，按父块聚合、补充条款上下文，并按 token 预算装配证据，最终生成带 Evidence ID、文档和页码的回答。时间过滤根据用户问题确定，历史查询保留当时适用的版本，不能一律只取最新文件。

面试回答

我们的初始配置是 BM25 和向量检索各取 Top 50，按子块 ID 去重后最多得到 100 个候选，RRF 融合后取前 50 个交给 Reranker，再保留前 10 个子块。之后回溯父块、去重，并根据上下文预算决定真正装入多少证据。

前面保留较多候选，是给后续融合和精排留筛选空间。Top 20 可能过早漏掉正确证据，继续扩大又会增加重排耗时，所以比较 20、50、100 等配置下的候选覆盖率、最终 Recall@10、MRR@10 和延迟。最终保留 10 个子块也是效果与成本的配置选择，父块去重后数量可能更少，并不等于给模型塞 10 个父块。

面试回答

我主要调平滑常数 k 和两路权重，初始采用 k 等于 60、BM25 与向量权重 1 比 1。先固定召回和重排配置，比较 k 为 20、60、100 时的效果；k 小时更强调头部名次，k 大时头部与后部排名贡献的差距会缩小。

然后根据错误分析调整权重。精确名称、编号类问题不足时，比较偏向 BM25 的配置；口语化问题漏召回较多时，比较偏向向量检索的配置。每次少量改变参数，同时看重排前的证据覆盖和重排后的 Recall@10、MRR@10，避免只看最终排序，忽略候选池已经发生的变化。

面试回答

Reranker 的输入包含问题、文档标题、章节路径和子块正文。我用对应模型的 tokenizer 计算总长度，先给问题和标题预留空间，再分配正文预算。因为重排对象是子块，大部分输入本身较短，通常不需要直接处理整个父块。

遇到超长表格或片段时，按段落、句子或表格结构拆成多个窗口，每个窗口保留必要标题、表头，分别评分，再用最高分代表该候选的相关性。这样避免统一截取开头，把后面的关键条款删掉。原文和页码映射始终保留，后续生成时仍按需要读取原始证据。

面试回答

两路检索设置独立超时，某一路失败时尽量保留另一路的有效结果。BM25 不可用就使用向量候选，向量编码或 Milvus 不可用就使用 BM25 候选；如果 Reranker 失败，就用 RRF 排序结果兜底，并记录实际走了哪条链路。

降级后仍要检查证据是否足够，必要时补查、澄清或说明缺少依据。正常检索无命中和通道故障分开处理，前者可以改写查询，后者做有限重试和降级。权限、版本校验属于证据放行条件，这些检查不可用时不能跳过，否则可用性恢复了，访问范围和答案适用性却失去保证。

面试回答

我们围绕养老政策、机构制度和服务资料构建了 200 余道题，覆盖精确条款查询、口语化表达、多条件查询、时间版本和政策对比，也加入无答案、条件不足的题目。每道题记录问题、参考答案、文档版本、原文证据位置，以及回答必须覆盖的条件。

标注时区分“主题相关”和“足以回答”，不能把所有提到补贴的片段都算正确证据。检索评测检查原文依据有没有被召回，回答评测再看条件和引用是否完整。调参题和最终评测题分开，近似改写放在同一组，避免泄漏；无答案题单独检查证据不足与澄清行为，不混进普通 Recall 的分母。

面试回答

我把整体效果比较和组件对照分开。整体比较对应原始系统与最终系统，简历里的 Recall@10 从 0.71 到 0.89、MRR@10 从 0.62 到 0.78，反映的是整套改进的收益。

为了判断各环节的作用，另外固定文档、父子分块、过滤规则和测评集，比较 BGE-M3 单路、BM25 单路、两路加 RRF，以及在混合检索上增加 Reranker。这样能分别观察单路特点、混合召回和精排的贡献。分块方式再单独做实验，每次保存模型版本、召回数量、RRF 参数和重排配置，避免同时改动多个环节后无法解释效果来源。

面试回答

ReAct 是让模型判断和工具调用交替进行的一种 Agent 执行方式。在我们的养老知识问答里，模型会根据当前问题和已经拿到的证据，决定下一步调用哪个工具；工具返回结果后，再判断是否需要继续检索，还是已经可以回答。

比如用户询问能否申请护理补贴，Agent 会先检查地区、照护等级这些必要条件是否齐全，缺少时向用户澄清。查到政策后，如果申请条件还引用了另一份认定办法，就继续检索对应资料，补齐回答依据。

模型负责提出工具调用和参数，后端负责参数、权限及时间范围校验。同时设置调用次数和超时上限，结束前检查证据与引用是否齐全，避免反复检索或依据不足就给出结论。

面试回答

ReAct 适合根据当前结果决定下一步，但政策变化分析通常包含多个版本和比较维度，如果一直局部补查，容易漏掉子问题，或者反复搜索同一部分。所以我们在复杂任务中引入 Plan-and-Execute，先拆解目标，再按步骤执行和检查完成情况。

比如比较政策调整前后的申请条件、补贴标准和材料要求，要先确认地区和时间，找到两个适用版本，再分别提取这些维度，最后核对差异和引用。计划会记录哪些步骤已完成、缺什么证据。如果执行中发现文件被替代或附件缺失，可以调整计划；某一步需要动态补查时，内部仍然使用 ReAct。

面试回答

我主要根据对象数量、时间版本、输出维度和步骤依赖判断。查询一个明确条款时，直接检索就可以；需要根据工具结果继续查附件或补条件时，使用有执行上限的 ReAct 循环。

如果任务同时比较多个版本或机构制度，还要求从多个维度给出结论，就先用 Plan-and-Execute 管理整个任务，避免漏项。计划中的某一步仍然可以用 ReAct，比如查旧版申请条件时，先查正文，再根据引用补查认定办法。简单任务不额外生成计划，减少不必要的耗时和模型调用，判断依据也不能只是问题字数。

面试回答

我按明确的业务能力定义工具，比如知识检索、读取证据原文和查询文档版本。每个工具都提供名称、适用场景、输入 Schema 和结构化返回值，让模型知道什么时候调用、参数怎么填、结果代表什么。

以知识检索为例，输入包含查询文本、文档类型、时间条件和返回数量，成功时返回片段、Evidence ID、文档版本和页码；失败时返回错误类型和是否可重试。用户身份和可访问范围由后端认证上下文确定，模型填写参数不能扩大权限。结果正文也控制长度，先返回必要片段，需要完整条款时再调用原文读取工具。

面试回答

后端会把当前任务允许使用的工具说明和参数 Schema 提供给模型。模型结合用户目标、当前步骤和已有结果，生成结构化的工具名和参数；后端根据工具名找到处理器，完成类型、范围与权限校验后执行，再把结果交回模型。

工具说明要写清能力边界，比如找资料用检索工具，已经拿到 Evidence ID 但需要完整条款时用原文读取工具，确认某个时间点适用哪个文件时用版本查询工具。模型提出的调用不会直接执行，未知工具、错误参数或越界数量会被拒绝并返回具体错误，允许模型在合法范围内修正。

面试回答

我们把计划作为结构化任务保存在 MySQL，包含目标、地区和时间等约束、计划版本、步骤列表及依赖。每个步骤记录自己的状态、完成条件、工具执行记录和 Evidence ID，根任务还保存已用步数、调用次数和截止时间。

这样恢复时能够明确知道哪些已经完成、下一步的依赖是否满足，而不必让模型重新解释一段自然语言计划。比较长的工具结果单独存，计划通过记录 ID 关联。需要重规划时保留旧计划和执行记录，生成新版本，已经拿到的证据经适用性检查后继续复用，避免整个任务从头再来。

面试回答

我把完成判断和用户要求关联起来，检查输出维度是否覆盖、证据是否适用、引用是否齐全，以及还有没有未解决项。比如政策对比要找到两个正确版本，申请条件、标准和材料都完成比较，每个差异都有对应原文，才能认为主要目标完成。

工具返回成功只说明这一次调用正常，不能直接当成任务完成。我们同时设置步数、调用次数和总超时上限。如果到上限仍缺资料，就保留已经确认的部分，明确说明缺哪项证据或条件。这样既有内容上的完成条件，也有执行预算，避免无限检索。

面试回答

暂停时保存任务、步骤状态、checkpoint、已有证据和累计预算，并停止发起新调用。恢复时先加载这些记录，重新检查当前权限、文档版本和证据适用性，再从未完成的位置继续，不重复执行已确认完成的部分。

正在进行的外部调用是否能取消，要看工具支持情况，不能认为点击暂停就已经停止。对于已发出但结果不确定的调用，恢复时先核对调用记录或查询结果。步数、重规划次数、模型和工具调用次数以及总时间都按同一个任务累计，重试和恢复也计入，避免每次恢复重新获得完整额度。

面试回答

我根据错误类型决定后续动作。参数错误就返回具体字段问题，让模型修正；超时和连接异常在剩余预算内有限重试；单路检索不可用时，使用其他可用通道。权限不足则停止这次访问，不能靠修改参数绕过。

工具正常执行但没有结果，要考虑改写查询、补条件或说明未找到，不能当作服务故障盲目重试。一次失败也不一定让整个任务重来，比如正文已经取得但附件获取失败，会保留正文证据，只继续处理附件缺口。必要依据始终拿不到时，返回已确认部分，并说明哪些结论暂时无法给出。

面试回答

我会记录每次查询的文本、时间与知识库等过滤范围，以及返回的 Evidence ID。再次调用前，先检查相同请求是否已有可复用结果，权限和版本仍适用时直接复用。

另外还要看检索有没有推进任务。模型即使换了措辞，如果一直返回同一批证据，也没有覆盖新的问题维度，就需要调整检索方向。比如补贴标准已经查到，缺少申请材料，下一次就查材料或附件，不再宽泛地搜索补贴政策。判断重复也不能只看文本，同一句问题查询不同地区、时间或版本，范围不同，仍然属于不同请求。

面试回答

我把当前问题、用户刚补充的条件、任务约束和当前步骤放在优先位置，再装配相关证据、近期消息和历史摘要。近期对话用滑动窗口保留，较早内容压缩为摘要；计划、步骤状态和证据记录单独跟踪，不完全依赖聊天历史。

检索结果先去重并提取相关片段，长工具结果移出上下文后保留记录 ID，需要时再读。计算预算时把工具 Schema、消息结构和引用信息也算进去，并给模型输出预留空间。裁剪不能丢掉条款的必要条件或工具调用与返回的对应关系，摘要里的政策描述也不能直接代替当前适用的原文证据。

面试回答

我们把地区、时间、对象和输出要求单独保存成结构化任务约束，每次装配上下文都明确提供给模型。摘要主要压缩对话背景，关键条件不依赖摘要模型自行记住，所以长对话压缩后仍能按同样范围检索和回答。

用户修改条件时，更新对应字段，后续查询使用新值；没有提供的信息继续保持缺失，不能让摘要自动补齐。摘要里还区分用户明确提供、工具已确认和尚未确认的内容，对重要事实保留来源消息或证据记录。发生不一致时，回到明确的用户要求和原始记录核对，避免错误摘要被不断沿用。

面试回答

政策变化分析要先确定比较的是哪个地区、哪项政策、哪个调整时间，再找到调整前后各自适用的文件。之后按照用户关心的维度提取条款，比如申请条件、补贴标准和申请材料，对齐后说明哪些新增、修改或保持不变。

每一项变化都要关联新旧证据，正文之外还检查附件和补充通知。Agent 负责组织这些查询和比较步骤，生成前再检查维度是否齐全、版本是否适用。不能只查到新文件就凭模型记忆描述旧规定，也不能把不同时间的条款拼成同一套当前政策。

面试回答

用户用语和政策原文经常不一致，而且回答依据可能分散在正文、附件和补充通知里。所以第一步把用户表达转成明确的检索目标，同时保留地区、时间、政策项目等约束，缺条件就先澄清。

比如“补贴变了多少”，需要明确比较金额、覆盖对象还是发放方式。第一轮查到正文后，如果材料要求写着详见附件，就继续读附件；金额规定引用补充通知，就针对那份通知补查。每一轮围绕具体证据缺口展开，避免不断搜索同一个宽泛问题，也不能为了扩大召回把地区和时间条件丢掉。

面试回答

入库时我们分别记录发布时间、生效时间、失效时间，以及修订、补充、替代和废止关系。查询时先判断用户问当前政策、历史某个时间点，还是新旧对比，再按地区和适用时间选择对应证据。

比如文件六月发布、七月生效，用户问六月的申请规则，就不能直接采用新规定。历史查询也要允许读取当时有效、现在已失效的政策。另外，政策版本和索引构建版本分开管理，重新解析、分块或编码只是技术处理变化，不代表政策发生修订；刚入库的文件也不能直接认定为最新政策。

面试回答

我按同一个比较维度对齐新旧条款，分别判断新增、删除、修改或未变化，保留对象范围、单位和例外条件。比如一个版本按每人每月补贴，另一个按服务次数结算，不能直接把两个数字相减，就认定补贴提高或降低。

遇到看起来冲突的文件，先核对地区、适用对象和时间，再检查明确的修订、替代或废止关系，以及正文和附件、一般规定和特殊情形的区别。发布日期更晚不能自动说明覆盖旧文件。关系仍无法确认时，保留两侧原文并说明冲突；新版没检索到某项要求，也会检查附件和关联文件，再判断是否真的取消。

面试回答

检索完成后，我把可用结果整理成结构化证据记录，每条分配 Evidence ID，关联文档及版本、父子块、原文片段、页码和适用时间。模型只引用本次提供的已有 ID，最终由后端映射成文档和页码，方便用户回到原文核对。

引用还要和具体结论对应。比如回答申请材料新增了某项证明，需要同时给出旧版清单和新版要求。生成后，后端检查引用 ID 是否存在、是否属于本次可用证据、当前是否仍可访问，还要核对原文是否支持这句话。只有 ID 正确但内容不支持结论，仍然不能算有效引用。

面试回答

我先判断缺的是用户条件还是文档依据。地区、时间或对象不明确时，向用户澄清；正文指向的附件、通知还没取得时，继续针对缺口检索。已经确认的部分可以正常回答，尚缺依据的部分单独说明。

如果达到执行预算仍未查齐，就明确告诉用户当前哪些结论有依据、哪些暂时无法判断，以及还缺什么材料。没有检索到某条规定，只能说明当前证据不足，不能直接说这项规定不存在，也不能让模型用常识补成确定的政策结论。这样回答能够保留已有价值，又让用户知道依据覆盖到了哪里。

面试回答

我围绕农机运营流程划分资产、作业、维保、成本和经营分析模块。资产模块维护机型与具体设备，作业模块管理任务和资源安排，维保模块处理维修保养流转，成本模块管理单据与审核，经营分析按统一时间和组织口径汇总数据。

接口层由 Controller 接收请求，Service 组织业务和校验，MyBatis 完成持久化。跨模块通过公开 Service 协作，比如调度时检查设备状态、已有任务和维保占用，不直接改其他模块的表。这样普通接口和 Agent 都能复用同一套权限、状态流转和资源规则，模型提出方案后仍由后端判断能否执行。

面试回答

我们以组织作为租户，采用单数据库共享业务表，通过组织字段和应用层授权隔离数据。每个组织有自己的成员、设备、作业、维保和成本记录，用户在当前有效组织内查询和操作，知道其他组织的资源 ID 也不能访问。

同时区分平台公共资料和组织私有数据。标准机型、公共知识按规则共享，组织资产和私有知识只在授权范围内开放。服务端会核对当前成员关系与数据范围，不能直接相信请求里填写的组织 ID。平台管理员承担平台治理，也不会因为拥有平台角色就自动获得所有组织的业务明细。

面试回答

JWT 用来携带可验证的登录身份，Spring Security 校验签名和有效期、建立认证上下文并控制请求入口。进入业务层后，还要检查账号和当前组织成员关系、角色操作权限、资源数据范围以及业务状态。

所以令牌有效只能证明登录凭据仍有效，不能代表用户当前仍有全部业务权限。比如用户登录后被移出组织，后续操作会按当前成员关系拒绝；用户在请求中切换组织，也要由服务端重新确认成员资格。查询和写入最终都基于经过验证的上下文限定范围，避免只在登录时检查一次权限。

面试回答

角色权限决定用户能进行哪类操作，数据范围决定这次操作能作用于哪些记录。比如农机手具备执行任务的权限，但只能处理分配给自己的任务；维保员可以处理工单，也只能访问授权范围内的工单。

之后还要检查业务状态。即使用户有权限、资源也属于本组织，已经结束且不允许修改的工单仍然不能更新。因此一次操作要同时满足身份与成员关系有效、具有操作权限、记录处于数据范围内、当前状态允许，不能只凭一个角色名称就放行。

面试回答

资源状态校验放在业务 Service 中，与权限检查分别执行。比如修改维保工单，先确认用户有权操作且工单在授权范围内，再判断它当前是否处于允许修改的状态，已经结束的工单不能因为用户有权限就继续改。

对于检查后可能发生并发变化的操作，实际更新时还会带上预期状态，并检查影响行数。如果其他请求已经推进状态，当前更新就不能继续当作成功，需要返回状态已变化的结果。这样避免只在写入前查一次状态，随后被其他请求修改，却仍然按旧判断执行。

面试回答

我把服务端验证过的组织和数据范围带进实际查询与更新条件。查详情时同时限定资源 ID、组织和有效状态，必要时再限定任务分配或成员范围；写入时同样带组织范围和所需的预期状态，并检查影响行数，避免查询有校验、更新却只按主键。

这套限制也覆盖导出、附件下载、统计和批量操作，不能只保护列表接口。批量请求逐项确认资源是否属于当前范围，请求里填写其他组织 ID 不能扩大权限。Agent 和异步任务调用业务 Service 时也复用这些规则，确保入口变了，资源边界仍然一致。

面试回答

创建任务时会保存发起人、组织和资源标识。HTTP 请求结束后，原线程的登录上下文不能长期代表后台执行权限，所以 Worker 真正执行时会重新加载有效身份与成员关系，建立本次执行上下文，再调用业务 Service。

Agent 也是模型先提出工具和参数，工具执行器校验用户范围，Service 再检查权限和业务状态。任务创建后如果用户被撤权、成员停用，或者设备状态发生变化，就按执行时的当前事实处理。人工确认只表示接受某份方案，不能替代权限校验，模型填写其他组织 ID 也不能越权。

面试回答

主要是减少几类重复开销。机型资料和部分统计结果会被反复查询，直接回源会重复执行 SQL 和聚合；知识检索中，同一个问题反复生成查询向量也会增加模型调用；多轮问答还需要频繁加载近期消息。

因此我用 Redis 缓存业务读结果、查询向量以及近期对话和常用偏好，让重复请求尽量复用已有结果。MySQL 仍保存业务记录、消息和来源，Redis 中的数据可以回源重建。真正调度、审批或者修改资源时，仍然查询当前业务事实并校验，避免把缓存中的旧状态直接当作执行依据。

面试回答

我把缓存分为三类。业务读缓存保存机型资料、部分查询和经营统计，减少重复 SQL；查询向量缓存保存问题的 embedding，避免重复编码；近期对话缓存保存组织、用户和会话范围内的近期消息，加快上下文装配。

缓存内容需要能够从持久化记录或模型计算重建。资产现在能否调度、任务有没有冲突、工单是否允许提交，这些在实际执行前仍然按当前事实检查。查询向量命中也只省掉编码步骤，后续知识检索依然要带当前权限、时间和版本条件，不能把向量缓存当成可直接复用的答案。

面试回答

读取时先查 Redis，命中就使用缓存结果，未命中则查 MySQL，再回填并设置 TTL。修改时先提交数据库事务，再删除受影响的缓存，由下一次读取重建。

选择删除而不逐一更新，是因为一次业务修改可能同时影响详情、列表和多个统计结果，全部重新计算容易复杂且遗漏。比如成本单据审核后，要让相关展示和统计失效。删除放在事务提交后，避免其他请求在新事务尚未提交时就查到旧值并重新缓存。并发回填和删除失败仍需单独处理，这个顺序本身不能保证强一致。

面试回答

Key 要包含所有会影响结果的范围和查询参数。业务详情通常包含组织、资源类型和资源 ID；统计还要加有效数据范围、时间区间和条件；对话按组织、用户和会话隔离；查询向量则按模型版本、编码配置和查询文本区分。

同一个组织里，不同成员能看到的记录可能不同，所以只加组织 ID 还不够，涉及数据范围的结果要继续区分。命中缓存也不能跳过必要的访问校验。查询向量只是文本编码，可以在编码兼容时复用，但真正检索时仍然应用当前用户的知识库、权限、时间和版本条件。

面试回答

查询向量必须和文档索引处在兼容的向量空间。模型版本、维度或预处理方式变化后，即使查询文本一样，生成的向量也可能不兼容，所以 Key 中要包含模型和编码配置，升级时使用新的缓存命名空间。

文本规范化只处理无意义差异，比如首尾空白，不能把地区、日期、机型编号删掉，否则不同问题可能共用同一个向量。缓存的是问题编码，文档内容更新后，如果编码配置没变，查询向量仍可使用，再对当前索引执行检索；旧模型向量则不能直接与新索引混用。

面试回答

TTL 根据数据变化频率、回源成本和能接受的陈旧时间分别设置。相对稳定的机型资料可以长一些，频繁变化的业务查询和统计短一些，并配合写入后的主动失效。查询向量在模型不变时比较稳定，过期主要用于控制容量和淘汰旧问题。

近期对话同时限制会话过期时间和消息数量，避免无限增长。大量同类缓存再给基础 TTL 增加少量随机偏移，减少同时失效造成的回源高峰。TTL 只是限制旧值可能保留的时间，在有效期内也可能已经过时，所以执行操作前仍然检查当前业务事实。

面试回答

我们采用先提交数据库修改、再删除相关缓存，下一次读取回源重建。对普通展示数据，接受短时间最终一致，通过主动失效和 TTL 限制陈旧窗口；删除失败会记录并补偿，不能只打日志就结束。

这个方案仍然存在并发窗口，比如请求 A 查到旧值，请求 B 更新数据库并删除缓存，之后 A 才把旧值回填。TTL 能限制它存在多久，但不能消除这个窗口。因此调度、审批和权限判断在执行时重新查询当前事实，不直接根据展示缓存决定是否写入。我会把展示一致性的要求和业务执行的正确性分别处理。

面试回答

Redis 不可用时按缓存类型回源。业务读结果回 MySQL，查询向量重新调用编码服务，近期消息从 MySQL 按需要加载。同时限制超时和并发，避免缓存故障把所有压力直接转移到数据库或模型服务。

热点 Key 失效时，会合并同一个 Key 的重建请求，让一个请求加载，其他请求等待或受控回源，减少相同 SQL 和编码任务同时执行。这只是缓存重建保护，不能替代业务事务或状态锁。监控时也区分正常未命中和缓存服务故障，分别看命中率、回源耗时和错误数量。

面试回答

我会固定数据规模、请求分布和并发条件，对比启用缓存前后的完整请求。业务查询看缓存命中率、数据库查询次数，以及平均耗时和 P95；查询向量缓存再看实际 embedding 调用次数；同时检查数据更新后多久能在查询结果中看到。

实验还要区分未预热和已预热，避免把一次理想命中当成全部请求表现。只有重复 SQL 或编码次数下降、用户等待改善，并且结果陈旧时间在可接受范围内，才能说明缓存起到了作用。单看 Redis 读取很快，无法证明整个业务接口变快，更不能说明数据更新仍然正确。

面试回答

这条工作流从理解用户目标开始，先补齐必要条件，再通过业务工具查询当前数据、通过知识工具取得专业资料，生成可检查的草案。后端先校验权限、资源和业务约束，把草案及依据展示给用户，人工确认后才进入实际执行。

比如用户要求安排下周作业并避开维修设备，Agent 先查询任务要求、设备、人员和已有安排，再准备调度方案。确认期间资源可能变化，所以执行前还会复核当前状态和冲突，通过业务 Service 写入，并记录结果与审计。模型负责理解和组织步骤，设备能否调度、用户是否有权操作由后端确定。

面试回答

我按需要取得的信息选择工具。作业调度查询任务、设备、人员和已有安排；维保建议结合设备档案、维修记录与手册检索；经营分析从业务记录中取得指标；知识问答则检索说明书、规范和资料页，保留引用。

动态状态通过业务工具查询，维修方法这类专业知识通过检索取得，不能把历史对话里的设备状态当成当前事实。金额、工时等指标由确定性的业务查询和计算产生，模型负责组织方案或解释结果，避免它根据零散记录自行估算。各场景最终返回草案、指标或带证据的答案，写操作再经过确认和业务校验。

面试回答

我把查询资产、查询任务、检查冲突、检索维修资料和准备调度草案等能力封装成工具，明确名称、说明、参数 Schema、读写属性、返回结构和幂等要求。执行器统一处理参数、权限、超时和预算，实际业务仍调用已有 Service。

这样可以复用普通接口的组织范围、状态流转和审计规则。比如创建维保工单，需要校验资产、用户权限和必填信息，不能让模型拼一条 SQL 就插入表。模型提出工具和参数，后端决定是否合法并执行；写操作还要关联用户确认和稳定执行标识，避免一次重试产生多条业务记录。

面试回答

后端根据草案中的设备、执行人和时间范围做确定性检查。先确认资源存在且在授权范围内，再看设备当前状态、维保占用、已有任务，以及人员和设备在相关时段是否冲突，同时核对作业要求和候选资源是否匹配。

失败时返回具体资源、冲突记录和原因，Agent 据此换设备、调时间或请求补齐条件。用户确认期间其他请求可能改变安排，所以真正写入前还要再次复核，并在业务写入环节控制并发，避免两个请求都查到空闲后同时占用。模型生成方案本身不能代表资源已经被预留。

面试回答

用户确认的是一份内容确定的草案，里面明确设备、操作、时间和关键参数。后端把真实确认动作关联到具体草案版本，执行也使用这个版本；设备、时间或其他关键参数改动后，要重新展示并确认，不能沿用旧确认执行新方案。

确认表示用户接受这份安排，权限和审批仍按业务规则检查。执行时会重新核对成员关系、资源状态和任务冲突，模型生成一句“用户已同意”不能替代确认记录。这样既知道用户同意了什么，也能保证实际执行内容与确认内容一致。

面试回答

每个业务动作都有稳定执行标识和执行记录。重复请求先查记录，已经成功的返回已有业务结果，避免再次创建。一个批量方案有部分成功、部分冲突时，逐项保存回执，只处理未完成或需要修正的项，不能整体重放。

写操作超时尤其要先核对执行记录和实际业务状态，因为可能已经写入，只是响应没回来。确认未执行后才考虑重试，重试时继续检查权限、草案版本和确认状态。只读查询可以在预算内有限重试；明确失败的写操作返回具体原因，必要时调整草案并重新确认。

面试回答

审计要能够还原谁提出了什么目标、确认了哪份草案、调用过哪些工具，以及最终影响了哪些业务记录。因此会记录发起人、组织、任务和草案版本，关键参数与用户确认，工具调用时间、状态、错误、证据和执行回执。

我会区分建议、待确认草案和已执行结果。比如草案生成成功，只说明模型已经提出方案，不能记成调度成功；最终还要关联创建或修改的业务记录 ID，说明哪些动作完成、哪些失败。界面和日志采用同样的状态区分，方便定位失败、处理重复请求和回溯实际变更。

面试回答

短期记忆服务于当前对话，比如保留刚确认的设备和时间，理解下一句里的“它”或“改到明天”。长期记忆保存跨会话可复用的背景、重要事件和明确偏好。实体记忆则把用户提到的机器、机型或工单关联到稳定业务对象，解决到底说的是谁。

例如先查资产 A 的维保记录，再问它为什么停机，近期对话帮助确定指代；过一段时间问上次那台收割机的维修进展，长期记忆找回讨论背景，实体关联定位资产，再用业务工具查当前进展。这些是用途上的区分，可以重叠，也不分别对应某一种数据库。

面试回答

MySQL 保存完整消息、历史事件、记忆记录、实体关联和来源，是可以回查的持久化记录。Redis 缓存近期对话与常用偏好，设置 TTL 和容量上限，加快上下文加载。Qdrant 保存记忆文本向量和过滤字段，用语义检索找出跨会话可能相关的历史信息。

召回后还会回查 MySQL，检查记录是否有效、来源是否可访问。Redis 过期只意味着缓存需要重建，Qdrant 向量丢失也可以从有效记录重新编码。记忆用的是文本 embedding，知识库文档页用 ColQwen 视觉多向量，两者的用途和向量空间不同，不能直接混在一起检索。

面试回答

短期记忆用滑动窗口保留最近的有效消息，较早内容压缩成历史摘要。窗口里优先保留用户刚修改的时间、设备编号和当前任务条件，裁剪按 token 预算做，避免只按消息条数限制，遇到单条很长的工具结果就失控。

长结果只提取相关内容，工具调用与返回保持对应。计划、草案、用户确认和执行结果单独持久化，恢复任务时读取这些结构化记录，不能只靠聊天摘要猜做到哪一步。这样近期对话负责理解追问，任务状态负责保证执行连续性，二者配合控制上下文长度。

面试回答

长期记忆从历史消息和事件中整理可复用的信息，比如用户明确表达的展示偏好、历史任务背景、讨论过的设备和故障。每条保留来源、时间和组织用户范围，持久化后再为有效内容建立向量索引，便于后续语义召回。

记录时区分建议和事实。Agent 提议下周保养，不能记成保养已经安排，只有实际执行成功后才能关联对应业务记录。设备当时维修可以保留为历史背景，但下次调度还要查当前状态。长期保存的价值在于减少用户重复交代背景，同时让信息有来源可核对。

面试回答

实体关联用稳定业务 ID 保存，名称、别名、机型和来源消息辅助匹配。用户说“那台收割机”时，最终要关联到具体 assetId，不能只记住机型，因为同一机型可能对应多台资产，一台资产又可能有多张工单。

召回候选后再通过业务查询确认对象和当前访问权。多个设备都符合描述时，让用户选择或补充信息，不直接取第一条。关联完成后，记忆帮助后续指代定位，但不会授予权限，也不能把工单 ID、机型 ID 和资产 ID 混为同一个对象。

面试回答

先根据当前问题和明确实体确定检索范围，按组织、用户和有效状态过滤，再从 Qdrant 召回相关历史信息。之后回查 MySQL 里的记录与来源权限，去重并检查时间和冲突，挑选有用片段放入上下文。

相似度高只说明可能相关，旧偏好已被修改、来源已撤权或记录失效时都不能继续使用。装配时优先保留当前问题、明确约束和当前任务证据，长期记忆控制在预算内，不能挤掉关键资料。偏好可以影响答案展示方式，但不能改变权限、审批规则或者确定性计算出来的指标。

面试回答

先区分信息类型。用户明确修改长期偏好时，更新可定位的偏好记录，保留版本和来源，用新值替代旧值，并同步 Redis 缓存和 Qdrant 投影。只针对当前任务的指令，就只影响这次，不自动覆盖长期设置。

比如默认展示未来两周维保，用户说“这次只看本周”，长期默认值不变。历史事件则按时间分别保存，设备发生第二次故障不能抹掉第一次；动态业务状态只作为当时背景，现在的状态重新查询。这样冲突处理依据来源、时间和作用范围，不能让所有相似记忆简单互相覆盖。

面试回答

记忆的缓存和向量过滤都带组织、用户及相应会话范围，召回后还会回查当前记录和来源权限。用户过去能读某段会话，不代表现在仍有权使用它的派生内容；来源已经不可读时，相关记忆也不能继续注入上下文。

删除或修改以 MySQL 有效记录为准，再同步清理缓存和向量投影。向量异步更新期间，回查可以阻止旧投影生效。用户明确要求遗忘时，还要保留对应遗忘控制，防止下一轮整理旧消息又抽取出同一条信息，仅删除当前一条向量无法完成这种持续遗忘。

面试回答

我会对同一批历史任务，比较启用长期召回和只用近期对话的表现。先看是否找到了相关背景、是否定位到正确设备或工单，用户是否少重复说明信息，再看跨会话任务能不能正确完成。

同时检查过时和冲突信息有没有被错误注入，尤其不能让历史设备状态干扰当前调度，或者绕过权限检查。最后记录额外的上下文 token 和耗时，判断收益是否值得。如果只是召回更多历史文本，却没有改善对象定位和任务完成，甚至带来旧信息干扰，就不能认为记忆有效。

面试回答

上传后先把 PDF 原文件存到 OSS，在 MySQL 创建文档版本和处理任务，再通过 RabbitMQ 交给后台 Worker。后台按页渲染图片、提取原生文本，扫描页或解析质量不足的页面用 MinerU 补充 OCR 和结构化解析，再用 ColQwen 编码页面，把多向量和过滤元数据写入 Qdrant。

处理完成后会校验页面、文本和索引产物，确认完整才把该版本标记为可检索。OSS 保留原文件与页面图片，MySQL 保存版本、页面关系和任务状态，Qdrant 是可重建的检索索引。各阶段持久化进度，失败从对应阶段或页面恢复，稳定标识保证重复执行更新同一份产物，避免重复建页和索引。

面试回答

文档页面渲染、OCR 和模型编码耗时长，大文件、扫描件的资源消耗差异也很大。如果都放在上传接口里，会长时间占用请求线程，用户也不容易区分上传失败还是后台解析失败。所以接口上传后返回任务标识，后台按资源能力处理，用户查询进度。

这里采用 RabbitMQ，主要因为它的任务队列、消费确认和路由机制适合平台当前的任务分发需求，也与已有技术栈匹配。MySQL 保存任务状态，消息触发执行，产物和状态持久化后再确认消息。临时故障有限重试，损坏文件等确定性错误记录原因并终止无效重试。Kafka 也能承担异步处理，具体取舍要结合平台需求。

面试回答

PDF 提取到字符不代表内容已经可用于问答。有些是扫描页，根本没有原生文本；有些多栏页面会出现阅读顺序错乱；表格只剩连续文字后，行列、单位和附注关系也容易丢失。

所以我们先提取原生文本，再按页面质量决定是否使用 MinerU 补充 OCR 和结构化解析，重点检查空文本、明显乱码和缺失页面。页面图片始终保留，因为 OCR 提供可读文字，但结构图、操作示意和位置关系仍需要视觉信息。这样把文字解析和页面证据配合起来，避免仅凭一份质量不足的提取文本生成答案。

面试回答

ColQwen 是面向文档页面的多模态检索模型，可以把页面图片编码成多个向量，再与查询做细粒度匹配。农机资料中有大量表格、结构图和操作示意，纯文本提取可能丢掉布局或部件位置关系，页面检索能利用这些局部视觉信息查找相关页。

比如查询液压回路中某个阀的位置，只有部件名称的文本未必能还原它与管路的关系。我们用页面多向量定位证据，再读取对应文字、数值和图例核对。它的代价是页面编码、向量存储和匹配成本更高，因此要同时评估检索效果与资源开销；找到相关页也不等于结论已经正确。

面试回答

查询和文档页面都编码成多向量，通过 MaxSim 后期交互计算相关性。可以理解成查询的每个向量去页面向量中找最相似的一项，再汇总这些最大相似度，这样保留问题不同部分与页面局部内容的匹配关系，不必先把整页压成单个向量。

Qdrant 保存页面多向量，以及文档、版本、页码和组织等过滤元数据。原文件与页面图片仍在 OSS，文档和页面业务关系在 MySQL，召回后要回查原始证据。查询与页面编码保持模型和配置兼容，升级导致向量空间变化时要重建相应索引，不能把不同模型的向量直接混用。

面试回答

视觉检索主要负责定位相关页面，原生文本或 OCR 提供模型可读取的文字、表格与注释。比如用户查故障码，先找到故障码表所在页，再读对应行、列标题和适用条件，不能只命中这一页就直接生成结论。

生成模型支持图像时，可以提供页面图片和相关文本；只支持文本时，就提供原生文本、OCR 或结构化解析结果。页面检索向量只用于匹配，不能当作原文证据输入。视觉与文字结果通过稳定的文档版本和页面标识关联，如果两路同时召回，先对齐去重再融合，避免直接相加尺度不同的原始分数。

面试回答

召回前用 Qdrant 元数据按访问范围过滤，缩小候选集合；候选返回后再回查 MySQL 中当前权限、文档状态和版本，防止索引滞后时继续使用已撤权、已删除或不适用的资料。通过检查的页面才能进入生成上下文。

引用绑定具体文档版本和页面标识，并区分 PDF 的物理页序和文档印刷页码，确保用户能定位同一份文件里的同一页。每条结论关联实际支持它的页面，跨页条件保留多个页码。不能因为某页排第一，就把整份回答里的所有结论都引用到这一页。

面试回答

我们从农机手册、技术规范和操作资料中整理问题，覆盖文字参数、表格行列、图示部件、跨页条件，以及无答案或信息不足的场景。题目既有直接查询，也有业务中的自然表达，比如保养周期、适用型号、部件位置和多页操作要求。

每道题标注文档版本、参考答案，以及真正支持回答的证据页或片段，不能只标来源文档，因为召回同一文件里的无关页仍然不算命中。调参集和测试集分开，同一道题的近似改写放在同一组；固定版本、证据和指标口径后比较检索配置，无答案题单独检查澄清和证据不足处理。

面试回答

Recall@10 看前十条结果找全了多少标准证据；MRR@10 看第一个正确结果有多靠前；NDCG@10 进一步看高相关内容在整体排序中的位置，按名次折损收益，再与理想排序比较。

比如一道题有三个证据页，前十条找到了两个，Recall 就是三分之二；第一条正确结果在第二位，倒数排名就是二分之一。项目测得 Recall@10 为 0.945、MRR@10 为 0.798、NDCG@10 为 0.839，这些反映检索覆盖和排序，不能当作回答准确率。最终问答还要检查事实、条件和引用是否正确，以及链路耗时和成本。

面试回答

用户录入农机设备或查资料时，不一定知道准确型号。我接入图片识别服务，根据照片返回候选机型和置信度，先缩小范围，再让用户结合铭牌、品牌和设备参数确认标准机型。确认后，就可以继续查对应说明书、保养要求或故障资料。

因为不同系列和配置外观相近，角度、遮挡和背景都会影响结果，所以保留 Top-K 候选，不自动认定第一名正确。另外，标准机型和组织里的具体资产分开，识别出某个型号还不能确定是哪一台机器，关联具体资产仍要用户确认。

面试回答

EfficientNet 是一类卷积神经网络，经典方法通过复合缩放协调调整网络深度、宽度和输入分辨率，在识别能力与计算开销之间做平衡。深度影响特征层次，宽度影响表达能力，分辨率影响细节保留，单独扩大某一个维度不一定划算。

我们的任务是从已有农机类别中返回候选机型，适合封装成专门的图片分类服务。选择时既考虑相近型号的区分能力，也看服务延迟、模型大小和部署环境能承受的并发。独立服务的输入和输出比较稳定，后端可以统一映射机型和安排人工复核，模型升级也能单独进行。

面试回答

Java 后端负责用户认证、文件与业务校验，调用内部模型服务后，把候选标签映射为标准机型，再处理人工复核和业务关联。FastAPI 提供内部 HTTP 接口，负责图片解码与预处理，PyTorch 加载 EfficientNet 权重并完成推理，返回 Top-K、分数和模型版本。

模型服务主要做计算，不直接读取组织资产或工单，这样模型资源和业务服务可以分别部署、限流和升级。预处理中的尺寸、颜色通道和归一化要与训练配置一致，类别索引与机型标签也随权重管理，否则模型即使正常返回，也可能被映射成错误名称。

面试回答

农机相近型号的外观可能很接近，Top-K 可以保留多个候选，让用户结合铭牌和其他角度比较。模型输出的 Softmax 分数反映已知类别间的相对倾向，未经校准不能直接理解成这次识别正确的概率；一张不属于任何已知类别的图片也可能得到较高分。

所以除了 Top-1 分数，还结合前两名差距、图片清晰度、主体完整性和候选是否能映射有效机型来提示复核，阈值通过验证集确定。候选接近时请用户补照片或查看铭牌，即使分差大也保留确认。识别结果和模型版本记录下来，确认后再完成对应业务关联。

面试回答

我先区分输入问题和服务故障。格式错误、文件损坏或超出大小限制，就提示用户修改图片，重复推理没有意义；连接失败、暂时不可用可以在总时间预算内有限重试，过载时限制并发和等待队列，避免重试继续放大压力。

识别失败会返回明确状态，让用户重传、稍后重试或手动选择机型，不能把故障当成没有候选。推理成功但结果不明确则正常返回候选并要求复核。健康检查也看模型权重是否加载成功，不能只凭 FastAPI 接口已经启动就认为识别能力可用。

面试回答

MCP 的全称是 Model Context Protocol，用于让 AI 应用以统一方式连接外部工具和数据。普通 HTTP 接口已经提供业务能力，MCP Server 再把这些能力描述为可发现的工具，提供工具说明、参数 Schema 和调用方式，方便支持 MCP 的客户端接入。

我把图片识别、标准机型查询、知识检索、问答和故障排查等公共能力封装出来，实际仍复用 Java 后端的规则和访问范围。比如外部助手可以先识别图片，请用户确认机型，再调用知识问答查询保养要求。这样减少每个客户端分别理解和适配业务 API 的工作，业务实现和权限仍由原后端维护。

面试回答

每个 MCP 工具都定义清楚名称、适用场景、输入 Schema 和返回结构，同时说明是否写入数据。客户端获取工具描述后，模型根据用户目标提出工具名和参数，客户端与 MCP Server 校验后执行，Java 后端再检查实际业务范围。

例如图片识别工具接收图片和文件信息，只返回候选、置信度与复核建议，不创建资产；知识检索返回证据，知识问答再基于证据生成回答。边界明确，模型才容易正确选择。选择发生在客户端模型和编排层，MCP Server 负责收到调用后的校验与执行，不能因为模型选了工具就跳过参数或权限检查。

面试回答

外部调用方先认证，MCP Server 再使用受限服务身份调用后端，只开放平台公共标准机型和知识能力，不读取组织私有资产、工单或私有知识库。调用参数里填写组织 ID 不能扩大权限，实际范围由服务端身份和后端规则确定。

结果要区分成功但空结果、证据不足、参数或权限错误，以及超时和服务不可用。工具执行失败通过错误状态返回，让客户端决定修正输入、有限重试或向用户解释，不能把故障包装成正常空列表。问答保留引用和证据充分性，识别保留候选、模型版本及复核状态，帮助客户端正确解释结果。