面试模拟题（必练）

面试模拟题（必练）

核心原理深度追问（基础分层题，筛掉只背八股的人）

1. 面试官：都说 Transformer 是大模型的核心，它的注意力机制到底解决了什么问题？和传统 RNN 比核心优势是什么？

候选人回答：

注意力机制本质是让模型处理每个词时，能动态给上下文相关信息分配权重，精准捕捉语义关联🧠

• RNN 核心痛点：串行计算，长文本容易出现梯度消失、遗忘前文，并行能力差，训练速度跟不上大模型的规模化需求；
• Transformer 核心优势：
  • 1.并行计算：整句文本同时处理，训练效率指数级提升，是大模型能堆参数量、训海量数据的基础；
  • 2.长距离依赖：自注意力直接建立任意两个词的关联，不会随距离衰减，长文档理解能力远超 RNN；
  • 3.可扩展性强：通过堆叠注意力层 + 前馈网络就能扩容，模型规模越大效果越好，完美匹配大模型的 scaling 规律。

💼 面试官点评：

• 及格：说出并行计算、长距离依赖两个核心点；
• 加分：能区分自注意力与循环神经网络的计算逻辑差异；
• 优秀：能结合训练成本、工程落地，讲清为什么 Transformer 能支撑大模型规模化。

2. 面试官：经常说的 Token 到底是什么？Java 调用大模型接口时，怎么提前估算 Token 数避免超窗口？

候选人回答：

Token 是大模型处理文本的最小单位，既不是单个字也不是完整词，是分词算法拆分后的语义片段💡

• 换算比例：中文约 1 个 Token 对应 1.5~2 个汉字，英文约 1 个 Token 对应 3~4 个字母；
• Java 工程里的估算方案：
  • 1.粗算兜底：非严格场景按「中文字符数 / 1.8」快速估算，做前置校验；
  • 2.精准计算：引入对应模型的分词器 SDK 本地计算（比如 OpenAI 的 tikoken、国内模型的官方分词工具），不用调用接口，性能无损；
  • 3.工程兜底：统一封装层加 Token 数校验，超出阈值自动裁剪历史上下文，避免触发接口报错。

💼 面试官点评：能说出「本地分词器精准计算」的是做过真实项目的；只知道 “字转 Token” 算入门水平。

3. 面试官：Embedding 相似度计算为什么大多用余弦相似度，不用欧氏距离？

候选人回答：

核心是由文本向量的语义表达特性决定的🎯

• 余弦相似度衡量向量方向的重合度，不关心向量绝对长度；文本向量化后，语义相似性只和方向有关，和向量模长无关；
• 欧氏距离衡量绝对空间距离，受向量模长影响大；同一个文本经过不同归一化处理后，模长会变但语义不变，欧氏距离就会出现偏差；
• 工程补充：工业界 Embedding 输出都会先做 L2 归一化，此时余弦相似度和欧氏距离正相关，但余弦计算更高效、语义解释性更强。

RAG 全链路场景难点与优化（项目必问，拉开差距的核心）

1. 面试官：长文档切片是 RAG 的第一步，你们项目里踩过什么坑？怎么优化切片效果？

候选人回答：

我们做企业内部知识库 RAG 时，切片是第一个大坑，初期固定长度切片的召回准确率只有 60% 左右⚠️

核心痛点：

固定长度按字符数硬切，很容易把完整知识点、段落切成两半，上下文语义断裂；检索到的片段信息不全，大模型自然答不对。

我们的分阶段优化方案：

1.基础优化：重叠分片

切片之间保留 10%~20% 的重叠内容，低成本解决边界语义断裂问题，落地后召回率直接提升 15%；

2.进阶优化：语义切片

放弃固定长度，先通过 Apache POI 解析文档结构（标题、段落、列表），按语义边界拆分；Java 侧可配合 HanLP 做分句、语义单元识别，进一步提升切片完整性；

3.高阶优化：父子分层切片

