推文

@mylifcc · 2026-10-08 20:07

绝大多数 LLM 项目死在 Demo 到 Production 的最后一公里，原因只有一个： 团队一直在用“刷题思维”评估模型，而不是“产品决策思维”。 刷 Benchmark、看各大榜单的分数，甚至自己搭一套规整的评测集，本质上是在温室里看花。 而在真实生产环境里，输入全是歧义、长上下文被截断、格式畸变，还有无数从未在测试集里见过的边缘用例（Edge cases）。 GitHub 团队在分享把 LLM 落地到 Secret Scanning（密钥扫描）的工程实践中，提出了一个极为清醒的三层评估框架： 1. 核心业务目标（Primary Outcome） 你引入大模型究竟是为了解决什么核心体验？ 在他们的场景下，是降低误报率（提高 Precision），让开发者少看噪音告警。 2. 安全红线底线（Safety Constraint） 这是最容易被忽视的：指标之间从来不是对等可交换的。 在安全场景，误报只是体验问题，但漏报真实凭据会引发灾难性事故。因此，召回率（Recall）绝不能跌破安全阈值。 哪怕一个 Prompt 能把准确率拉到极致，只要召回率掉了一点，这个方案就必须一票否决。 3. 现实工程约束（Operational Guardrails） 效果再好，延迟（Latency）、推理成本（Cost）、系统可靠性扛得住吗？ 很多在 Notebook 里惊艳的方案，一放到高并发业务流里，就被吞吐量和账单瞬间压垮。 更重要的一点是认知层面的转变： 永远不要把 Offline 评估当成一次性任务，它本质上是 AI 系统的 End-to-End 集成测试（Integration Testing）。 换模型、改 Prompt、调整上下文策略，就像改底层业务逻辑一样，随时会引入隐蔽的质量退化（Regression）。没有自动化回归测试体系，上线就等于裸奔。 做 AI 应用，别再沉迷于“模型能不能答对这道题”； 先想清楚：你的产品能承受多大代价的错误？系统的安全底线又在哪里？ 你们在将模型推上生产环境时，最难把控的指标是准确率、延迟，还是那根碰不得的安全红线？

曝光 759 · 评论 2 · 点赞 3 · 书签 2 · 曝光/时 185.22691251918334