前十一篇把 AIGC 从原理到实战到安全到微调全讲了一遍。看起来什么都会了对不对但面试官最后可能会问一个温柔一刀的问题你说了这么多怎么证明你的系统好用这个问题最难不是因为技术多复杂是因为很多人根本没想过怎么评估。RAG 跑起来了、Function Calling 接上了、Agent 能自主决策了——但效果好不好有没有退化用户满不满意不知道。没有数据。这不只是面试问题这是生产上的定时炸弹。你不知道效果怎么样就不知道什么时候退化。等用户来投诉说你这个 AI 最近怎么变蠢了已经晚了。这篇就聊这个话题评估、监控、成本控制——AIGC 项目上线后怎么持续保障质量。第一步建一个测试集没有测试集一切评估都是扯淡。你的知识库、客服系统、代码助手、数据分析 Agent——不管什么项目第一步一定是建测试集。测试集长这样[ { id: 001, question: 订单 20240715001 的物流状态是什么, expected: 订单 20240715001 目前正在派送中预计今晚送达。, category: 订单查询, difficulty: easy }, { id: 002, question: 我想买一台5000元以内的游戏本有什么推荐, expected: 推荐XX品牌游戏本¥4799搭载RTX4060显卡。, category: 产品推荐, difficulty: medium }, ... ]测试集的要求50-100 条就够。不需要几万条。覆盖你的核心场景。按类别分——查询类、推荐类、操作类。按难度分——易、中、难。每条都有标准答案。标准答案是人工写的不是模型生成的。定期更新。业务变了测试集也得变。为什么人工答案很重要因为你要比较模型答的和正确答案的差距。没有人工答案你比什么第二步定评估标准有了测试集就得有打分标准。最简单的办法人工打 1-5 分。分数标准5分完全正确和标准答案一致4分基本正确有小瑕疵但不影响3分部分正确但关键信息缺失或错误2分大部分错误1分完全不相关或编造招一个实习生让他针对 50 个问题打分。每打一轮得到一个平均分。比如 4.2 分。然后你改了参数、换了模型、改了 Prompt——再跑一遍——4.5 分。说明改对了。简单粗暴但有效。进阶办法LLM 评分LLM-as-a-Judge。用大模型给大模型打分你是一个 AIGC 效果评估专家。 请从准确性、完整性、安全性三个方面评估以下回答。 问题{question} 标准答案{expected} 模型回答{actual} 准确性1-5分回答中的事实是否准确 完整性1-5分是否完整回答了问题 安全性1-5分是否有不当内容、幻觉、泄露 输出 JSON 格式 {accuracy: 4, completeness: 4, safety: 5}研究显示在评分标准设计得当时LLM 评估与人工评估的结果有较高的一致性不同任务差异较大不能当绝对真理。够用但关键场景仍要人工抽检。更简单的指标回答长度。虽然不准确但能快速发现异常。比如一个知识库问答系统答案正常长度是 100-200 字。突然某天平均回答变成了 500 字——说明模型开始啰嗦了可能 Prompt 被改了或者上下文里有噪音。快速排查不一定精确但够快。第三步灰度对比测试上线不是直接全量。先灰度。A/B 对比- A 组旧版本10% 流量- B 组新版本10% 流量- 其余 80%当前稳定版跑一天对比 A 和 B 的指标平均延迟、Token 消耗、用户反馈、人工抽检评分。B 比 A 好全量上线。B 比 A 差回滚。回滚方案必须有。AIGC 系统的改动比传统系统更容易出现不可预期的问题——同一套 Prompt换了模型的一个小版本可能效果就变了。没有回滚方案等于裸奔。第四步线上监控评估只是上线的入场券。真正的质量保障在线上。三个必须监控的指标P95 响应时间。用户从发问到拿到答案的耗时。对用户体验影响最大。一般要求 P95 5 秒。超过 10 秒就告警。影响响应时间的因素Prompt 长度、模型大小、网络延迟、API 并发堵塞。你需要知道慢在哪里——是检索慢了还是模型推理慢了还是输出太长Token 消耗。这是你的真金白银。// 记录每次调用的Token消耗 public class TokenTracker { private final MeterRegistry meterRegistry; public void recordUsage(String model, String caller, int inputTokens, int outputTokens) { double cost calculateCost(model, inputTokens, outputTokens); meterRegistry.counter(aigc.tokens.input, model, model, caller, caller) .increment(inputTokens); meterRegistry.counter(aigc.tokens.output, model, model, caller, caller) .increment(outputTokens); meterRegistry.counter(aigc.cost.total, model, model).increment(cost); } private double calculateCost(String model, int input, int output) { // GPT-4o: $2.50/1M input tokens, $10.00/1M output tokens if (gpt-4o.equals(model)) { return (input / 1_000_000.0) * 2.50 (output / 1_000_000.0) * 10.00; } if (gpt-4o-mini.equals(model)) { return (input / 1_000_000.0) * 0.15 (output / 1_000_000.0) * 0.60; } return 0; } }每天看成本报表。如果某天的 Token 消耗突增说明有问题——可能是 RAG 返回了过多文档也可能是模型陷入了循环。错误率。API 调用失败的数量和比例。最常见的错误超时、限流429、内容过滤拦截。任何错误率超过 5% 就需要告警。成本控制Token 就是你口袋里的钱AIGC 项目上线后最大的隐形成本——Token。很多人在 Demo 阶段不关心 Token 消耗因为流量小。但上线后一个用户的单次对话可能消耗上千 Tokens。每天几千个用户成本可观。成本控制三板斧1. 上下文压缩。减少不需要的信息。比如历史对话保留最近 3 轮就够了不需要保留 20 轮。public class ContextCompressor { public ListMessage compress(ListMessage history, int maxTurns) { if (history.size() maxTurns * 2 1) { return history; } // 保留系统消息 最近几轮对话 Message system history.get(0); ListMessage recent history.subList(history.size() - maxTurns * 2, history.size()); ListMessage compressed new ArrayList(); compressed.add(system); compressed.addAll(recent); return compressed; } }2. 结果的缓存。同一个问题不要让模型反复回答。对于高频问题设置缓存。Component public class AnswerCache { private final CacheString, String cache; public AnswerCache() { this.cache Caffeine.newBuilder() .expireAfterWrite(1, TimeUnit.HOURS) .maximumSize(1000) .build(); } public String getOrCompute(String question, FunctionString, String computeFn) { String key question.toLowerCase().trim(); return cache.get(key, computeFn); } }缓存能省多少取决于问题的重复度FAQ 这类高频复现的场景收益大开放式问答基本靠不住。3. 模型分层。简单问题用小模型复杂问题用大模型。public String smartQuery(String question) { if (isSimpleQuestion(question)) { // 简单问题GPT-4o-mini便宜 return cheapClient.prompt().user(question).call().content(); } else { // 复杂问题GPT-4o贵但强 return expensiveClient.prompt().user(question).call().content(); } } private boolean isSimpleQuestion(String question) { // 长度 20 字、不涉及多步推理 return question.length() 20; }这三板斧能省多少取决于你的业务结构高频重复问题多缓存的收益就大长短问题分布均匀模型分级的收益更明显。上线前先统计一版问题的分布再决定把力气花在哪。日志记录最后的退路所有 AIGC 系统都应该记录完整的日志。不是技术需要是业务需要。用户投诉AI 给我推荐了不合适的商品——你怎么溯源看日志。每条对话记录用户输入、模型输出、检索到的文档、Token 消耗、响应时间。Component public class AiAuditLogger { public void log(AiAuditRecord record) { // 写入专用日志表 auditRepository.save(AiAuditEntity.builder() .sessionId(record.getSessionId()) .userId(record.getUserId()) .userInput(record.getUserInput()) .modelOutput(record.getModelOutput()) .ragContext(record.getRagContext()) .modelName(record.getModelName()) .inputTokens(record.getInputTokens()) .outputTokens(record.getOutputTokens()) .responseTimeMs(record.getResponseTimeMs()) .createdAt(LocalDateTime.now()) .build() ); } }有了日志你就有了数据和证据。不管是分析模型跑偏、审计合规、还是排查 bug日志是最后的防线。 面试官视角的标准回答如果面试官问AIGC 项目上线后怎么保证效果和成本从四个方面做测试集评估、灰度上线、线上监控、持续优化。第一建 50-100 条真实问题的测试集每条都有标准答案。每次改 Prompt 或模型前先跑一遍测试集打分。低于阈值不改。第二灰度上线。10% 流量跑新版本和旧版本对比指标。新版本差就回滚不头铁。第三线上监控三个核心指标P95 响应时间5 秒正常、Token 消耗看日报突增告警、错误率5% 告警。配合完整的日志审计每条对话都能溯源。第四持续优化成本。上下文压缩保留最近 3 轮就够了、答案缓存高频问题复用、模型分层简单问题走小模型复杂问题走大模型。这三板斧先统计业务的问题分布再决定重点优化哪一块。最后补充一句AIGC 项目要做可评估、可回滚、可审计。不能因为用了 AI 就不管质量了反而要比传统项目监控得更细。评估监控讲完了顺着 RAG 主线一路走下来面试里大半个 AIGC 话题你都能接得住。下一步是那些看起来简单、答起来容易露怯的基础题——比如大模型的记忆到底有多大长对话为什么会突然失忆。下一篇就聊这个上下文窗口是怎么组成的用户聊到一半 AI 翻脸不认人工程上怎么兜。