主题
React + AI 应用开发
如何建设 AI 前端的成本、延迟和质量观测体系？
AI 体验不能只看页面快不快，还要知道首 token、工具耗时、token 成本、引用质量和用户是否完成任务。
面试官想考什么
- AI 应用的核心性能指标有哪些？ 考察是否超越 Web Vitals。
- 如何关联一次前端操作和模型调用？ 考察 trace 设计。
- token 成本怎么归因到用户和功能？ 考察成本治理。
- 质量如何量化而不是凭感觉？ 考察评估闭环。
一句话回答
text
我会用统一 traceId 串起用户动作、前端渲染、网关、模型、检索和工具调用，分别记录首 token、生成耗时、token/费用、错误和 Web Vitals，再结合引用正确性、任务完成率、反馈和抽样评测做分版本、模型和功能的质量闭环。面试回答详解
1. 指标分层
- 用户体验：提交到反馈、首 token、可读首段、总完成时间、断开率。
- React 性能：render/commit、长任务、INP、内存、列表滚动。
- 模型链路：排队、TTFT、生成速度、输入/输出 token、模型版本。
- 工具链路：检索耗时、工具调用耗时、失败率、审批等待时间。
- 业务质量：任务完成率、重试率、人工接管率、引用正确性、用户评分。
2. Trace 和字段
text
user action
-> frontend span
-> api request
-> model span
-> retrieval/tool spans
-> final message公共字段包括 traceId、release、route、tenant hash、feature flag、model、prompt version、tool name、status 和 sampling decision。不要把完整 prompt、token、文件或敏感答案无差别写入日志。
3. 前端埋点
前端记录用户可感知的时间点，而不是把服务端耗时直接当体验：
text
submit -> request accepted -> first visible delta -> completed/error首 token 到达但页面因为 Markdown 解析卡住，用户仍然会觉得慢，因此要同时测 visible delta、React commit 和长任务。
4. 成本和预算
按租户、功能、模型、输入输出 token、工具次数和缓存命中归因。设置单请求、单用户和单租户预算；前端展示剩余配额或降级提示，服务端负责最终限流和计费。不要只用平均成本，长尾工具调用可能吞掉预算。
5. 质量闭环
线上反馈适合发现真实问题，离线评测适合版本比较。建立带脱敏输入的回归集，评估答案正确性、引用支持度、格式遵循、工具选择和安全拒绝。模型或 prompt 升级要与前端 feature flag、release 和告警关联，支持快速回滚。
可直接背诵的 30 秒回答
text
AI 前端观测要同时看体验、系统和质量。我会用 traceId 串起提交、首个可见 delta、React commit、网关、模型、RAG 和工具调用，记录 TTFT、总耗时、token、费用、错误和 Web Vitals。按模型、prompt 版本、租户和功能分组，再用任务完成率、引用正确性和反馈做质量评估，配合预算、采样和回滚。扩展知识
三类数据要分开
- Logs：具体错误和事件上下文。
- Metrics：可聚合的延迟、成本和成功率。
- Traces：一次请求跨前后端的因果链。
OpenTelemetry 可以统一这三类信号的语义，但浏览器端仍要谨慎采集隐私和高频 token 事件。
面试官追问链
追问一：为什么 TTFT 不是唯一延迟指标？
- 考察点：体验理解。
- 回答方向：用户还关心持续输出速度、首个完整可读 block、工具等待和最终完成；TTFT 低但生成慢仍然体验差。
追问二：如何保护观测数据中的 prompt？
- 考察点：隐私治理。
- 回答方向：默认不采完整内容，使用 hash、长度、模板版本和脱敏摘要；需要样本时权限隔离、短期保留并审计访问。
追问三：质量指标和人工反馈冲突怎么办？
- 考察点：评估方法。
- 回答方向：分层分析样本、人群和任务类型，结合离线标注、用户反馈和业务结果，不能用单一指标替代判断。