淘天 AI应用开发一面

1. 做一下自我介绍

2. RAG 分块策略应该怎么选，真正影响效果的核心因素是什么

分块策略不是越细越好，也不是统一按 token 长度切就行。真正影响效果的是 chunk 是否保留了完整语义单元、是否带有足够的定位信息、是否能在召回后被模型直接利用。像制度文档、规则文档、FAQ、表格和多层级说明，最佳切法差异很大。比较稳的方式通常是结构优先、语义补充、长度兜底，也就是先尊重标题、段落、表格、列表，再在超长片段内部做语义切分。这样做的目标不是生成整齐块，而是让每个 chunk 自带最小可回答上下文。

3. 怎么评估 RAG 的效果，除了准确率还能看什么

RAG 效果不能只看最终回答对不对，因为那样很难归因。一般要拆成召回层、重排层和生成层分别评估。召回层看 recall@k、命中覆盖率、是否把关键证据找回来；重排层看关键 chunk 是否能稳定进入前几位；生成层则看引用准确率、幻觉率、答案完整性和用户采纳率。线上还要关注延迟、token 成本、缓存命中率和 bad case 类型分布，不然系统可能答得准，但慢得不可用，或者成本高得不可持续。

4. 开发 RAG 系统时你遇到过最难处理的问题是什么

最难的问题通常不是 embedding 选型，而是知识源本身不干净。比如同一个规则有多个版本、历史文档互相冲突、标题命名不统一、表格和正文语义断裂，这种情况下召回出来的东西看起来都相关，但模型很容易拼出一个貌似合理却不可靠的答案。后面一般要补版本治理、文档标准化、引用约束和冲突检测，而不是继续盲调 topK 或 prompt。RAG 系统做深了之后，核心问题经常会从“模型够不够强”转成“知识底座是否可治理”。

5. MySQL 的索引为什么普遍用 B+ 树，而不是跳表、红黑树或者哈希结构

数据库索引选 B+ 树，本质上是磁盘和页访问模型决定的。红黑树虽然查找复杂度也是对数级，但树高更高，磁盘随机 IO 会明显更多；哈希适合等值查询，却不适合范围查询和排序；跳表虽然在内存里表现不错，但在数据库页组织和磁盘预读模型下没有 B+ 树稳定。B+ 树的优势在于非叶子节点只存键和指针，单页能容纳更多分支，树高更低，叶子节点还天然有序，范围扫描和顺序读都更友好。数据库索引设计真正看重的是综合访问成本，而不是某个理论查找复杂度。

6. 操作系统里的堆和栈如果放到工程问题里理解，最值得讲的点是什么

最值得讲的不是“栈向下增长、堆向上增长”这类概念，而是它们背后的分配模型和性能语义。栈由编译器和调用约定管理，分配释放都很快，适合短生命周期、大小相对确定的数据；堆更灵活，但需要显式或隐式管理，容易带来碎片、逃逸、GC 压力或锁竞争。真实系统里很多性能问题和内存问题，本质上都能追到对象分配方式，比如频繁创建大对象导致 GC 抖动，或者线程栈过大导致进程能开的线程数受限。理解堆栈的关键是它如何影响时延、并发和资源边界。

7. 常见排序算法如果不想答成背诵题，应该怎么讲

排序算法更适合从稳定性、最坏复杂度、空间复杂度和适用场景来讲。比如快排平均快但最坏会退化，不稳定，适合一般内存排序；归并稳定，适合链表和外部排序，但需要额外空间；堆排最坏复杂度稳定，但缓存局部性差，常数也不小；插入排序在近乎有序的小数据集上反而很好用。面试里真正能拉开差距的是你知道这些算法为什么在工程里会被组合使用，比如 Java 和 C++ 标准库为什么不会只押宝一种排序。

8. HashMap 的底层实现原理如果往深了问，你会怎么回答

HashMap 的核心不只是数组加链表或红黑树，而是如何在时间、空间和冲突概率之间做平衡。put 时先通过 hash 扰动减少高位信息浪费，再定位桶位；桶内冲突少时用链表，冲突严重且达到阈值时树化，避免极端退化；扩容时通过容量翻倍和位运算优化重定位，减少重新计算成本。真正值得讲的是为什么容量最好是 2 的幂、为什么树化前还有最小容量限制、为什么高并发下不能直接拿 HashMap 共享用。这些点比“数组链表红黑树”更像真正理解底层。

int index = (n - 1) & hash;

9. 做多智能体项目的背景一般是什么，为什么很多系统最后还是回到单 Agent 加工具

多智能体通常出现在任务天然可分工的场景，比如规划、检索、执行、审计是不同职责，而且每一步都需要不同的上下文和约束。它的价值在于把复杂任务拆成可观测、可验证的子流程，而不是让一个 Agent 在长链路里自由发挥。但很多系统最后回到单 Agent 加工具，是因为多智能体会显著增加上下文传递成本、状态管理复杂度和调试难度。如果任务本身并没有明确角色边界，多智能体反而只是把一个问题拆成多个不稳定问题。

10. AI Coding 里让你写一个 Skill 来解决业务需求，你会怎么设计

Skill 本质上不是一段 prompt，而是一个带能力边界、输入输出协议和失败语义的执行单元。设计时我通常先收窄职责，只做一件可验证的事，比如“生成接口测试样例”或者“扫描仓库里某类风险调用”。然后定义严格的输入 schema、结果格式、超时策略、错误码和回滚方式，最后再决定内部要不要调用模型、规则引擎或代码检索。这样 Skill 才能接到真实工作流里，而不是停留在一次性问答。

{
  "name": "generate_api_testcases",
  "input": {
    "apiSpec": "OpenAPI内容",
    "riskLevel": "high"
  },
  "output": {
    "cases": []
  }
}

11. 一个 Skill 写完之后，通常应该怎么优化，而不是只改 prompt

优化 Skill 不能只盯 prompt wording，更关键的是把不稳定来源拆开。先看输入是不是太宽，是否需要做预处理和参数标准化；再看是否有可规则化的部分，能用规则就不要全交给模型；然后看输出是否可校验，能不能加 schema 校验、引用检查、静态规则或回归测试。很多 Skill 表现不稳定，本质上是职责过大、上下文污染或输出缺乏约束，不是模型“今天状态不好”。

12. 如果让你聊一下 base 地以及开发方向选择，你会怎么回答得更像工程师

这个问题不适合答成“哪里都可以”。更合理的讲法是把地点选择和业务密度、技术复杂度、成长曲线联系起来。如果某个 base 的业务更贴近核心链路、技术治理更重、系统复杂度更高，那对后端和 AI 应用落地都会更有锻炼价值。开发方向上，我更倾向于能同时接触系统基础设施和应用落地的岗位，因为只做上层编排会缺底层稳定性视角，只做底层又容易离真实业务效果太远。这样回答会显得你是在考虑成长路径，而不是随意投递。