父分片保存完整大段落，子分片是细分的小片段；检索时召回子分片，再挂载对应完整父分片传给大模型，兼顾召回精度和上下文完整性。

切片方案	实现难度	召回准确率	适用场景
固定长度切片	极低	50%~60%	快速验证、简单短文档
重叠分片	低	65%~75%	大多数通用业务场景
语义切片	中	75%~85%	结构化文档、专业知识库
父子分层切片	高	85%+	长文档、政策 / 技术手册类场景

💼 面试官点评：能说出「语义断裂」这个核心痛点就超过一半候选人；能讲出分层切片、量化优化效果的，说明有真实项目落地经验。

2. 面试官：RAG 经常 “答非所问、召回不准”，有哪些全链路优化手段？

候选人回答：

RAG 效果优化是系统工程，不能只调检索环节，我们是从「查询 - 检索 - 排序 - 生成」全链路做优化的🏗️

核心优化点（按性价比排序）：

1. 加重排（Rerank）：向量库粗召回 Top20 片段，用轻量 Rerank 模型做精细语义排序，选 Top5 传给大模型，准确率提升最明显，是性价比最高的优化；
2. 混合检索：ES 关键词检索 + 向量库语义检索两路合并召回，解决 “字面匹配强、语义匹配弱” 的互补问题；
3. 查询侧改写：多轮对话先做问题补全（把 “它怎么样” 补成完整问题），复杂问题拆分子问题分别检索，避免歧义导致召回偏差；
4. 生成侧约束：Prompt 强制要求 “仅基于参考资料回答，资料缺失则明确说明无法解答”，同时把 temperature 降到 0.1~0.3，大幅降低幻觉。

我们落地全链路优化后，答案准确率从 70% 提升至 92% 左右。

💼 面试官点评：答出混合检索 + Rerank 算加分；能讲全链路优化、带量化指标的，属于实战派，直接高分。

3. 面试官：多轮对话场景下，RAG 怎么处理上下文？不会每次都只检索当前问题吗？

候选人回答：

多轮对话是业务真实场景，单轮 RAG 直接用肯定不行，我们的处理流程是这样的🔄

核心处理逻辑：

1. 问题补全：调用小模型把带指代的省略句补全为独立完整问题，再去做检索，从源头解决召回偏差；
2. 历史压缩：对话轮次增多后，不把全量历史塞进上下文，用大模型生成对话核心摘要，保留关键信息，大幅节省 Token；
3. 窗口管理：严格控制总 Token 数，超出阈值后优先丢弃最早的对话历史，保证不突破模型窗口上限。

Agent 落地痛点与工程化方案

1. 面试官：AI Agent 听起来很美好，但实际落地经常工具调用出错、参数传错，你们怎么提升可靠性？

候选人回答：

Agent 工具调用的稳定性是落地最大的坎，我们初期调用成功率只有 70%，优化后稳定在 95% 以上⚠️

核心优化手段：

1. 工具描述极致精准：每个工具的功能、入参含义、格式、取值范围都明确标注；Java 生态用 LangChain4j 的@Tool注解，直接在业务方法和参数上加注解，自动生成工具定义，和现有 Service 零侵入复用；
2. 结构化输出强约束：强制大模型用固定 JSON Schema 输出工具调用指令，Java 侧做格式校验，解析失败直接返回错误信息，让大模型纠错重生成；
3. 业务层二次校验：工具执行前，Java 业务层再做一次参数合法性校验，不符合要求直接返回明确报错，引导 Agent 修正，避免脏数据打穿业务；
4. 有限重试机制：调用失败最多重试 2 次，每次把错误信息反馈给大模型修正；超过次数直接终止，走人工兜底，避免无限循环。

2. 面试官：Agent 任务拆解失败、陷入死循环怎么解决？

候选人回答：

完全放开自主规划的 Agent 很容易失控，企业落地我们的方案是「约束为主，兜底为辅」🧩

