高校内部文档 Agentic RAG
一句话:Java Gateway 管身份与服务路由,Python FastAPI 处理文档入库、检索与生成,授权范围贯穿问答链路。
画出的链路:上传 → 解析与切片 → Embedding/Milvus → 授权知识库 → 向量召回 + BM25 → RRF → LangGraph 证据判断 → SSE 回答及引用。
按“投递进展 → 岗位侧重 → 项目证据 → 八股与手写 → 模拟表达”推进。先把简历中的每一句讲清楚,再把 Java 基础补到能追问的程度。
依据你提供的两张投递截图及简历整理;进展会变化,面试通知以招聘系统为准。
优先准备 Java 基础、Spring、MySQL、Redis、项目中的登录鉴权和订单链路。东软 Home 是与学校/项目相关的真实经历,可用于“为什么东软”与团队协作问题。
截图显示两岗位均为“待处理简历”。FDE 重点练需求澄清、部署联调、故障定位;AI 应用重点练 RAG、Dify、SSE 和评测。
截图显示“简历已被 HR 查看”。重点讲 LangGraph 状态流转、权限边界、检索质量、证据决策、可观测性与安全。不要将“已查看”理解为面试邀请。
同一份履历切换不同主项目,复习时间按近期面试概率再动态调整。
60 秒开场:先说 Spring Boot、MyBatis、MySQL、Redis、JWT 的业务开发,再用 RAG 网关补充跨服务鉴权与接口协作。
60 秒开场:从文档入库、授权检索、Agent 证据决策到流式返回,突出你把 AI 能力接入实际后端服务的经验。
60 秒开场:讲清外部平台 API/AMQP 接入、日志定位、SSE 连接问题、Docker 环境和与业务方确认验收标准的方式。
60 秒开场:强调 LangGraph 的规划→检索→证据判断有边界、有授权、有失败回退,能解释“为什么不用单次 prompt”。
每天约 3 小时:90 分钟项目/八股、45 分钟手写、30 分钟口述、15 分钟复盘。若临时接到面试,直接跳到对应岗位卡和“临面清单”。
每个项目按“背景 → 个人职责 → 关键链路 → 难点取舍 → 验证结果”练 2 分钟和 5 分钟两个版本。没有量化数据时直接说验证方法,不编造提升百分比。
一句话:Java Gateway 管身份与服务路由,Python FastAPI 处理文档入库、检索与生成,授权范围贯穿问答链路。
画出的链路:上传 → 解析与切片 → Embedding/Milvus → 授权知识库 → 向量召回 + BM25 → RRF → LangGraph 证据判断 → SSE 回答及引用。
你的简历口径:负责登录模块,参与商品、套餐、结算单、下单的库表与接口设计,参与 Redis 热点数据和 OSS 图片存储。
重点复盘:账号密码及状态校验 → JWT 签发 → 管理端/用户端拦截器 → 业务接口;下单时购物车、订单主表/明细和支付状态如何保持一致。
D:\java\WangMiao 和 D:\WangMiao\sky-take-out;后者包含 wangmiao-server、JWT 拦截器和订单代码。面试前确认你实际提交过的模块,避免将现成项目全部归为个人开发。你的简历口径:Dify 智能体 SSE 流式对话、按用户隔离会话;华为云 IoT 设备注册与查询、AMQP 上报数据处理、规则告警和 Docker 部署。
关键链路:设备 → 华为云 IoT → AMQP 消费 → 解析设备/时间/属性 → 业务库/Redis → 告警规则 → 告警记录。对话链路是前端 → Java 服务 → Dify → SSE 透传。
你的简历口径:参与苍穹 PaaS 业务流程、AI 助手“坤坤”、活动申请状态流转、个人 ID 校验与轻分析大屏交互。
重点讲法:校友活动查询需求 → 业务数据/知识库接入 → 用户身份与申请记录匹配 → 助手答复及状态展示。把“参与”与“独立实现”分清。
点击题目展开参考要点。每题训练 60–90 秒:定义、原理、项目例子、边界。筛选岗位可聚焦。
每题先说边界与复杂度,写完至少测空输入、单元素、重复值和大输入。
“面试官您好,我是牛博斐,2027 届软件工程本科在读,之前在大连东软信息学院学习软件技术。我的项目主要有两条线:一是 Java 后端业务开发,做过商城登录鉴权、订单相关接口;二是 AI 应用工程,在高校文档系统里实践过 Java 网关、Python RAG、混合检索、权限控制和 SSE 流式回答,也在智慧养老项目里接过 Dify 与 IoT 数据。我比较重视把功能做成可验证、可维护的服务。今天应聘这个岗位,我想重点介绍与岗位最相关的【替换为主项目】。”
东软版突出 Java;AI 岗突出 RAG;FDE 版突出联调和排障。自然讲述,不逐字背诵。
S 情境:谁遇到什么具体问题?
T 任务:你负责哪一段,成功标准是什么?
A 行动:方案、取舍、代码与排查步骤。
R 结果:测试、演示、上线或用户反馈;没有可靠数据就说验证证据。
复盘:下一次如何改进。
勾选保存在本机浏览器。当前完成 0/0
以下每题要求讲出定义、原理、项目例子和边界。先口述,再点开核对;不会的回源码和官方文档。
“系统面向校内文档问答。我主要做文档入库、授权检索和 Agent 流程。Java Gateway 统一入口、校验 JWT 与知识库访问权;Python FastAPI 承担解析、向量化、检索与回答。入库保留文档、页码和知识库元数据;查询先确认授权范围,再做向量与 BM25 召回,用 RRF 融合。LangGraph 负责改写问题、规划检索和判断证据,不足时有限次继续检索;最后以 SSE 输出带来源的回答。最重要的工程边界是检索层也只读取授权语料,BM25 失效时可回退纯向量。我用切片、检索、权限和流程脚本验证。”
需要答到源码的追问:定位:rag-gateway/.../KnowledgeAccessFilter.java、rag-service/app/vectorstore/milvus_store.py、rag-service/app/graph/workflow.py。
“这是含管理端和用户端的宠物用品商城。我负责登录模块,参与商品、套餐、结算与订单接口设计。登录请求先查账号,核验密码和启用状态,签发 JWT;后续请求通过对应端的拦截器解析身份。订单侧重点是主表、明细和购物车的写入顺序与状态变化。技术上用 Spring Boot、MyBatis、MySQL、Redis、OSS。具体到个人工作,我可以指出自己负责的登录和联调部分,其他模块属于团队合作。”
需要答到源码的追问:源码能证明项目实现,个人贡献需以真实提交为准。定位:EmployeeServiceImpl.java、JwtTokenAdminInterceptor.java、OrderServiceImpl.java。
“我参与养老平台 AI 与设备能力扩展。AI 部分由 Java 服务代理 Dify 流式对话,按登录用户生成 Dify 用户标识,提供会话列表、消息历史和删除。IoT 部分对接华为云,AMQP 接收上报,解析后批量入库,同时按 iotId 写 Redis Hash,再由规则判断告警。这个项目让我熟悉外部接口接入、SSE 长连接和分层排障。”
追问:定位:DifyController.java、DifyServiceImpl.java、AmqpClient.java、DeviceDataServiceImpl.java。
“东软 Home 是校友服务团队毕业设计,基于金蝶云苍穹。我的参与点是 AI 助手‘坤坤’与业务数据结合、活动申请状态流转、个人 ID 校验和轻分析大屏交互。业务目标是让校友申请活动、查询状态和通过助手获取信息。我会用实际页面、流程配置或毕业设计材料说明个人工作。”
追问:公开页面可佐证项目背景,不等于每项功能均由你独立实现。
每套按 40 分钟限时录音。回答不了的题,在题后写下要查的源码位置和下一次回答日期。
int longest(String s) {
Map<Character,Integer> last = new HashMap<>();
int left = 0, best = 0;
for (int right = 0; right < s.length(); right++) {
char c = s.charAt(right);
if (last.containsKey(c))
left = Math.max(left, last.get(c) + 1);
last.put(c, right);
best = Math.max(best, right - left + 1);
}
return best;
}边界:空串、重复连续字符、Unicode 代理对。
int lowerBound(int[] a, int target) {
int l = 0, r = a.length;
while (l < r) {
int m = l + (r - l) / 2;
if (a[m] < target) l = m + 1;
else r = m;
}
return l;
}采用左闭右开区间;全小于 target 时返回数组长度。
SELECT * FROM (
SELECT o.*, ROW_NUMBER() OVER (
PARTITION BY user_id
ORDER BY create_time DESC, id DESC
) AS rn FROM orders o
) t WHERE rn = 1;同一时间用 id 打破并列;用实际数据量评估窗口函数代价。
SELECT * FROM orders
WHERE user_id = ?
AND (create_time < ? OR
(create_time = ? AND id < ?))
ORDER BY create_time DESC, id DESC
LIMIT 20;建议检查 (user_id, create_time, id) 索引和执行计划。
HashMap 定位节点 + 双向链表维护访问次序。get 命中移到头;put 更新或插入,超容量删除尾节点并从 Map 移除。复杂度 O(1)。手写时必须包含虚拟头尾、remove、addToHead,测容量 0 和重复 put。
这是改进方案,不代表汪喵当前已实现。
每天 3–4 小时,具体交付物写在最后一列。若面试在一周内,优先做 1、2、4、6、8、10、13、14 天。
| 天 | 学习与源码 | 手写/场景 | 口述与交付物 |
|---|---|---|---|
| 1 | 简历逐句核对,划分个人/团队职责 | 两数之和、二分 | 90 秒介绍录音;四项目各一张职责卡 |
| 2 | 汪喵登录、JWT、拦截器源码 | 最长无重复子串 | 画登录时序图,讲 2 分钟 |
| 3 | Java 集合、并发、线程池、JVM | LRU | 8 道 Java 题闭卷口述 |
| 4 | Spring MVC、IOC、AOP、事务;订单源码 | 幂等下单设计 | 画订单事务边界与状态图 |
| 5 | MySQL 索引、MVCC、锁、EXPLAIN | 最新订单 SQL、游标分页 | 一条慢 SQL 分析记录 |
| 6 | Redis 结构、缓存问题、一致性 | 热点商品缓存场景 | 东软 Java 模拟面试录音 |
| 7 | RAG 文档解析、切片、Embedding | 切片边界测试设计 | 画入库链路并解释失败处理 |
| 8 | Milvus、BM25、RRF 与授权代码 | 手算一组 RRF 排名 | 讲清“为什么混合检索” |
| 9 | LangGraph 节点、状态与终止条件 | 无证据/越权样本设计 | 画 Agent 状态图 |
| 10 | JWT、HMAC、SSE、提示注入 | 跨用户知识库攻击场景 | 超聚变 AI 模拟面试录音 |
| 11 | 星海智办 Dify 服务与会话隔离 | SSE 中断排查 | 画前端→Java→Dify 链路 |
| 12 | IoT AMQP、入库、Redis、告警规则 | 消息重复/晚到场景 | FDE 故障排查口述 |
| 13 | 东软 Home 业务与真实个人证据 | 活动状态机设计 | 四岗位模拟各 20 分钟 |
| 14 | 错题与源码补漏,复看 JD | 限时两道手写+一道 SQL | 最终介绍录音、反问清单 |
按真实面试节奏整理:简历核验 → 项目深挖 → 基础知识 → 场景与手写 → 行为问题。67 道题都给出可直接口述的示范回答,以及下一层追问的示范回答。涉及个人贡献与未落地方案时,请按自己的实际工作调整表述;不要逐字死背。
对没有亲自实现的内容说“项目目前是……,如果我来改会……”。这个区分比背出标准答案更重要。
建议逐题口述 60–120 秒。展开后先看回答要点,再尝试回答追问。
示范回答:我投 Java 后端,是因为我做过的项目核心工作本来就包含服务端工程。汪喵 E 家中,我负责登录相关开发,接触了 Spring Boot、MyBatis、MySQL、JWT 和接口鉴权;在高校 RAG 项目里,Java Gateway 承担路由、JWT 校验及知识库访问控制,Python 只负责 AI 检索与生成。我想继续把接口设计、数据一致性、性能和排障能力做深,AI 经验也能帮助我理解业务中新增的智能化需求。
追问示范回答:我会打开汪喵的登录 Service 和 JWT 拦截器,说明输入、查询、校验、令牌签发与受保护接口的路径。个人独立贡献以我的提交和联调记录为准;RAG 网关部分会指出 JwtAuthFilter、KnowledgeAccessFilter 的具体实现。
示范回答:专升本是我的真实学习路径。我在辽宁工业大学软件工程专业的统招专升本年级排名 46/600,系统学了数据结构、网络、操作系统、数据库;更重要的是把知识用在了项目里,例如订单事务、JWT 鉴权和 RAG 网关的对象级权限。我不把竞赛奖项当成后端能力的替代,面试官可以直接通过代码和基础题检验我。
追问示范回答:我会选一个真实问题讲“现象—定位—修改—验证”。例如 RAG 检索越权风险:先复现不同用户访问同库的边界,再检查网关与检索层过滤,修正后用跨权限样本回归。具体提交和测试记录我会提前准备好。
示范回答:我说“熟悉 Java”,指能完成常见 Spring Boot 业务接口、用 MyBatis 操作数据库、理解 JWT 拦截和接口联调,并能沿日志和源码排查问题。我没有高并发核心系统的生产经验,JVM 调优和分布式事务属于正在补强的部分。这样定义更准确,也便于您针对我做过的部分追问。
追问示范回答:以汪喵登录为例:Controller 接收用户名和密码,Service 根据用户名查 employee,比较密码摘要并检查状态,登录成功后 Controller 签发 JWT;受保护接口先经过对应拦截器解析 token,再进入业务方法。
示范回答:管理端登录请求先进入 Controller,传入 EmployeeLoginDTO。EmployeeServiceImpl.login 用用户名查询 employee,代码中对前端明文密码做 MD5 摘要后与库中值比较,再检查账号是否禁用;成功后 Controller 生成 JWT。后续管理端请求被 JwtTokenAdminInterceptor 拦截,解析 token、取员工 ID 放进请求上下文。我的职责应以实际提交为界,登录 Service 和联调是我能重点讲的部分。
追问示范回答:当前代码对“账号不存在、密码错误、账号锁定”抛不同异常,内部排障方便,但公开接口可能暴露账号存在性。若面向公网,我会考虑统一对外错误提示,内部日志保留具体原因,同时加登录限流与失败次数控制。
示范回答:我核对了本地代码:EmployeeServiceImpl 用的是 MD5 摘要,并没有加盐或自适应成本。这是已有实现,但不符合今天的密码安全要求。我不会把它说成安全方案。改造时会用 bcrypt 或 Argon2 存新密码;旧用户登录时先按旧算法验证,成功后立即重新哈希并更新,逐步迁移,同时设置迁移期限和异常监控。
追问示范回答:数据库给密码记录加算法版本字段;登录时按版本验证。旧 MD5 验证成功才用 bcrypt/Argon2 重写。不能把旧 MD5 字符串直接再次哈希并认为等同于明文密码迁移;长期未登录用户到期要求重置密码。
示范回答:JWT 中的 exp 能让服务端拒绝过期令牌,但签发后通常不能天然撤销。项目拦截器主要做解析和身份提取;如果要支持退出与盗用处置,我会采用短有效期、刷新令牌、服务端 token 版本或黑名单,并对敏感操作再验证。全链路用 HTTPS,令牌不写入日志。这里我会明确区分项目现状与改进方案。
追问示范回答:黑名单若依赖 Redis,需要考虑 Redis 故障时的策略:敏感接口可失败关闭,普通接口可结合短有效期控制风险;Redis 做高可用并监控。也可采用用户 tokenVersion,轮换版本后旧 token 全部失效。
示范回答:我核对了 OrderServiceImpl.submitOrder 上的 @Transactional。它先检查配送地址和购物车,再插入订单主表、批量插入订单明细,最后清空该用户购物车。这三次数据库写入应在同一事务里,任何一步失败都应回滚,避免只有主订单没有明细。支付是另一阶段,不能把等待外部支付平台的网络调用放在长数据库事务中。
追问示范回答:如果插入明细抛 RuntimeException 且异常向外传播,Spring 事务代理会回滚前面的主表插入;若异常被吞掉或者不满足回滚规则,就可能误提交。我会写故障注入测试核对实际回滚,并检查数据库表引擎。
示范回答:我先说明这是设计题,不能说汪喵当前已实现。库存扣减可以用数据库条件更新:UPDATE product SET stock=stock-? WHERE id=? AND stock>=?,检查影响行数;订单写入与扣库存在同一事务。更高并发时可预扣和异步确认,但要设计超时释放、失败补偿和防重复。系统最终以数据库或可靠库存服务作为权威来源。
追问示范回答:缓存库存可用于展示或预判,不能单独作为最终扣减依据。扣减成功后删除或更新缓存,并通过消息重试/定期对账处理不一致;下单时仍需原子条件更新保护最后一件商品。
示范回答:我核对的 submitOrder 是按当前时间毫秒生成订单号,不能据此宣称已经实现请求幂等。改进方案是前端每次下单生成 requestId,服务端对 userId+requestId 建唯一约束;事务里首次创建订单,重复请求查询并返回同一订单。支付回调另用交易号和订单状态做条件更新,确保重复通知不会重复处理。
追问示范回答:幂等键至少保留到订单生命周期中需要防重的窗口,最好与订单记录一起长期保存。客户端超时重试使用原 requestId;如果第一次请求已成功但响应丢失,服务端返回原订单号,不再创建第二单。
示范回答:我会先指出项目中具体缓存的是哪类数据和 key,再谈策略,避免空泛说“用了 Redis”。对于商品信息常用 cache aside:读取未命中查库并回填;修改商品先更新数据库,再删除对应缓存。这样仍存在并发读旧值回填、删缓存失败的窗口,因此要结合 TTL、重试和监控;价格与库存等关键字段不能只依赖缓存。
追问示范回答:一个线程读到旧数据库值,在更新线程删缓存后才回填,会短暂出现旧值。可通过短 TTL、延迟二次删除、版本号/消息通知降低窗口;高一致性场景直接读权威数据或引入更严格的序列化更新。
示范回答:put 时先计算 key 的 hash 并定位桶;空桶直接插入,冲突时比较 hash 和 equals,在链表或树中找同键并覆盖,否则新增节点;达到阈值时扩容。HashMap 不保证并发写安全,跨线程共享时可用 ConcurrentHashMap。选择 key 时必须保证参与 equals/hashCode 的字段在入表后不变。
追问示范回答:如果 key 入 Map 后参与哈希的字段变化,查找时会落到新桶位置,而对象仍在旧桶,可能无法 get/remove。这就是为什么通常用不可变对象或稳定 ID 作 key。
示范回答:如果已经拿到 LinkedList 节点,局部插入可以 O(1),但业务常常要先按下标或条件找到位置,仍需 O(n) 遍历。ArrayList 随机访问 O(1),中间插入要搬移 O(n),但内存局部性较好。分页结果主要顺序遍历和按索引读取,我会用 ArrayList,除非有明确的频繁链表节点操作需求。
追问示范回答:分页结果用 ArrayList:结果集通常先批量构造,再序列化遍历;它内存更紧凑,按位置访问快。LinkedList 在这里没有明显优势,还增加节点对象与 GC 压力。
示范回答:不能。i++ 包含读取、加一、写回,volatile 只保证变量可见性及一定有序性,两个线程可能都读到相同旧值。若只是计数,可用 AtomicInteger 的 CAS;如果还要同时维护多个字段的一致性,用 synchronized 或 Lock 把整个临界区保护起来。
追问示范回答:ABA 是值从 A 变 B 又变 A,单纯 CAS 看见还是 A,误以为没有变化。带版本号的 AtomicStampedReference 能检测;实际业务更常用状态版本列做乐观锁。
示范回答:队列满时会触发线程池配置的拒绝策略,可能抛异常、由调用线程执行或丢弃任务。业务上不能接受静默丢弃;我要按任务重要性定义有界队列、超时、拒绝告警与降级。线程池大小也受下游容量约束,不能只把线程数调大。
追问示范回答:Dify 调用是长耗时外部 IO,若占用公共线程池,可能把普通业务任务也拖死。应使用专用有界线程池/异步客户端,设置连接与读取超时、并发限制、取消传播和监控。
示范回答:Spring 声明式事务通常由代理实现。同类内部 this 调用绕过代理、异常被捕获不再抛出、受检异常未配置回滚、跨线程执行或对象不是 Spring Bean,都可能让预期事务不生效。汪喵订单的 submitOrder 是对外 Service 方法并加了 @Transactional,我会重点核对其调用路径和异常传播。
追问示范回答:我会优先拆分到另一个 Spring Bean,由代理调用 B;也可以调整事务边界,让外部入口方法本身带事务。不推荐为了“生效”随意从容器获取自己而掩盖职责设计问题。
示范回答:Filter 位于 Servlet 请求链,适合通用请求预处理;Interceptor 位于 Spring MVC Handler 链,适合鉴权和请求上下文;AOP 在方法代理层,适合事务、日志等横切逻辑。高校 RAG 的 Gateway Filter 在路由前做 JWT 与知识库授权;汪喵用 MVC Interceptor 校验管理端/用户端 token。
追问示范回答:Controller 注解可以作为补充,但若入口很多,容易漏标;对象级授权还需要检查当前用户对具体资源的关系。网关和服务端统一拦截可以形成默认拒绝的边界,关键业务操作仍应复核授权。
示范回答:先拿到真实慢 SQL、参数、数据规模和执行时间,再用 EXPLAIN 看是否使用索引、估计扫描行数和排序方式。用户订单按时间倒序查询,常考虑 user_id、create_time、id 组合索引,稳定分页用时间加 ID 游标。建索引后必须用真实数据回测;选择列顺序还要看过滤条件和写入成本。
追问示范回答:即便存在索引,选择性低、统计信息不准、函数/隐式类型转换、返回行过多或排序不匹配,都可能让优化器选全表扫描。要看执行计划而不是认定“建了索引就一定走”。
示范回答:InnoDB 一致性读通过 Read View 选择可见版本,undo log 提供旧版本;当前读要读最新可见数据并对并发修改加锁。RR 下不能简单说“绝不会有幻读”,要区分普通 SELECT 和 SELECT FOR UPDATE/UPDATE。订单状态查询展示可用一致性读,真正进行状态迁移时需条件更新或锁保护。
追问示范回答:快照读可能沿事务 Read View 看到旧版本;当前读要处理最新记录并加锁,所以同一事务内两类读的结果可能不同。回答时我会给出具体 SQL 与隔离级别,而不泛泛背结论。
示范回答:先确认影响范围、开始时间、失败接口与错误比例,再用请求 ID 关联入口日志、应用异常、数据库连接和下游依赖,同时核对最近部署/配置变更。若影响严重,先回滚或降级止损;定位根因后写复现和回归测试。不能一看到 500 就重启服务。
追问示范回答:只有一部分用户失败,优先比较账号角色、数据权限、请求参数、地区/网络、会话状态与分流实例。还要看是否某个数据库分片或某台实例异常,用请求 ID 和实例标签关联。
示范回答:我会用左闭右开区间 [l,r),初始 l=0、r=数组长度;每轮取 m=l+(r-l)/2。若 a[m] 小于 target,左边界改为 m+1,否则右边界改为 m。循环结束 l 即首个大于等于 target 的位置,无匹配则返回数组长度,时间 O(log n)、空间 O(1)。
追问示范回答:最后一个小于 target 的下标正好是 lowerBound(target)-1。若结果为 -1,说明没有更小元素;这个复用方式能少写一套容易错边界的二分。
建议逐题口述 60–120 秒。展开后先看回答要点,再尝试回答追问。
示范回答:我会按模块说清楚:高校 RAG 中我能讲文档解析和切片、授权范围内的混合检索、LangGraph 状态图、SSE 与测试脚本,并指出对应代码和验证结果;Java 侧会指出 Gateway 的 JWT 与知识库访问过滤。AI 编程工具用于查文档、生成初稿和辅助定位,但代码是否正确由我阅读、联调、写测试和复核。我不会把工具生成的内容或团队功能都说成个人独立完成。
追问示范回答:我会选一次真实 bug,把失败输入、日志、相关函数、根因和回归测试讲完整。比如检索结果异常时先分开检查向量分支与 BM25 分支、授权 ID、候选数和融合去重,最后用固定问答样本复测;具体案例以我的提交记录为证。
示范回答:Java 侧承接用户、知识库、聊天及网关鉴权,Python 对 LangGraph、文档解析、Embedding 和 Milvus 的生态更成熟,所以分层后职责比较清楚。代价是跨语言调用增加延迟、部署和身份传递复杂度,因此内部请求要有签名、超时和链路日志。若是小型 MVP,我会看团队基础,未必一开始就拆多个服务。
追问示范回答:两周交付时我会先保留明确的用户权限边界和可替换的 RAG 接口;如果没有现成 Java 服务,可能先做单体 API 验证效果。等业务与性能指标明确后再拆分,避免为架构复杂度付出过早成本。
示范回答:上传后先校验格式和大小,解析器把不同文件转成统一的文本片段及来源元数据:PDF 尽量保页码,DOCX 保标题/段落,Markdown 利用标题层级,TXT 按段落。之后切片、向量化并存文档 ID、知识库 ID 和页码。当前项目支持文本型 PDF 等格式;扫描 PDF 的图片文字需要 OCR,不能把它说成已具备的能力。
追问示范回答:表格跨页时普通文本抽取可能打散行列关系,我会先识别表格边界、保留标题和列头,必要时把表格转换为结构化文本;图片文字接 OCR,并把 OCR 置信度纳入入库质量检查。
示范回答:切片大小没有适用于所有文档的固定值。太小容易丢上下文,太大则引入无关内容并增加 token 和向量成本;overlap 可保住边界语义,却会增加重复召回。我会用不同文档类型的标注问答集,对比 recall@k、引用准确率、答案正确率与延迟,再决定参数。
追问示范回答:融合前可按 chunk_id 或文档 ID+页码+内容去重;生成上下文再做相邻片段合并或冗余去除,给不同来源设上下文配额,避免相同内容占满证据窗口。
示范回答:Embedding 模型换了,旧向量和新向量通常不在同一空间,甚至维度也不同,不能只改配置继续查询。我要给每批向量记录模型版本,建新集合/索引并全量重算;用固定评测集比较质量与延迟,灰度读新索引,确认后切流并保留回滚窗口。
追问示范回答:切换期间新上传文档可双写两套索引,或暂时写旧索引并记录待重算队列。必须确保用户查询命中的索引版本与查询向量模型一致,切流前核对文档数量和失败任务。
示范回答:向量检索对“意思相近但措辞不同”的问题有优势,但遇到课程编号、文件名、条款号等精确词,语义相似度不一定把正确段落排前。BM25 根据词项匹配可补这部分,二者在相同授权语料内召回,再由 RRF 融合。我会用真实问答集比较纯向量与混合结果,不只凭理论判断。
追问示范回答:例如问“某课程 2026-A-17 号文件的有效期”,编号可能是检索关键。我要用实际文档和查询跑纯向量、纯 BM25、融合三组,展示正确片段的排名变化,不能临场编造已测过的数值。
示范回答:项目中向量和 BM25 两路各返回候选列表,按名次计算 1/(rrf_k+rank),同一段在两路出现就累加得分,最后排序取 Top K。原始向量相似度与 BM25 分数尺度不同,直接加权需要校准。代码优先按 chunk_id 去重,缺失时用知识库、文档、页码、内容组合。
追问示范回答:同一段两路命中后只保留一份文档记录,但两路的 RRF 分数都加到这份记录上,retrieval 标为 both。若 chunk_id 不稳定或重复,备用组合键仍可能有误,需要在入库阶段保证 ID 稳定。
示范回答:当前 hybrid_search_multi 在 BM25 分支抛异常时记录 warning,并直接返回向量分支前 Top K,保障问答基本可用;但精确词召回质量可能下降。我会监控 BM25 回退次数与比例、索引构建耗时和请求质量,超过阈值告警并修复,而不是把降级当正常状态。
追问示范回答:每次回退打结构化指标,按服务实例和知识库聚合,告警条件可以是连续 N 分钟回退率超过阈值;同时做定期健康检查和固定精确词查询,防止只有用户投诉才发现。
示范回答:Java Gateway 先校验 JWT 和当前用户对请求知识库的访问关系;到 Python 后,检索函数只接受明确授权知识库 ID,Milvus filter 和 BM25 语料加载都按该范围执行。这样即使模型要求“去查别的库”,工具也不能扩大权限。答案生成的 prompt 不是安全边界。
追问示范回答:历史引用也可能泄漏已撤销的资料。下一次查看历史或重新生成时应按当前权限重新检查引用;对旧会话可隐藏无权来源或使其失效。项目当前实现到哪一步要现场核源码,不应把设计建议说成现状。
示范回答:实际图从 query_analysis 开始,依次经过 rewrite、plan、retrieve、decide;plan 无可执行查询可结束,decide 判断证据不足时可回 plan。回答生成在图执行后的 SSE 阶段,不是图内无限循环节点。状态里至少有原问题、改写问题、计划、授权库 ID、证据、迭代次数、deadline 与是否继续等信息。
追问示范回答:我会打开 RagState 和 agents.py 说明字段:iterations 记录已检索步数,deadline 限制总时间,should_continue 决定是否回 plan;plan_query 或 plan_kb_ids 为空时直接结束。具体上限由配置项控制。
示范回答:多轮问答中的“它”“上面那份”需要结合会话上下文改写成可检索的问题,否则直接向量化可能召回错误。改写只负责澄清指代和补全省略,不应擅自添加事实;保留原问与改写问供日志和回放。若上下文里有多个可能对象且无法确定,应该询问用户或分别检索并标明歧义。
追问示范回答:如果前两轮分别谈“2025 版培养方案”和“2026 版培养方案”,用户问“它什么时候生效”,单靠最近一轮可能猜错。我会让改写结果保留版本依据,无法唯一判断时先追问“你指哪一版”。
示范回答:Evidence 节点根据已有来源判断是否覆盖问题,若有具体缺口,就把缺口交给下一次 plan;但只有在授权范围、检索步数和 deadline 都允许时才继续。若已经无可执行计划或达到边界,就结束检索,生成阶段说明证据不足,而不是无限尝试或编答案。
追问示范回答:源码中 agents.py 检查 iterations、deadline 和最大步数;workflow.py 的条件边只在 should_continue 为真时回 plan。测试要覆盖零结果、模型异常和重复同一计划,确认都能有限步退出。
示范回答:我不会说系统能完全消除幻觉。做法是先提高授权范围内的召回,保留文档、页码、chunk 等来源元数据;生成时只依据证据,证据不足时明确不确定;最后用标准样本核对“结论是否被引用片段支持”。如果两份文档冲突,答案要列出来源和版本,不可混成一个确定结论。
追问示范回答:先核对文档权威性、发布时间和适用范围;若无法判断,就回答“来源 A 说……,来源 B 说……,目前不能确认统一结论”,并提示需要哪个业务负责人确认。
示范回答:检索文档是不可信输入,文档里的“忽略之前指令”必须被当作普通内容。系统指令与检索内容分隔,工具调用只开放固定能力,服务端校验用户权限和参数;尤其知识库范围不能由模型扩大。我会把恶意文档加入测试集,检查模型是否泄漏其他库内容或调用越权工具。
追问示范回答:即便模型被诱导,服务端检索工具仍只接受当前用户授权的知识库 ID;高风险工具要做白名单、参数校验、只读或人工确认。安全不能只靠提示词。
示范回答:JWT 主要证明终端用户身份并承载受控声明;HMAC 用共享密钥对 Java/Python 内部请求的关键字段签名,验证调用方与内容完整性。HMAC 不是加密,不能替代 HTTPS;还要考虑时间戳、nonce 防重放和密钥轮换。面试时我会指出项目实际签名字段和验证代码,没核实的细节不编造。
追问示范回答:轮换时支持新旧密钥短暂并存,按 keyId 选验证密钥,先部署验证端再切签名端,观察失败率,最后撤旧密钥。密钥存安全配置,不放仓库或日志。
示范回答:我会做分层评测集:事实查询、编号精确匹配、跨文档综合、无答案、权限越界、冲突文档和提示注入。分别看 recall@k、正确来源命中、答案事实准确、拒答质量、越权率,以及 p95 延迟、token 成本。项目中的 LLM 自评可辅助观察趋势,但不能代替人工标注或标准答案。
追问示范回答:若质量升而延迟翻倍,要看岗位需求与 SLO。先拆分各节点耗时,尝试并行检索、缓存和只对复杂问题启用 Agent;若超出用户可接受延迟,就不能只凭准确率宣布方案更好。
示范回答:先用时间戳拆开“模型首 token 慢”和“传输缓冲”:看 Python 生成时间、Java/网关转发时间、代理和浏览器收到第一段的时间。检查响应 Content-Type、逐段 flush、Nginx proxy buffering、超时和客户端读取方式。用户断开时要尽量取消上游生成、关闭连接,避免继续消耗 token 与线程。
追问示范回答:监听客户端取消或写入异常,把取消信号传到上游请求,并在 finally 关闭响应体/连接与计时资源;指标上记录断线后仍运行的任务数量,防止隐性成本。
示范回答:十万份文档时,首先担心解析与 Embedding 吞吐、向量批量写入、索引构建、任务重试、重复上传、版本更新和删除一致性。应把入库做成有状态的异步任务,按文档 ID 和内容哈希去重,批处理并限制并发,失败能重试或人工处理;查询侧监控过滤后的召回耗时与权限边界。
追问示范回答:给文档内容哈希与版本号,重复相同内容可跳过重算;同名但内容变更则生成新版本,成功后切换可见版本并清理旧向量。写入向量时使用稳定 chunk ID,重试采用覆盖/幂等策略。
示范回答:星海智办主要是 Java 服务代理 Dify API,利用已有应用能力快速接入对话与会话;高校 RAG 则自建 LangGraph,可以把授权检索、证据判断、回退和测试做得更贴合业务。Dify 的开发速度与运营体验有优势,自建则灵活但要承担状态管理、监控和维护成本。选型取决于权限复杂度、可控性、时间与团队能力。
追问示范回答:养老项目的 Dify 负责上游会话和生成,Java 侧负责用户标识、接口与 SSE 转发;RAG 项目的规划、检索和证据决策由自己实现。两者不可都说成“我自研了智能体引擎”。
示范回答:我会用真实案例回答,不编造指标:先给出某个失败问题和预期来源,再展示实际回答/引用错误;把链路拆成解析、切片、授权、召回、融合、生成,定位问题落在哪层;修改后用同一问题及相邻样本回归,防止只优化单题。如果具体失败记录拿不出来,我会承认需要补充证据,而不说“调了 prompt 就解决”。
追问示范回答:把原问题、文档版本、授权角色、期望 chunk/答案、错误类型写进回归集;每次改切片、Embedding、RRF 或 prompt 都跑同一组,记录质量和延迟变化。
建议逐题口述 60–120 秒。展开后先看回答要点,再尝试回答追问。
示范回答:我不会先猜是服务器配置不够。先问“哪个页面/接口慢、何时开始、所有人还是部分人、操作步骤、客户网络和预期响应时间”,拿一次请求 ID 与时间线。再从浏览器耗时、网关、Java 服务、数据库、Dify/IoT 外部依赖分层测量,判断是首包慢、流式卡顿还是整体吞吐不足。确认根因后给客户可复现的处理方案与验收数据。
追问示范回答:若现场无法复现,先收集受影响用户、时间、请求 ID、浏览器 HAR 或录屏、实例日志和监控曲线;部署临时、脱敏的链路耗时日志,约定下次发生时的采集方式,而不是要求客户“再试试”。
示范回答:先确认客户的数据安全要求、可用 GPU/CPU、内网镜像与软件许可,不能直接把云 API 地址改成本地地址。应用层抽象模型与 Embedding 接口,选择可离线部署的模型,重建向量索引并重新评测回答质量、时延与并发;同时准备离线依赖包、配置、日志和回滚方案。最终以客户接受的质量与资源成本作为验收边界。
追问示范回答:若硬件不足,列出可选方案与量化代价:更小模型、量化、降低并发或分批处理,以及回答质量变化。不要承诺原云模型同等效果;让客户选择服务等级和硬件投入,并记录验收标准。
示范回答:我按链路查:设备是否实际发送、华为云 IoT 是否收到、AMQP 是否连接并消费、消息体能否解析、数据库和 Redis 是否写入、查询接口是否返回、前端是否展示。用设备 ID、平台 messageId 和时间戳串起每层日志。该项目 DeviceDataServiceImpl 处理上报并批量入库、写 Redis Hash,因此要分清“消息没来”和“来后处理失败”。
追问示范回答:平台已投递而数据库无记录,我先看 AmqpClient 的连接/消费日志和消息体,确认异步任务是否提交、线程池是否拒绝、handleMessage 是否抛异常,再查数据库连接与字段转换。现代码自动确认并异步处理,失败后不保证重投,是必须披露和改进的风险。
示范回答:我先区分是建立连接失败、运行中断还是消息处理异常。检查网络、域名/DNS、TLS 证书、访问密钥、机器时间、队列名、心跳、并发连接数和平台限额;结合异常类型和时间线找规律。项目代码目前在创建连接时把证书设为 trustAll,这在生产环境应改为校验证书链,不能作为安全做法推广。
追问示范回答:项目用 Session.AUTO_ACKNOWLEDGE,且监听器把消息交给线程池后返回;即使后续业务处理失败,也不能据此保证平台重新投递。若要求可靠处理,应调整确认时机或使用可持久化任务队列,并给消息去重、重试和死信处理。
示范回答:先用 curl 或浏览器 Network 看 Dify 上游是否分段返回,再看 Java DifyServiceImpl 是否逐段读取并 flush,最后查网关和 Nginx 是否缓冲、超时或改写 Content-Type。若上游本身首 token 慢,优化模型/检索;若 Java 已逐段输出但浏览器成批收到,重点查代理缓冲。每层记录首字节与最后字节时间。
追问示范回答:用 curl -N 调上游 Dify、Java 代理和最终域名三个地址,分别记录首个 data: 到达时间;若 Java 快而域名慢,检查代理配置如 proxy_buffering 和压缩;同时确保响应为 text/event-stream。
示范回答:先比较变更前后镜像版本、环境变量名、值来源和启动日志,只输出变量是否存在及配置版本,不打印密钥明文。若是配置错误,回滚到已验证版本或通过安全渠道修正,再做健康检查、登录/对话/设备数据的冒烟测试。还要防止前端构建时把服务端密钥打进静态资源。
追问示范回答:轮换后需同步更新使用该密钥的应用实例、任务进程、网关/代理配置和可能的 CI 密钥存储;先保证新旧密钥短时兼容,再撤销旧密钥并检查异常调用。
示范回答:我会先保留原始消息样本和失败率,确认是新增字段、字段改名、类型变化还是时间格式变化。解析层做兼容与版本判断,对无法识别的消息隔离保存并告警,不直接丢弃;补充回归样本后灰度发布。项目当前处理路径是 AMQP→DeviceDataServiceImpl,因此要核对这一层的字段映射和数据库约束。
追问示范回答:若客户要求立即恢复,可先把无法解析的新格式消息落到隔离队列/文件,保持旧格式正常处理;和设备方确认协议版本,再上线双版本解析,重放隔离消息并对账。
示范回答:我会把“系统能用”拆成可验收项:部署环境和依赖版本、核心业务场景、准确性/权限、p95 延迟、并发、故障恢复与日志留存。让客户提供代表性数据和账号,双方确认测试步骤、通过阈值和不在本期范围内的内容。验收结论附测试记录,而不是只发一张页面截图。
追问示范回答:若测试不通过,我会说明失败项、影响、临时绕行、修复时间和重新验收标准;任何缩小范围或放宽指标都要由相关负责人书面确认。
示范回答:我会先做资产清点:入口、服务、数据库、外部依赖、部署方式和联系人,再通过日志、接口文档、配置和代码画最小链路图。先在测试环境复现一个核心流程,建立“正常路径”的基线,再处理变更;对不理解的数据表和定时任务不直接修改。每一步记录证据,避免只靠口头交接。
追问示范回答:若没有文档,我会用只读方式查看部署清单、API 路由、数据库结构与日志,约一次业务走查确认关键流程;把得到的最小架构和风险点整理成新文档,供客户和研发共同核对。
示范回答:问题单要让研发无需猜:环境与版本、影响用户和严重程度、时间、复现步骤、期望与实际、请求 ID、脱敏日志、已经排除的层、临时绕行和回归条件。若涉及安全/数据丢失,按紧急流程升级,同时保持对客户的进度沟通。FDE 的价值是把模糊的现场现象变成可定位的问题。
追问示范回答:研发无法复现时,我会补充客户数据特征和环境差异,必要时做远程结对调试、加临时观测点或构建最小复现。若仍无法复现,保留监控与采样计划,不把问题直接关闭。
建议逐题口述 60–120 秒。展开后先看回答要点,再尝试回答追问。
示范回答:我理解智能体不是“接了大模型就叫 Agent”。它需要带目标和状态,能在受控工具集合里规划、执行、观察结果,并根据证据决定下一步或终止。普通单轮 RAG 对简单事实查询通常更经济;我的项目在多轮指代、多个证据点和首轮检索不足时,才需要改写、规划、再检索和证据判断。
追问示范回答:例如问“2025 与 2026 两版培养方案在毕业学分要求上有什么变化”,一次检索可能只找到一版;Agent 可拆成两版证据需求,分别检索授权资料,再判断是否足够比较。
示范回答:我会画实际代码链路:query_analysis 解析问题,rewrite 处理多轮指代,plan 形成受授权约束的查询,retrieve 调混合检索,decide 审查证据。若 decide 认为仍有缺口且未超预算,就回 plan;否则结束图执行,随后 SSE 阶段基于证据生成。每条边都要有退出条件,不能让模型无限调工具。
追问示范回答:plan_query 或 plan_kb_ids 为空时 after_plan 返回 end;这意味着没有合法可执行检索。系统应在生成/响应阶段明确告诉用户缺少可检索资料或权限,而不是擅自扩大库范围。
示范回答:状态应保留原问、改写问、授权知识库集合、当前检索计划、证据列表、尚缺的证据点、迭代次数、deadline 和错误/停止原因。长对话不宜把所有文档全文不断放进状态,可保存文档 ID、chunk ID、页码和短摘要,只在生成前按预算组装上下文。压缩时要保留用户明确的约束和权限范围。
追问示范回答:我会把历史分成近期原文、稳定事实摘要和可追溯引用。摘要有版本和来源,定期重建;对“只能查某部门资料”这类安全约束不能由模型摘要决定,必须从当前用户权限服务读取。
示范回答:不能。Agent 可以在服务端提供的授权集合内选择要检索的库,但不能自造一个知识库 ID 就获得访问。Gateway 先做对象级访问校验,Python 检索时 Milvus filter 和 BM25 语料加载再次限定授权 ID。工具的权限边界在代码里,不在模型提示词里。
追问示范回答:模型若传管理员库 ID,工具层会与当前授权集合求交或直接拒绝;空授权返回空结果并记录越权尝试。测试要覆盖伪造 ID、跨角色和权限中途变更。
示范回答:权限不能在会话创建时一次判定后永久沿用。下一次检索时重新获取当前授权;生成前也应检查拟引用证据仍可访问。已保存的历史引用在查看时要按现权限过滤、隐藏或标记失效。项目当前是否做到了每一步,面试时会区分“已实现”和“应补的安全设计”,不能把理想方案说成现状。
追问示范回答:缓存键不能只用知识库 ID;至少包含用户/角色及权限版本,并设置合理 TTL。权限变更时主动失效相关缓存;关键检索以服务端当前授权列表过滤,不依赖缓存中的旧授权快照。
示范回答:企业或政务文档先分级,明确谁能看哪一库、哪一文档及哪些字段;传输加密、密钥管理、最小权限、访问审计和删除留痕是底线。把外部模型 API、日志和评测样本也算入数据流,防止敏感内容被无意上传或长期留存。我项目里能明确举证的是 JWT、知识库范围过滤和内部 HMAC;更细的行列级权限/全链路加密要作为进一步设计。
追问示范回答:我会逐项区分:当前代码有 Gateway 身份/知识库校验、检索范围过滤及 HMAC;行列级数据权限、模型供应商合规审查和完整审计保留策略,需要按真实部署要求补齐。
示范回答:文档是数据,不是系统指令。即使写着“请调用外部接口发送全部资料”,Agent 也不能据此获得工具权限。工具由服务端白名单提供,参数和目标资源再次校验;敏感操作做只读限制或人工审批。把文档注入样本加入回归集,检查是否泄漏内容或改变工作流。
追问示范回答:只读工具仍可能通过查询返回敏感信息,或者把数据写进外部 URL 查询参数、日志和回答中。所以还要限制可查询资源、返回字段、结果大小和出网目标。
示范回答:先把两份证据的文件名、版本、发布日期和适用范围列出来。如果一份是旧版、一份是新版,要依据用户问题选适用版本;若无法判定权威性,就在回答里明确“来源 A 说……,来源 B 说……”,不合并成确定结论。必要时把问题交给资料维护者确认,并记录冲突样本用于后续评测。
追问示范回答:检索排序可加入版本生效时间、官方发布状态、文档类型和维护部门等元数据,但不能只靠日期覆盖业务规则;权威性规则由业务方定义,并在答案中保留原始来源。
示范回答:在授权资料中确实没有证据时,应说“目前可访问的资料不足以确认”,指出缺少的是哪一项信息;可建议用户补充文件或联系维护者。不要根据常识编一个似是而非的答案。评测时同时统计正确拒答和错误拒答,避免模型因为怕出错而一律拒答。
追问示范回答:评测集分为可回答与不可回答两类;前者看是否找到了正确证据并给出答案,后者看是否没有编造。把“有证据却拒答”的比例单独统计,并分析是检索漏召还是证据判断过严。
示范回答:我会用同一批问题对比单轮 RAG 和多步 Agent,特别分开看简单事实题与多跳、指代、冲突题。指标包括答案正确率、来源支持率、越权率、p95 延迟、token/工具调用成本和失败率。若只在复杂题有明显收益,就先做问题路由,让简单题走单轮,避免所有请求都付多步成本。
追问示范回答:收益小但成本翻倍时,我会缩小 Agent 触发范围、减少候选数和最大轮次,优化重写与检索缓存;若质量优势仍不足以覆盖延迟和费用,就回退到单轮方案。
示范回答:离线用覆盖事实、精确编号、无答案、越权、多轮和注入的标注集回归;线上记录每节点耗时、检索命中、回退、错误、引用来源与用户反馈,敏感内容脱敏。用户点踩后先定位是解析、召回、证据判断还是生成问题,再把典型样本加入离线集,下一版验证不能只修单一问题。
追问示范回答:离线通过、线上点踩,先看线上问题分布是否超出评测集、文档版本是否变化、用户权限是否不同、模型或配置是否灰度变更;拿该请求的链路 trace 复盘。
示范回答:模型超时、非法 JSON 或空检索计划都不能让图无限重试。每个节点设置超时、有限重试和解析校验;失败时走保守分支,若已有可靠证据可返回来源和“不确定”,否则明确服务暂不可用。deadline、iterations 和最大步数在项目中就是限制循环的机制;需要监控止损原因和失败率。
追问示范回答:调用只读检索重试通常较安全,但若未来工具会写入数据,网络超时后无法知道写入是否成功,盲重试可能重复操作。写工具必须有幂等键、状态查询或人工确认。
示范回答:对每个请求设置最大检索轮数、总耗时、token 上限、候选文档数和工具调用数,并按用户做限额。问题进入系统时先判断是否简单事实题,简单题走一次检索生成;多跳或证据不足时才走 Agent。线上按场景监控成本分布,不能只看平均值。
追问示范回答:按用户/组织做令牌桶或日预算,复杂请求单独限制并发;超过预算时给出可解释的降级回答或排队提示,防止一个用户把模型和向量服务耗尽。
示范回答:审计一次回答至少要能还原:请求 ID、时间、用户及当时授权版本、问题与改写、模型/prompt 版本、每个节点的决策与耗时、检索到的文档版本/页码/chunk ID、最终引用和错误。敏感内容要脱敏、限制访问和保留期。项目已有部分节点耗时与来源元数据,完整审计仍需按合规要求补齐。
追问示范回答:旧回答复现需要保存当时文档版本、索引/Embedding 版本、模型/prompt 参数和权限快照;不能只用当前最新文档重新检索,否则得到的是新结果而不是当时的依据。
示范回答:我会把模型调用抽象成可替换接口,评估国产模型的工具调用、结构化输出、上下文长度与流式能力;Embedding 一旦更换要重建向量索引。部署上核算 GPU、并发、缓存、日志和隔离,使用私有数据做质量/延迟/越权回归。用户授权仍由服务端控制,不随模型替换而改变。
追问示范回答:若质量下降,先分任务类型定位是改写、规划、证据判断还是生成弱;调 prompt、结构化输出约束和检索策略后重测。若仍不能达到旧标准,应与业务方明确新的可接受指标和人工兜底,而不是私自放宽验收。
示范回答:我不会让模型直接拼 SQL 连接生产库。服务端提供固定的只读查询能力,限定表、字段、过滤条件和最大返回行数,参数化查询并做用户行列级权限;每次工具调用记录审计与超时。对外回答再做脱敏和小样本聚合限制,避免模型根据少量数据反推出个人信息。
追问示范回答:即使返回平均值或计数,若过滤后只有一两个人,也可能推断个人信息。可设置最小样本阈值、分组粒度限制和查询频率/差分比较限制,低于阈值不返回具体统计。
示范回答:我会选“混合检索质量与延迟”的真实取舍来讲:只用向量链路更简单、快,但精确编号可能漏召;加入 BM25 和 RRF 后提高精确词覆盖,同时增加索引维护和请求耗时。我们把两路并发执行并设 BM25 失败回退,保证基本可用;我会用固定样本和链路耗时而不是主观感受决定是否保留。没有真实测量值时不报提升百分比。
追问示范回答:如果重做,我会先建立更完整的离线评测集和线上回退率监控,再调整候选数与 RRF 参数;并补强索引更新、文档版本和权限变化时的缓存失效测试。
牛博斐简历.pdf(项目职责与技术栈)。D:\java\RAG_qa_system、D:\WangMiao\sky-take-out、E:\xinghaizhiban\ai-xhzb;代码存在只证明仓库内容,个人贡献以你的实际工作为准。