系统与工程
系统与工程
架构、性能、故障、质量、安全和发布。
060 · 中 · Streaming 流式输出是怎么实现的？
来源：ai-agent-interview-guide
链路是：模型 SSE → 后端异步生成器 → 网关 SSE 或 WebSocket → 前端 EventSource。
后端每收到一块就写出 data: {...}\n\n，结束时发 done。Nginx 必须关缓冲（X-Accel-Buffering: no），否则用户还是等完整包。大约每 15 秒一个心跳，避免代理掐连接。中途错误发 error 事件。客户端断开要取消上游模型调用，否则 token 照扣。
ReAct 不能把 Thought 全推给用户。Thought 留在内部，Action 只推「正在查询」，Final Answer 才逐 token 输出。靠解析流来切阶段。源笔记的首 token 从大约 3 秒降到大约 500 毫秒。
061 · 中 · A/B 测试和 Prompt 版本管理是怎么做的？
来源：ai-agent-interview-guide
Prompt 放数据库，带版本、时间和变更说明，可以按流量百分比灰度，不写死在代码里。
分组用用户 ID 的哈希，保证同一个人不会来回跳版本。实验跑满大约 7 天或 1000 段对话再下结论。
指标分三层：自动的 BERTScore、格式遵循、工具准确率；人工抽大约 100 条、多人 1 到 5 分；业务上的满意度、解决率、对话轮次。新版本各项不能差于旧版，核心相关性至少提升约 2%，并且 p < 0.05。
源笔记用这个门槛挡下 3 次「看起来更好、线上更差」的修改。没有对照，Prompt 迭代就是运气。
062 · 中 · Token 成本是怎么控制的？
来源：ai-agent-interview-guide
最大头是路由，不是把 Prompt 抠短几个字。大约 60% 的简单查询走小模型，成本大约是大模型的 1/17；大约 15% 才用大模型。这一项单独大约降 62% 的费用。
其次才是上下文。System Prompt 从大约 1500 token 收到 800。工具描述按本轮需要注入，不要每次带上全部工具，输入大约省 20%。检索从 top 10 收到 rerank 后的 top 5，历史及时摘要，context 大约再少 30%。
语义缓存和高频 FAQ 预计算大约吃掉 15% 的重复调用。输出用 max_tokens 封顶，普通回答约 512，详细回答约 1024。
源笔记月成本从大约 5 万到 1.9 万，满意度大约只掉 1.2%。省 token 的约束是质量指标不能一起掉。
063 · 中 · 延迟优化做了哪些措施？
来源：ai-agent-interview-guide
先拆链路再优化。源笔记初期大致是：意图 300 毫秒，检索串行 500 毫秒，rerank 130 毫秒，生成 4500 毫秒，后处理 100 毫秒。生成是大头。
检索改并行，大约省 300 毫秒。意图和检索同时启动，检索先用原始 query，不等意图结束。简单查询走快模型（大约 800 毫秒对 3000 毫秒）。连接池去掉反复握手，大约 50 毫秒。缓存命中小于 100 毫秒。流式不减少总生成时间，但首 token 大约 500 毫秒，用户感觉的等待变短。
Prompt 变短、限制输出长度、选近的 API 区域，都是在削生成这段。P50 从 6.5 秒到 2.8 秒，P99 从 15 秒到 5.2 秒。
064 · 中 · 缓存策略是什么？命中率多少？
来源：ai-agent-interview-guide
三层，命中条件从严格到宽松。
| 层 | 键 | TTL | 命中 |
|---|---|---|---|
| 精确 | query 的 MD5，Redis | 24 小时 | 约 8% |
| 语义 | query embedding，相似度 > 0.95 | 12 小时 | 约 7% |
| FAQ | Top 200 高频问，意图匹配 | 手动更新 | 约 5% |
合计大约 20%。命中小于 100 毫秒，对照一次模型调用大约 3 秒，API 成本大约省 20%。
失效有两条：TTL 到期；知识库更新时按事件清掉相关问题。启动时预热 FAQ 和高频问。语义阈值不能放太低，否则答非所问会被缓存住。
065 · 中 · 流式输出从性能上看怎么做？
来源：ai-agent-interview-guide
实现链路见技术实现里的流式一题。性能上盯两个数。
TTFT 目标小于 500 毫秒：意图和检索在模型开吐之前完成，第一个 token 通常在 200 到 500 毫秒。源笔记 P50 约 450 毫秒，P99 约 800 毫秒。
TBT 靠模型和「不攒批」。小模型大约 10 毫秒一个 token。后端不要积一批再发。
工具调用插在流中间：发现 Action 就推状态，工具结束再继续推 Final Answer。前端要有加载态，否则用户以为卡死。感知速度大约快 5 倍，总生成时间并没有变成五分之一。
066 · 中 · 冷启动问题是怎么解决的？
来源：ai-agent-interview-guide
新实例慢在三件事：模型没进显存、缓存是空的、连接还没建。
就绪探针等模型加载完再接流量。模型放共享存储，避免每次重新下载。embedding 加 reranker 大约 30 秒。启动时加载 FAQ 和热门问，也可以从健康实例同步；预热完成前跳过缓存直接查，不能让请求失败。数据库和 Redis 连接按最小池先建好，Redis 做一次 PING。负载均衡对新实例渐增加权。
源笔记冷启动从大约 120 秒到 45 秒，期间成功率从约 70% 到约 98%。
067 · 中 · 怎么部署？CI/CD 是什么流程？
来源：ai-agent-interview-guide
合入前：lint、类型检查、单元、集成、AI 评估、安全扫描、镜像。不过就不进主干。CI 目标小于约 15 分钟。
发布：主干到 Staging，冒烟，人工看一眼，再按 10%、50%、100% 金丝雀。每一档观察大约 30 分钟。保留最近大约 5 个镜像，kubectl rollout undo 可以退，灰度期异常自动退。环境是 Dev、Staging、Production，Helm 管部署，配置进 ConfigMap，密钥进 Secret。
源笔记从月发改成周发，大约 2% 的版本在灰度被退回，回滚小于约 3 分钟。AI 评估不进 CI，Prompt 改动会和普通发布一样直接全量。
068 · 中 · 安全性怎么保证？Prompt 注入怎么办？
来源：ai-agent-interview-guide
架构上的四层防护见架构设计里的安全一题。工程上要把它变成会过期的规则，而不是上线检查单。
维护大约 500 条以上的注入样本，发版前跑，每季度做一次红蓝对抗。跟踪 OWASP LLM Top 10 和社区里的新绕过，新模式大约 48 小时内补规则。紧急规则走配置热更新，大约 10 分钟能生效，不等发版。
编码约定：用户输入不信任；系统指令和用户内容用不同的 message role；工具参数做白名单，不把模型输出直接拼进 SQL 或 shell。源笔记称没有成功的注入，规则更新平均小于约 4 小时。这个结论依赖样本库是否还在更新。
069 · 中 · 在RM训练阶段，我们通常收集的是成对比较数据，而不是让人类标注者直接给回复打一个绝对分数。你认为这样做的主要优势和潜在的劣势分别是什么？
来源：Hello-Agents Extra01
在训练奖励模型（RM）时，采用成对比较（Pairwise Comparison）而非绝对评分（Absolute Scoring）是业界的标准做法，这背后有深刻的认知科学和实践考量。
主要优势：
- 降低认知负荷，提升标注一致性： 让人在多个选项中选出“哪个更好”远比给一个选项打一个精确的绝对分数（如1到10分）要容易和直观。不同标注者对于“7分”的定义可能天差地别，但对于“A比B更好”的判断则更容易达成共识，这大大提升了数据的标注者间一致性（Inter-rater agreement）。
- 提供更精细的信号： 比较数据能够捕捉到细微的偏好差异。两个回答可能在绝对分数上都是“好”的（比如都是8分），但比较数据可以明确指出其中一个比另一个“稍微好一点”，这种相对信号对于模型学习更精细的偏好至关重要。
- 数据分布归一化： 绝对分数很容易受到标注者个人情绪、打分尺度、疲劳度等因素影响，导致分数分布不均或存在偏差。而比较数据天然地将问题转化为一个标准化的二元分类或排序任务，模型只需要学习相对关系，对绝对尺度不敏感。
潜在的劣势：
- 数据效率可能较低： 每次比较只产生1比特的信息（A>B或B>A）。如果要对K个回答进行完整排序，需要进行 $O(K^2)$ 次比较，而绝对评分只需要K次。这意味着要达到同等的信息量，可能需要更多的标注工作。
- 可能出现不传递性（Intransitivity）： 人类偏好有时不满足传递性，即可能出现“A比B好，B比C好，但C比A好”的循环偏好。这会给奖励模型带来噪声和矛盾的训练信号。
- 信息不完整： 比较数据只告诉我们相对好坏，但没有说明“好多少”或“差多少”。两个回答的差距可能微乎其微，也可能天差地别，但成对比较无法直接体现这种差异的幅度。
070 · 中 · 系统的可扩展性是怎么设计的？
来源：ai-agent-interview-guide
边际成本靠接口和配置，不靠改主循环。
工具是插件：name、description、parameters_schema、execute。描述直接变成 Function Calling 的 schema，注册表自动收集。
检索管道用配置声明引擎、top_k 和权重，后面接 reranker（源笔记用 bge-reranker-v2-m3，再收到 top 5）。新通道实现引擎接口再加一段配置。
模型走统一 LLMProvider，换 OpenAI、Anthropic 或本地模型只改配置。主流程用事件总线，旁路功能监听事件，不插进主干。
源笔记的接入成本：新工具约 2 小时，新检索通道约半天，换模型改配置。六个月加了 8 个工具和 3 个通道，核心代码不动。
071 · 难 · 如果让你重新设计这个系统，你会怎么改进？
来源：ai-agent-interview-guide
这题考的是事后哪几处返工最贵，不是再讲一遍架构。
- 评估从第一天进 CI。 手动点验挡不住回归。用 RAGAS、DeepEval，每次提交跑固定评估集（源笔记是 500 条以上）。
- 可观测性和第一行代码一起上。 后补的日志 trace 不完整。LangSmith 或 LangFuse 给每个 Agent 步骤一个 span。
- 默认流式。 先做同步再改 SSE / WebSocket，改造成本高。
- 路由按任务切，不按简单/复杂两档。 分类、生成、推理、摘要，再加上输入长度和质量要求。
- 记忆分层。 窗口截断不够。工作记忆、情景记忆、语义记忆分开，要能索引和召回。
072 · 中 · 为什么要做模型路由？直接用一个模型不行吗？
来源：ai-agent-interview-guide
一个模型要么贵，要么不够。查询分布不均匀：大约 60% 是 FAQ 和事实检索，25% 要多步推理，15% 要强推理和长指令。
路由看四件事：任务复杂度、上下文长度、质量要求、用户等级。轻量模型做问答、分类、抽实体；标准模型做 RAG 生成和中等推理；强模型做长文和关键决策。分类器本身用规则加 FastText，延迟小于 3 毫秒。强模型超时就降到标准模型。
源笔记的账：月成本降约 62%，满意度只掉约 1.2%，整体延迟降约 35%，因为小模型更快。路由的风险是分错档，所以要有降级，并且用满意度盯质量，不能只看账单。
073 · 中 · 怎么设计对话管理和上下文维护？
来源：ai-agent-interview-guide
上下文分成四层，预算分开算，避免历史把检索挤掉。
- 系统层：角色和行为，大约 800 token，固定。
- 会话层：最近若干轮原文，更早的压成摘要。摘要留意图、已做的决定、还没解决的问题。
- 检索层：按相关性放进 RAG 片段。
- 工具层：调用结果用完就清，不进长期历史。
以 8K 窗口为例：系统 10%，历史加摘要 30%，检索 40%，输出预留 20%。最近 10 轮留原文，更早的自动摘要。源笔记称这样能撑大约 50 轮还不丢关键约束，上下文一致性从 76% 到 94%。窗口变大时比例可以改，四层不能并成一锅。
074 · 中 · 系统支持哪些模型？怎么做模型适配？
来源：ai-agent-interview-guide
企业客户要 OpenAI、国产模型和内网模型。业务代码只认一个接口：chat、stream_chat、count_tokens、get_model_info。
适配器盖住差异，不把差异漏到编排器：
- OpenAI / Azure、Claude、通义（兼容 OpenAI 格式）、vLLM / Ollama。
- 工具调用字段不同：OpenAI 的
tools，Claude 的tool_use。 - tokenizer 不同，token 计数必须在各自 Provider 里做。
- SSE 分片格式不同，在 Provider 里收成统一的 token 流。
源笔记支持 6 家，新模型大约一天：实现 Provider 再补测试。切换是改配置。
075 · 中 · 系统的安全架构是怎么设计的？
来源：ai-agent-interview-guide
四层，每层挡住不同的失败。
输入。 限长（源笔记是单次 ≤ 2000 字）、转义、用分类器认「忽略之前的指令」「你现在是」这类注入。系统指令和用户内容分属不同 message，不拼进同一段。
数据。 PII 进模型前打成占位符，出来再按权限还原。知识库按 RBAC 分区。日志同样打码。
输出。 内容审核、低置信度加免责、回答带引用以便核对。
系统。 JWT 加 API Key，每用户每分钟大约 20 次，操作进审计日志。
源笔记用约 1000 个攻击样本，注入拦截率约 97%。安全架构的面试点是分层和「模型不可信」，不是背一份产品清单。
076 · 难 · 系统支持多租户吗？怎么实现的？
来源：ai-agent-interview-guide
隔离要落在数据、配置和配额三处，只加一个 tenant_id 字段不够。
知识库用独立 Collection。源笔记的经验是数据一大，分区过滤不如独立 Collection。对话放独立 schema。Redis key 用 tenant_id: 前缀。
每个租户可以热更新自己的 System Prompt、工具集、模型和检索策略，不用重启。配额用 Redis 令牌桶：独立 QPS 和 token 预算，超出返回 429。一个租户打满不应该占住别人的连接和模型额度。
077 · 中 · 熔断器是怎么实现的？三个状态是什么？
来源：ai-agent-interview-guide
熔断是为了在下游抖动时快速失败，而不是把超时重试打满。
| 状态 | 行为 |
|---|---|
| CLOSED | 请求通过，用滑动窗口记失败率 |
| OPEN | 不再打下游，直接走降级 |
| HALF_OPEN | 放少量探测，看下游是否恢复 |
转换：最近 60 秒失败率超过 50%，且至少 10 次请求，CLOSED 到 OPEN。熔断 30 秒后进 HALF_OPEN。连续 3 次探测成功回到 CLOSED；任意一次失败重新 OPEN。
打开时优先返回缓存，否则切备用模型，再不行返回明确的繁忙话术。源笔记里下游故障时，响应从等满 30 秒超时变成大约 100 毫秒失败，恢复后 30 秒内自动闭合。
078 · 中 · 会话摘要压缩的阈值是多少？怎么确定的？
来源：ai-agent-interview-guide
触发点是对话历史占窗口约 40%。8K 窗口就是大约 3200 token。最近 3 轮永远留原文。
三个阈值对比过：30% 压得太勤，回答质量掉约 8 个点；50% 在 15 轮以后容易顶满窗口；40% 是保留和成本的交点。
摘要 Prompt 只要求留下四样：核心诉求、已确认的关键字段（订单号、姓名）、已完成的操作、待解决问题。大约 3000 token 压到 500–800，大约 4:1 到 6:1。
不要一次压完全部历史。每次只压最旧的 3 到 5 轮，新摘要和旧摘要合并。源笔记在这个阈值下大约能到 50 轮，摘要后理解准确率约 91%，对照完整历史约 96%，长对话 token 大约省 60%。
079 · 中 · Guardrails 是怎么实现的？
来源：ai-agent-interview-guide
输入侧和输出侧各一条管道，任一条失败就停，不要等全部跑完。
输入：注入检测、PII 正则、长度上限、业务话题过滤。输出：JSON Schema 或格式检查、内容审核、引用是否真的在检索结果里、陈述能否从 context 推出来。
每条护栏同一接口：check(content, context) → passed / reason。管道按顺序跑，失败即返回。扩展是加一条护栏，不是在生成 Prompt 里再写一段「请注意安全」。
源笔记的注入拦截约 97%，输出合规约 99.8%，幻觉检测覆盖约 85%，最后这项明确还有缺口。
080 · 中 · 日志和链路追踪是怎么做的？
来源：ai-agent-interview-guide
日志按用途分级：INFO 记状态转换，DEBUG 记 Prompt、检索和工具参数，WARN 记降级、重试和低置信度，ERROR 记超时和失败。
一条日志是结构化字段：trace_id、span_id、服务、事件、工具名、延迟、状态。不要只打一行自然语言。
OpenTelemetry 给每个请求一个 trace。意图、检索（下面再分向量和关键词）、rerank、生成、格式化各是一个 span。收集走 Fluentd 到 Elasticsearch，链路看 Jaeger。告警例子：P99 大于 10 秒、错误率大于 1%、幻觉率大于 5%。
源笔记把定位从大约 2 小时收到大约 15 分钟。没有 trace，延迟优化只能猜。
081 · 中 · 异步并行是怎么做的？
来源：ai-agent-interview-guide
I/O 全部 async：FastAPI、httpx，不用同步 HTTP 客户端占住事件循环。
能并行的是互不依赖的调用。三路检索用 asyncio.gather。多个没有先后关系的工具同样并行。有依赖的步骤不能并。
并发要封顶：LLM 调用信号量大约 50，数据库连接池大约 20。文档索引、日志分析这类不在请求路径上，放 Celery，别堵实时请求。
源笔记三路检索从串行约 500 毫秒降到并行约 200 毫秒，QPS 大约 2.5 倍，批量入库大约 4 倍。
082 · 中 · Token 计数和费用统计是怎么实现的？
来源：ai-agent-interview-guide
输入在客户端用该模型的 tokenizer 预估：OpenAI 用 tiktoken，Claude 用官方计数，本地用对应 HuggingFace tokenizer。输出以 API 返回的 usage 为准，这是账单数字。
费用按输入价和输出价分开算，单价不同，不能用总 token 乘一个数。统计切到租户、功能（意图、RAG、摘要）、模型和日周月。租户有月预算，大约 80% 提醒，100% 限流或降到小模型。
源笔记计数误差大约 2% 以内。拆开之后发现摘要占了大约 25% 的 token，优化后这块降了大约 40%。不拆维度，就只看得到一张总账单。
083 · 中 · 数据预处理和数据清洗是怎么做的？
来源：ai-agent-interview-guide
管道：格式转换、抽文本、清洗、去重、质量分、分块、入库。检索差的时候先看这条管道，不要先换模型。
清洗去掉页眉页脚、水印和空行，统一 UTF-8 和标点，用语言模型修 OCR（「己术」这类），手机号和身份证打码。
去重三档：MD5 去完全相同；MinHash + LSH，Jaccard 大于约 0.85 当近似重复；同一文档只留最新版本。
质量分看长度、句子是否完整、实体和关键词密度。低于阈值的块不参与检索。源笔记清洗后检索准确率大约加 8 个点，存储少约 15%，幻觉率降约 12 个点。脏块进了索引，rerank 也救不回来。
084 · 中 · 异步处理用在哪些地方？
来源：ai-agent-interview-guide
三条路径，延迟要求不同。
实时路径全是 async：模型、向量库、Elasticsearch、请求本身。意图识别和检索做成两个 task，一起 gather，再生成。
准实时进队列：对话入库、行为日志、告警。失败可以重试，不挡回答。
离线走 Celery：解析、建索引、图谱更新、历史归档、报表。
源笔记 QPS 从大约 30 到 85。异步解决的是等待重叠，不是把有依赖的步骤硬并行。
085 · 中 · 数据库查询是怎么优化的？
来源：ai-agent-interview-guide
向量库按规模选索引。大约 100 万以下用 HNSW，延迟低；更大用 IVF_SQ8，省内存。HNSW 的一组可用参数是 M=16、efConstruction=200、ef=128。Collection 按租户分开，避免一次过滤扫所有人。
PostgreSQL：组合索引、EXPLAIN ANALYZE、对话表按月分区，连接池大约 min 5、max 20、空闲 300 秒。禁止 N+1 和 SELECT *，重复 SQL 用预编译。
Redis：缓存用 String，会话用 Hash，排行用 Sorted Set。Key 形如 {service}:{tenant}:{type}:{id}。热 key 要打散。
源笔记向量 P99 稳定在 50 毫秒内，慢 SQL 从日均约 200 到约 5，Redis 命中约 95%，读小于 1 毫秒。
086 · 中 · 前端渲染性能怎么优化？
来源：ai-agent-interview-guide
流式输出如果每个 token 改一次 DOM，长回答会卡。大约每 50 毫秒把积下的 token 画一次，用 requestAnimationFrame 对齐帧。Markdown 对已收到的部分渐进渲染，不等全文。
长会话用虚拟列表，只画可视区，历史按页拉。离开页面关掉 EventSource。源笔记流式帧率从大约 30 到 60，百轮列表还能滚，页面内存大约降 40%。
087 · 中 · 网络传输是怎么优化的？
来源：ai-agent-interview-guide
跨洋到模型 API 往往比检索更贵。换到近区域端点，源笔记从美西大约 200 毫秒降到亚太大约 40 毫秒。
连接用 HTTP/2、连接池和 120 秒 Keep-Alive，避免每次 TLS 握手。请求开启 gzip，Prompt 去掉无意义空白。主端点超时大约 3 秒切备用端点。
网络超时大约少 80%。这题要和模型本身的生成时间分开：区域解决的是往返，不解决解码速度。
088 · 中 · 资源监控和自动扩缩容是怎么做的？
来源：ai-agent-interview-guide
只看 CPU 会扩错。业务高峰先打满的是模型并发和 P99。
指标三组：机器的 CPU、内存、网络；业务的 QPS、P99、错误率、模型并发；自建的队列积压和缓存命中。
HPA 按每 Pod 的 QPS：大约高于 50 扩容，低于 20 且持续约 5 分钟缩容，副本最少 2、最多 10。已知大促提前扩，不等人到了再反应。
源笔记高峰 8 个 Pod、低谷 2 个，相对固定 8 个大约省 35% 资源，高峰 P99 仍小于 5 秒。缩容要慢于扩容，否则流量一抖就抖动副本数。
089 · 中 · 模型超时怎么处理？
来源：ai-agent-interview-guide
超时分三段：连接大约 5 秒，首 token 大约 10 秒，整次大约 60 秒。等满一个总超时再失败，用户已经走了。
处理顺序：超时后换备用端点重试一次；再超时降到备用模型；备用也不行就走缓存或固定话术。GPT-4o、Claude、本地模型的备用都可以落到小模型，兜底都是缓存或话术。
流式如果已经吐了一部分，告诉用户可能不完整。非流式给重试，并把这次请求留到后台，完成后推送。源笔记用户可见超时从约 5% 到 0.5%；模型全挂时，靠降级仍有大约 95% 的请求能返回某种答案，其中大约 85% 的用户接受降级质量。
090 · 中 · 高并发下的限流降级策略是什么？
来源：ai-agent-interview-guide
限流分三层：网关总 QPS 大约 500，租户大约 50，用户每分钟大约 20。算法是 Redis 令牌桶，桶容量大约是配额的 2 倍，允许短突发。
降级按损伤从小到大：
| 级别 | 行为 | 触发例子 |
|---|---|---|
| L0 | 全功能 | 正常 |
| L1 | 关掉推荐、个性化 | QPS 到阈值约 80% |
| L2 | 复杂查询也走快模型 | 模型错误率 > 10% |
| L3 | 只回缓存和 FAQ | CPU > 90% 或内存 > 85% |
L3 的延迟小于约 200 毫秒。目标是核心问答还在，不是所有功能都在。源笔记在大约 5 倍突发下核心功能仍可用。
091 · 中 · 数据丢失和恢复策略是什么？
来源：ai-agent-interview-guide
按能不能重建定 RPO，不要所有库都做同样的备份。
核心的原始文档和租户配置要实时同步，RPO 为 0。对话和向量索引大约一小时内的增量可以接受。缓存和报表一天重建得起。
PostgreSQL 用流复制、每日全量和 WAL。Milvus 做 snapshot，同时保留原始文档，索引坏了可以重嵌。Redis 每小时 RDB，再加 AOF。
每季度演练：主库挂、向量数据坏、Redis 清空，记下 RTO。源笔记主从切换小于约 5 分钟，向量从原文重建大约 6 小时。没演练过的备份不算恢复方案。
092 · 中 · 模型输出格式异常怎么处理？
来源：ai-agent-interview-guide
解析从严到松，最后才放弃结构。
严格正则认标准的 Thought / Action。宽松正则忽略大小写和空白。还不行，用轻量模型把输出修成目标格式。再不行，整段当作 Final Answer，避免卡死。
预防比修复便宜：Prompt 里给格式例子；要 JSON 时用厂商的 JSON mode 或 tool use，不要指望纯文本永远守格式。格式遵循率低于约 90% 就告警，去查 Prompt，而不是只加正则。源笔记解析成功率从约 82% 到 98%，修复层兜住大约 5%。
093 · 中 · 敏感信息泄露怎么防止？
来源：ai-agent-interview-guide
假设模型会记住送进去的东西，所以敏感字段默认不进模型。
输入用正则加 NER 认出手机、身份证、银行卡、邮箱、地址，换成 [手机号_1] 这类占位符。映射只活在这次会话的内存里，结束即丢。输出时按权限把占位符换回，无权限的不换。传输用 TLS。日志在落盘前打码，日志权限按最小范围开。
源笔记覆盖率大约 99.5%。「请模型不要泄露」不是控制手段，替换发生在调用之前。
094 · 难 · 系统容量规划是怎么做的？
来源：ai-agent-interview-guide
Pod 数 = 峰值 QPS / (单 Pod QPS × 0.7)，0.7 是留大约 30% 余量。
源笔记的一组数量级：每 Pod 大约 25 QPS，峰值 200 QPS，大约要 12 个 Pod。1000 万向量大约 48GB，三节点各 16GB。Redis 缓存加会话大约 15GB，配 16GB 集群。对话记录大约每年 500GB，存储要单独看。
用历史做 3 到 6 个月的线性外推，每季度重算。预留实例和非高峰缩容是成本项，不改变容量公式。业务大约长到 3 倍时仍能扩，利用率维持在大约 60% 到 80%。算容量时 LLM 的厂商配额和 Pod 的 QPS 是两个上限，取更小的那个。
095 · 中 · 怎么做测试？覆盖率多少？
来源：ai-agent-interview-guide
Agent 的输出不确定，所以测试分确定性逻辑和效果评估，不能只用一个覆盖率。
金字塔大约是单元 60%、集成 30%、端到端 10%。单元测解析、分块、路由这些给定输入就有给定输出的部分，模型调用用固定夹具，pytest 加异步插件。源笔记单元覆盖率大约 85%，核心模块大约 95%。
集成测检索管道和工具参数是否传对，依赖用 testcontainers 拉起 Milvus、Redis。端到端只覆盖完整用户路径，数量少、成本高。
效果评估是 AI 系统多出来的一层：500 条以上的 query-answer。检索看 Recall@10、Precision@5、NDCG@5；生成看 BERTScore、ROUGE-L 和人工分；端到端看完成率和满意度。RAG 管道用 RAGAS，挂在 CI 里防止回归。压测按月一次，大改之后补一次。严重缺陷大约少 70%，靠的是评估进了合并门槛，不是用例数量本身。
096 · 中 · 监控和告警怎么做？
来源：ai-agent-interview-guide
三层指标，缺 AI 层就只能看见机器还活着。
系统层：CPU、内存、磁盘、网络、重启次数、数据库连接和查询延迟。业务层：QPS、P50/P95/P99、错误率、超时率、活跃用户、对话轮次。AI 层：模型延迟和成功率、token、检索命中和 rerank 分数分布、NLI 估的幻觉率、Agent 迭代次数、工具成功率。
Prometheus 加 Grafana 看指标，ELK 看日志，Jaeger 看链路，LangFuse 看每次模型的输入输出。
| 指标 | 阈值 | 级别 |
|---|---|---|
| P99 | > 10 秒 | P1，电话 |
| 错误率 | > 5% | P1，电话 |
| 幻觉率 | > 5% | P2 |
| 日 token | > 200 万 | P3，邮件 |
| 检索命中 | < 70% | P2 |
阈值要按误报调。源笔记发现问题从「等投诉」提前到大约 3 分钟，月误报小于约 5%。
097 · 中 · 日志系统怎么设计？
来源：ai-agent-interview-guide
链路字段见技术实现里的追踪一题。工程上要把日志分成四种，存储不能一种策略。
请求日志是概要。推理日志是 Thought、Action、Observation，以及 Prompt 和模型输出。工具日志是参数和返回。审计日志是登录和权限。
热数据大约 7 天进 Elasticsearch，温数据大约 30 天压缩进对象存储，冷数据大约一年放低成本存储。推理日志一条可以到数 KB，生产默认只留摘要，排障时再打开全文。所有落盘前做 PII 打码。
源笔记热查询小于约 1 秒，温数据小于约 10 秒，分层后存储成本大约降 60%。全文 Prompt 常开，账单和隐私会先出问题。
098 · 中 · 代码质量是怎么保证的？
来源：ai-agent-interview-guide
规范：PEP 8，函数有类型，ruff 统一格式。PR 至少一人审，编排器和安全模块两人审。审查看逻辑、异常、性能和安全，不看格式，格式交给工具。
mypy 用 strict，bandit 扫安全，单函数圈复杂度大约不超过 10。另外检查模块是否循环依赖，接口变更是否破坏调用方。
源笔记审查覆盖 100%，类型覆盖大约 90%，线上缺陷密度大约降一半。类型和复杂度挡的是意外耦合，挡不住 Prompt 效果变差，所以效果评估还得单独在。
099 · 中 · 文档是怎么维护的？
来源：ai-agent-interview-guide
四类文档各有主人。架构图、模块设计和 ADR 记录为什么这样选。API 用 FastAPI 的 OpenAPI，不手写一份会过期的列表。运维手册写部署、排障和预案。Prompt 文档写模板、版本和设计理由。
文档和代码同一个仓库，一起审查。能从类型、Schema、Dashboard 生成的就不手抄。源笔记新人从大约两周到大约三天，文档和提交同步率大于约 80%，ADR 大约 30 份。没有 ADR，半年后没人说得清为什么不用单路向量。
100 · 中 · 版本管理和发布管理是怎么做的？
来源：ai-agent-interview-guide
语义化版本：不兼容改 MAJOR，兼容的功能改 MINOR，修复改 PATCH。
main 随时可发，develop 集成，feature/* 合进 develop，hotfix/* 直接进 main。发版前冻结 develop，拉 release 分支，修完再进 main 打 tag。Changelog 从提交说明生成，分成功能、修复、性能、不兼容。
周发是节奏，热修不跟节奏。任何 tag 都要能复现。多组件（API、Worker、MCP Server）版本要一起说，只升 API 会让工具协议对不上。
101 · 中 · 技术债务怎么管理？
来源：ai-agent-interview-guide
债务要进清单，不能只留在注释里。Review、迭代回顾和静态分析都能产生条目，注释用统一标记方便搜索。
P0 影响稳定或安全，下个迭代必须还。P1 影响维护或性能，大约一个月。P2 是风格和小优化，碰到再改。每个迭代留大约 20% 时间还债，大重构单独排期。
没有分级，债务清单会变成永不执行的愿望。源笔记用可维护性评分盯积压，目标是持续高于大约 7 分（满分 10）。
102 · 中 · 配置管理是怎么做的？
来源：ai-agent-interview-guide
配置分三层。很少变的连接参数进仓库。Prompt、模型参数、限流阈值进配置中心（Nacos 或 Apollo），watch 推送，变更有审计，能回滚。密钥进 Vault 或 Kubernetes Secret，不进仓库，也不进配置中心的明文。
dev、staging、prod 用不同配置集。生产变更要审批。源笔记改 Prompt 不用重启，生效小于约 5 秒。热更新的风险是未评审的 Prompt 直接进生产，所以生产集和开发集必须分开。
103 · 中 · 团队协作和知识共享是怎么做的？
来源：ai-agent-interview-guide
技术栈跨了检索、模型和运维，知识不写下来就会留在一个人手里。
每周大约 30 分钟轮流分享，内容收成文档。复杂的 Prompt 和安全模块结对做。新人有导师。Wiki 放决策、排障和操作步骤，重复问题进 FAQ。Code Review 写清为什么，而不只是改哪一行。
这些是传递机制。真正减少重复事故的是排障记录和 ADR，不是分享次数。
104 · 中 · 你的系统能支持多少并发？怎么评估的？
来源：ai-agent-interview-guide
容量用压测定，不靠机器规格口算。Locust 模拟混合流量：简单问答 40%、RAG 30%、多轮 20%、工具调用 10%。
源笔记的环境：API 4 个 Pod，每个 4C8G；Milvus 三节点，每节点 8C32G；Redis 三节点 Sentinel；云端 LLM QPS 上限 200。
| 并发 | P99 | QPS | 错误率 |
|---|---|---|---|
| 50 | 2.8s | 48 | 0% |
| 100 | 4.2s | 85 | 0.1% |
| 200 | 8.5s | 120 | 2.3% |
| 300 | 15s+ | 110，开始掉 | 8.7% |
瓶颈在 LLM 的 QPS 和延迟。200 并发时 Milvus 仍小于 80 毫秒。安全上限取 P99 小于 5 秒、错误率小于 0.5%，大约 150 并发。日常高峰约 80。超过约 120 就扩 API Pod。简单查询走小模型，是缓解 LLM 瓶颈的手段，不是再加检索机器。
105 · 中 · 性能基准测试是怎么做的？
来源：ai-agent-interview-guide
基准分三档：单组件（检索、模型、rerank 的延迟）、端到端（简单问答、RAG、工具）、压力（最大 QPS 和并发）。
工具用 pytest-benchmark 和 Locust，结果入库才能和上次比。大改前后各跑一次。延迟增加超过约 10% 告警。数据集固定大约 100 条、覆盖各类 query，换数据集就不能比。
源笔记靠这个抓住两次「功能没变、延迟变坏」的回归。没有基线，优化故事无法核对。