1. 最大步数硬限制：设置最大执行步数（一般 5 步），超过直接终止返回，从机制上杜绝死循环；
2. 反思校验机制：每执行一步，让大模型判断当前进度是否偏离目标，必要时调整规划路径；
3. 高频任务模板化：主流业务场景不做完全自主规划，预设任务流程模板，Agent 只负责参数填充和简单分支判断，稳定性提升最显著，是企业落地的首选方案；
4. 人工兜底降级：连续失败、复杂度超标的任务，自动流转人工处理，不追求 100% 全自动。

3. 面试官：ReAct 框架的核心逻辑是什么？和普通 Prompt 调用有什么区别？

候选人回答：

ReAct 是 Agent 最经典的实现框架，核心是「思考（Thought）- 行动（Action）- 观察（Observation）」的循环推理模式💡

• 普通大模型调用是一次性输入、一次性输出，没有中间过程，黑盒属性强；
• ReAct 是让大模型分步推理：先思考下一步该做什么、调用什么工具，拿到工具返回的观察结果后，再继续思考推导，直到得出最终答案；
• 优势：复杂任务准确率更高，执行过程可追溯，出问题能定位到哪一步出错；缺点是调用次数多、响应慢、成本更高。

Java 生态 AI 工程化实战（项目经验 + 技术亮点）

1. 面试官：你们 Java 项目里用的什么 AI 开发框架？有什么技术亮点和落地经验？

候选人回答：

我们主用 LangChain4j，新业务逐步切换 Spring AI，都是和 Spring Boot 生态无缝集成的，不用额外引入技术栈🔧

技术亮点 1：注解式工具开发，业务代码零侵入

用 LangChain4j 的@Tool注解，普通 Java 业务方法加注解就能变成 Agent 可调用的工具，不用手动写工具定义，直接复用现有业务 Service，示例代码：

@Tool("根据用户ID查询订单详情，入参userId为用户唯一标识，字符串类型")
public OrderInfo queryOrderByUserId(@P("用户ID") String userId) {
    return orderService.queryOrderByUserId(userId);
}

技术亮点 2：SSE 流式响应，优化用户体验

大模型生成耗时长，我们用 Spring MVC 的 SSE 配合 AI 框架的流式输出，逐字返回结果，用户不用等待全量生成，感知速度提升非常明显；Spring AI 原生支持流式调用，直接返回 Flux 即可。

技术亮点 3：统一模型抽象，多模型无缝切换

框架把大模型能力抽象成统一接口，换模型只改配置，业务代码零改动；方便做多模型降级、成本对比，比如从通义千问切换到豆包，不用动业务逻辑。

💼 面试官点评：能说出注解式工具、流式响应这些具体特性的，说明真的写过代码；只知道 “发 HTTP 请求调大模型” 的属于入门水平。

2. 面试官：大模型接口调用，Java 里怎么做高可用架构？有哪些踩坑经验？

候选人回答：

我们完全按分布式第三方依赖的标准做高可用，同时针对大模型特性做了专项优化，核心架构如下🏗️

核心方案 + 踩坑经验：

1. 统一封装层：所有大模型调用都走统一 SDK，集中处理鉴权、超时、重试、日志、监控，避免业务代码散写 HTTP 调用，这是工程规范的基础；
2. 限流熔断：用 Sentinel 做 QPS 限流和异常熔断，防止大模型故障拖垮业务；踩过的坑：大模型超时时间远长于普通接口，必须单独配置熔断阈值，不能复用通用配置；
3. 模型分层降级：主模型故障时自动切备用模型；同时做模型分层：分类、改写等简单任务用便宜的小模型，复杂问答才用大模型，整体成本能降 40% 以上；
4. 语义缓存：用问题的 Embedding 向量做相似度缓存，不用完全文本匹配，线上缓存命中率可达 30%；踩过的坑：纯文本缓存命中率极低，同义不同表述的问题会重复调用。

3. 面试官：项目里怎么控制大模型调用成本？有什么落地经验？

候选人回答：

大模型按 Token 计费，成本控制是硬指标，我们做了几项优化，单均成本下降了 52%💰

