今天是 12.20 号，参加了 puputech 举办的线下沙龙活动，会议主要分享了 AI 在企业中的实际落地，借此机会，梳理一下对 AI 应用的理解。
如何落地？
这是会议的第一部分，给出了一个数据：目前全球所有的 AI 应用尝试中只有 5% 真正落地。落地难已经是行业的普遍共识。作为技术驱动的互联网公司，究竟应该如何让 AI 落地呢？实际上互联网公司正是 AI 应用落地的最佳范本。
从后台开始，以效率为导向，发现“影子 AI”的场景。
在大多数的 AI 应用尝试中，直接面向 C 端或者是面向某个场景搭建一个 AI Agent 直接解决问题是最热门的方向，同时也是 ROI 最低的选择。
而朴朴选择从企业的中后台开始，优化一些垂直、简单的场景。比如电商数据分析、商品合格审查、上游渠道对接，这些场景都是“影子 AI”出现的高频场景，即员工工作过程中会主动使用 AI 辅助但是不在公司的管理中。这些场景其实是落地成功率最高的部分。这种思路不同于普遍激进的“代替某个部门”的看法，而是在积累局部上的优化，提高整体的效率。
但是这其中有一个问题：具体的业务场景谁来发现？业务人员不具备搭建 workflow 自动化的能力，技术人员又不熟悉业务。朴朴给出的解决方案是基于开源平台 Dify，让业务人员主动以图形化的方式搭建工作流，技术人员负责把其中跑通了的链路完整部署。这是一个大型企业落地 AI 应用的范本：小步快走，局部优化。
思考：大部分 AI Agent 为何失败？
抛开 LLM 当下的能力瓶颈的影响，大多数的 AI Agent 产品的问题在于过于追求某个场景的完整替代。不过这也正是 Agent 市场能吸引巨量资金的原因，但这必然面临一个问题：LLM 可能在某个业务 70% 的场景经过不断的反馈、迭代可以达到基本替代人工，但是 Agent 追求全链路替代，导致这 70% 的成功被 30% 仍然达不到要求的场景给拖累，最终的结果不理想，或者稳定性低，并不能达到生产标准。
另一个问题是大多数的 Agent 公司并没有真正的业务场景。他们可能有几个业内专家，但是缺乏具体场景，必然缺少了大量的训练素材和人类反馈。而专家不一定有一线脏活累活的实操经验，导致了 Agent 无法像朴朴一样在局部建立大量反馈、优化、迭代的循环。
针对这个问题我想起了硅谷之前火的一个新概念：驻场工作。Agent 公司直接指派自己的员工到客户公司工作，亲自参与一线工作。同时假如我的 Agent 面向的是会计市场，最好是积极地与大型公司共建这个 Agent，而不是找一批会计专家，对着模型反复改提示词、调上下文。
走向前台？
究竟如何在前台落地？究竟要不要让 Agent 走向 C 端，这是一个很宏大的命题。借助朴朴这个电商场景来谈谈我的看法，目前大家的主要落地方式其实比较单一，就是 chatbot + tool calling 的形式，从个人的使用上来说，意义不算太大。
原因在于，真正对 AI 有需求的主要还是生产场景或者说追求效率的场景。我是有可能要点一杯咖啡，然后告诉 AI 帮我点一杯，这很酷很有想象力，so what? 对于公司来说，难道我不做这个功能，用户就不点咖啡了吗？做了这个功能反而因为不稳定性，可能造成退款等问题，为公司增加了无意义的成本。另一方面，电商场景很多消费其实是无目的消费，用户做的只是在购物车里添加喜欢的商品，其实是一个不理智的状态，很大概率为公司带来更高的收益。但假设 Agent 足够强大，用户要求“1000块以内，帮我置办年货，优先考虑性价比”，AI 完整地实现需求，但是公司获得收益了吗？并没有。
所以，个人观点，在未来很长的一段时间内，AI 应用的主战场依然在生产端。
传统企业的困境
在问答环节有朋友分享自己在传统行业，非常积极地推荐公司生产的 AI 化，但是得不到同事和领导的支持。
首先可以明确的一点：AI 化从公司用人成本和生产效率上来说一定是有效的，特别是传统行业有更多可以自动化的工作内容，但是无法 AI 化受到以下几个方面的阻力：
- 同事阻力：一般推动 AI 化的都是技术岗位，他们接触前沿生产力工具，应用熟练。如果要 AI 化，他们大概率是执行者和受益者，而传统行业大部分的低效生产力自然是不愿意当被优化的部分的。
- 技术人员不足：在互联网行业中是效率驱动、技术驱动的，技术人员地位很高。而传统行业技术人员可能只是很小的一个部分，自然无法推动。
- 高层认知不足：传统行业高层年龄偏大，没有精力关注新技术。
技术分享
这是本次会议的另一个亮点，主要分享技术上后台如何 AI 化和一些优化工作流的技巧。切确地感受到“Software engineer”和“developer”的区别。
LLM 评测体系
随着 scaling law 边际效益逐渐降低，数据和算力同样重要。构建一个良好的评价体系是未来不断优化 AI 效果的一个关键部分：
- 构建可靠的测试集：不要用 AI 来构建测试集，AI 倾向于长回答和偏好自己的回答。
- 对比测试 (A/B)：不要具体评分，要进行双盲对比，交换 A/B 位置校验有效性。
- 裁判模型：一定要选用更先进的模型。
- 归因分析：成本高，暂时不做。
LLM 后台经验
- 流量与资源管理：为核心业务和高级用户单独分配资源，保证核心业务稳定性。
- 任务时效性：在非时效性任务上利用服务器空闲时段或支持 batch API 的服务。
- 降级策略：由于模型服务商 SLA 无法完全保证，要做好多个模型互相替代的降级方案。
总的来说，线下技术沙龙确实是一个很好的学习技术和了解行业的平台。感谢 puputech 提供的机会。