1. 模型路由分层：按任务难度匹配模型，分类、摘要、改写类简单任务用小模型，成本只有大模型的 1/10；复杂推理、多轮问答才用大模型；
2. 上下文极致压缩：系统 Prompt 精简冗余话术，历史对话用摘要代替全量，文档片段只保留核心相关内容；
3. 语义缓存复用：语义相似度超过阈值的问题直接返回缓存结果，避免重复调用；
4. 成本监控告警：统一封装层统计每个业务场景的 Token 消耗，做成本分摊和异常告警，防止异常流量刷爆费用。

企业级 AI 系统架构设计（拔高题・项目经验总结）

面试官：设计一个企业级智能知识库问答系统，整体架构怎么设计？有哪些技术难点和亮点？

候选人回答：

我会按「接入层 - 业务层 - 能力层 - 数据层」四层设计，兼顾效果、稳定性、成本和可运维性，这也是我们落地项目的核心架构🏗️

核心设计亮点：

1. 意图前置路由：先做轻量级意图识别，知识库问答走 RAG 链路，查数据走 Agent 工具调用，闲聊走小模型，不同场景匹配最优模型和链路，兼顾效果与成本；
2. 知识库自动化运营：对接企业文档系统，文档新增 / 修改自动触发解析、切片、向量化，同步更新向量库，无需人工干预，运营成本极低；
3. 全链路可观测：每个请求的 Token 消耗、耗时、召回片段、生成答案全链路落日志，配置效果大盘，实时监控回答准确率、幻觉率、转人工率。

核心难点攻克：

1. 解决长文档语义断裂问题，用语义切片 + 父子分片方案，召回准确率提升 30%；
2. 解决大模型调用成本高的问题，通过模型分层 + 语义缓存，单问答平均成本下降 52%；
3. 解决多轮对话答非所问问题，通过问题补全 + 上下文管理，多轮场景回答准确率提升 25%。

📌 面试项目话术小贴士

讲 AI 项目经验时，按「背景 - 难点 - 方案 - 结果」STAR 法则展开，重点突出：

• 你负责的核心模块

• 遇到的具体技术难点

• 基于 Java 技术栈的解决方案

• 最终可量化的效果指标

• 不要只说 “我做了个 RAG 系统”，细节和数据才是加分项

真实面试模拟

真实面试模拟

面试官 👨‍💻：

同学你好，先放轻松。看你简历写了有 AI 相关项目，那咱们就从基础原理到工程落地都聊一聊。第一个问题：你平时用 Java 做 AI 相关开发，主要接触过哪些框架或库？和 Python 生态比，Java 这边你觉得优势和短板在哪儿？

候选人 👦：

面试官好。我主要用过 Deep Java Library (DJL)、Tribuo 和 ONNX Runtime Java 绑定。

• DJL 是 AWS 开源的，很贴近 Python 习惯，模型加载和推理代码很简洁，而且底层能自动切换 PyTorch、TensorFlow 引擎。
• Tribuo 是 Oracle 维护的机器学习库，好处是自带特征工程、模型评估一致性高，适合传统 ML 场景。
• ONNX Runtime 我主要用来部署训练好的模型，尤其是和 Spring Boot 结合做微服务推理。

说到优势短板，我用个表对比一下 🧐：

维度	Java 生态	Python 生态
模型训练	弱势，库少、社区小，通常不在 Java 侧训练	绝对主力，PyTorch / TF / JAX 丰富
推理部署	强项，与微服务、流处理天然集成	需借助 FastAPI / Flask，性能调优繁琐
类型安全	编译期类型检查，大型团队协作更稳妥	动态类型，易出错，需大量测试
算子性能	JIT 优化好，大吞吐场景表现佳	依赖 C++ 底层，Python 侧调度有开销
生态丰富度	模型 zoo、预训练模型要转换才能用	原生模型极多，开箱即用

短板很明显：训练能力弱，模型需要从 Python 侧转换。优势在生产环境的集成度和稳定性上。现在大模型时代，Java 更适合做推理网关、RAG 检索、Agent 调度这些。

面试官 👨‍💻：

很好，对生态认识挺清楚。那我们深入一下原理。Transformer 的核心 Self-Attention 机制，能不能用你理解的方式讲清楚？最好画个简图说明，不要背公式。

候选人 👦：

没问题。我边画个图边说 🤖。

核心思想就三步：

1. 投影：把每个词的 Embedding 分别乘以三个矩阵 W_Q、W_K、W_V，得到 Query、Key、Value 向量。可以类比成：Query 是你“查什么”，Key 是“标签”，Value 是“实际内容”。
2. 计算相关性：对每个 Query，和所有 Key 做点积得到分数，分数越高代表这两个位置越该互相“注意”。然后除以 √d_k 防止方差过大，再做 Softmax 变成概率。
3. 加权聚合：用这些概率做权重，对所有的 Value 加权求和，输出的每个位置都吸收了整个序列的信息，不再局限在局部。

对于编码器，这就是 双向上下文 的来源；对于解码器，会加掩码保证只能看到已生成的部分。这个机制完全不依赖循环，所以能并行训练，也是大模型的基础。

面试官 👨‍💻：

理解到位。那工程上，如果你有个上 GB 的大模型要集成到 Java 微服务里，怎么设计才能保证低延迟和高吞吐？同时兼顾内存占用？

候选人 👦：

这块我非常喜欢用一张图来表达整体架构 💡：

具体落地我会做这么几件事 🛠️：

1. 模型格式转换与优化
   用 Python 导出 ONNX 或 TensorRT 引擎，并做量化（FP16 或 INT8），体积缩小 2-4 倍，推理加速明显。

2. 单例 + 对象池
   模型加载一次，在 Spring 中以单例 Bean 注入。Tokenizer 和推理 Session 用对象池复用，避免重复创建和 GC 抖动。

3. 异步非阻塞
   Controller 用 CompletableFuture 或 WebFlux 响应式，底层推理放到独立线程池（注意绑定 CPU 亲和性），不阻塞 Tomcat 线程。

4. 动态批处理 (Dynamic Batching)
   短时间内攒一波请求，组成 batch 一次推理，GPU 利用率从 30% 拉到 80%+。ONNX Runtime 和 TensorRT 都支持。

5. KV Cache 优化
   大模型自回归推理时，缓存之前的 Key/Value 张量，下一轮只算增量，延迟大幅下降。

6. 内存与限流
   限制最大输入长度和 batch 大小，防止 OOM。配合 Sentinel 做并发限流，保证服务质量。

这套方案在 4 核 16G 机器上跑 7B 量化模型，经过优化单请求延迟能从 5 秒降到 400ms 以内，QPS 达到 20+，生产完全可用。

面试官 👨‍💻：

工程能力不错。但我们再往深了聊：你经手过的 Java AI 项目里，有没有哪个场景让你觉得“选 Java 真是选对了”，或者相反，差点翻车？

候选人 👦：

确实有一个印象深刻的线上推理项目。我们为一个金融客户做实时的财报情感分析微服务，日均调用量 2000 万次，要求 P99 延迟 < 50ms。最初技术选型时团队争论过用 Python 还是 Java，最终 Java 胜出。但在实际落地中，我们踩过两个大坑 📉：

1. ONNX 算子兼容性翻车
   我们用 PyTorch 训练了一个 BERT-tiny，导出 ONNX 后直接拿 onnxruntime-java 加载，结果启动报 Unsupported operator: 'FusedMatMul'。原因是训练侧用了特定版本的 CUDA 融合算子，但 ONNX Runtime 的 Java 包没有包含对应执行提供器。解决方案是重新用 torch.onnx.export(..., opset_version=14, do_constant_folding=True) 并禁用融合。教训：导出前必须锁定 Opset 版本，并在 CI 中加一步 onnx.checker.check_model 自动化校验。

2. 内存泄漏差点搞垮服务
   上线一周后发现内存缓慢上涨，最终触发 OOM Killer。排查发现我们复用了 OrtSession，但每个请求调用 session.run() 时传入了 OnnxTensor 对象，未及时 close()。ONNX Runtime 的 Java 绑定里，Tensor 是堆外内存，GC 无法自动回收，必须显式调用 close() 或使用 try-with-resources。修复后堆外内存稳定在 2.2GB。

这个项目让我深刻体会到：Java 在高并发下配合 ONNX Runtime 确实能获得接近 C++ 的推理速度，但对内存管理的要求远比 Python 严苛。我们用 JMH 压测，单节点 4C8G 最终撑住了 1200 QPS，P99 38ms，客户很满意 👍

对比项	初版 Python 服务 (FastAPI)	优化后 Java 服务 (Spring Boot)
QPS (4C8G)	230	1200
P99 延迟	210ms	38ms
内存占用	1.8GB	2.2GB（堆外可控）
上线故障次数	3 次 OOM	0

面试官 👨‍💻：

实打实的生产经验，不错。那我们往底层挖一下：你提到用 KV Cache 优化自回归推理，能具体讲一下 Java 侧怎么实现 KV Cache 的吗？这个 Cache 放在堆内还是堆外？为什么？

候选人 👦：

这个优化非常关键，尤其对于 Chat 场景的流式输出。KV Cache 的原理大家都清楚：解码阶段每个 token 只计算增量，历史 token 的 Key/Value 矩阵直接复用，避免重复计算。

在 Java 实现上，我们并没有自己从零写矩阵运算，而是充分利用 ONNX Runtime 的特性。模型本身需要导出成 带 past-state 输入输出 的格式。具体步骤：

1. 导出模型时将 use_cache=True 固定，使模型接受 past_key_values 作为输入，并输出新的 present_key_values。
2. 在 Java 推理循环中，维护一个 Map<String, OnnxTensor> 作为 KV 状态缓存。Key 是层名（如 past_key_0），Value 是该层的 Key/Value 张量。

内存放置决策：必须用堆外内存 (Direct Memory)。原因有两点：

• 性能：ONNX Runtime 内部是 C++ 推理引擎，张量数据在原生内存中。如果放在堆内（Java Heap），每次推理都要将数据从堆内拷贝到堆外，引入大量额外延迟和 GC 压力。
• 大小可控：一个 7B 模型，FP16 精度，单层 KV Cache 约 2MB，32 层共 64MB。堆外分配可避免触发堆内存膨胀和频繁 GC。

我们用 OrtEnvironment 的 createTensor 方法，指定 OrtMemoryInfo 为 DataLocation.DEVICE（或 CPU 的 pinned memory），完全绕开 JVM 堆。推理伪代码如下：

Map<String, OnnxTensor> kvCache = new HashMap<>();
for (int i = 0; i < maxTokens; i++) {
    // 将 kvCache 作为输入的一部分传入
    inputs.putAll(kvCache);
    OrtSession.Result result = session.run(inputs);
    // 从输出中提取新的 present KV，更新缓存
    for (int layer = 0; layer < numLayers; layer++) {
        kvCache.put("present_key_" + layer, result.get("present_key_" + layer));
        kvCache.put("present_value_" + layer, result.get("present_value_" + layer));
        // 旧张量必须手动 close 释放堆外内存
        inputs.remove("past_key_" + layer).close();
    }
}

难点：张量生命周期的管理很棘手，一旦忘记 close()，64MB 的堆外内存泄露几分钟就能撑爆服务。我们封装了一个 KVCacheManager，使用 PhantomReference 结合 Cleaner 做兜底释放，并在关闭 session 时统一清理。

优化后，首 token 延迟从 3.2s 降到 1.8s，后续 token 平均延迟从 800ms 降到 120ms，效果显著 📈

面试官 👨‍💻：

对内存和生命周期理解很深。再问一个架构设计题：如果让你用 Java 设计一个支持多模型 A/B 实验的推理网关，你会怎么做？重点在路由、灰度、以及模型热切换。

候选人 👦：

这个场景很典型。我会基于 Spring Cloud 生态，结合动态配置和流量染色来实现。画个架构图一目了然：

核心设计要点 🛠️：

1.动态路由规则

不硬编码模型选择，而是从 Apollo 配置中心读取路由策略，支持按 userId 哈希、流量百分比、Header 标记等切流。例如配置：

route:
  model_v2: 
    weight: 10         # 10%流量
    whitelist: [1,2]   # 指定用户id

2.模型实例发现与负载均衡

每个模型实例启动时注册到 Nacos，标记元数据 model=finbert_v2。Router 通过 Spring Cloud LoadBalancer 自动发现并负载均衡。这样新模型实例上线无需改网关配置。

3.热切换与优雅下线

这是最棘手的点。模型对象通常占用几个 GB 内存，不能简单 new 一个替换旧的，否则内存瞬间爆掉。我们采用 预热 + 逐步引流 策略：

• 新模型实例启动后，先向 Nacos 注册一个 preheating:true 的临时元数据，Router 不会给它分配正式流量。
• 通过一个 /preheat 端点发送少量模拟请求，让 JIT 编译和模型缓存预热。
• 预热完成后修改元数据为 preheating:false，Router 动态感知并开始分配流量。
• 同时，通过 Apollo 开关逐步增加新模型流量权重，观察错误率和延迟指标，无异常则下线旧实例。

4.流量染色与效果对比

请求头注入 x-model-version，在整个链路中透传，最终在监控里用 Prometheus 按版本维度聚合延迟、错误率、业务指标（如情感分类准确率，可通过用户反馈回传）。这样数据驱动 A/B 实验决策。

5.兜底与熔断

通过 Resilience4j 做熔断，新模型实例错误率超过阈值自动切流回旧模型，保障业务无损。

这个网关我们实际落地后，模型切换对业务完全透明，故障恢复时间从 10 分钟级降到 30 秒以内。

面试官 👨‍💻：

非常完整的方案。最后问一个偏 RAG 进阶的：在 RAG 系统中，文档切分 (chunking) 看似简单，实则影响重大。你有哪些切分策略？遇到过什么切分导致的 Bad Case？

候选人 👦：

切分是 RAG 的水龙头，一旦切不好，后续检索和生成都是徒劳。我经历过一个典型案例：客户的知识库是产品说明书，含有大量表格。最初使用固定 512 token 切分，结果表格被拦腰切断，检索到碎片化信息后，LLM 生成的回答张冠李戴，电压值对应到了错误型号，导致一次严重线上事故 😱。

后来我们沉淀了一套自适应切分策略，针对不同内容选用不同方案：

具体技术亮点 ⭐：

• 语义分割：计算相邻句子的 embedding 余弦相似度，当相似度骤降（低于阈值 0.5）时断开。这个方法比固定长度更能保持语义块完整。我们使用 DJL 加载一个轻量的 all-MiniLM-L6-v2 模型在 Java 侧实时计算，避免调用外部 API 的延迟。
• 表格特殊处理：在 Apache Tika 解析时，自定义 ContentHandler 拦截 table 标签，将其转换为 Markdown 表格格式并作为一个整体 chunk。同时，自动提取表头，在每个 chunk 前拼接“该表格描述的是...，表头为...”，增强检索精准度。
• 父子文档模式：对于长文，我们还会采用“小 chunk 检索、大 chunk 生成”的策略。检索时用 200 token 的子块匹配，返回其父块（包含完整段落，500 token）送给 LLM，平衡了检索精度和上下文完整度。

经过切分优化后，表格问答的正确率从 62% 提升到 93%，用户投诉率归零。同时 chunk 总量减少了 20%，检索速度反而更快。

面试官 👨‍💻：

从切分细节到整体架构，再到底层内存管理，回答都非常扎实，明显是经历过实战打磨的。我今天没有更多问题了，感谢你的时间，后续流程 HR 会同步。

候选人 👦：

谢谢面试官，整个过程也让我梳理了很多细节，受益匪浅！🙌