🔥 Search Hot Tweets

如果你或你的团队正在塑造AI产品，我建议从Day1开始，就要注重「可观测性」 传统PM：“今天AI有点不对劲。” 掌握可观测性的AI PM： “当查询词超过50个字，且上下文文档超过10个时，AI就会失败。具体表现为，在太平洋时间下午2-4点流量高峰期，它会幻觉出一些不存在的技术特性。” 最重要的区别，是后者的问题能被解决。 传统的PM提交一个模糊的Bug报告，然后它就在需求池里积灰，因为工程师根本无法复现“感觉不对劲”。 而掌握可观测性的AI PM，是带着“证据”来参加会议的： - 他们能展示出具体的链路追踪，指出是哪个长查询导致检索了过多文档，撑爆了上下文窗口。 - 他们能指出时间戳上的规律——故障都集中在流量高峰期。 - 他们甚至能提出假设：“看起来是高流量时缓存被清理，导致了更多的文档检索，从而破坏了上下文窗口。” 然而在我们的实际工作中，推行这个机制会遇到重重阻力： 借口1：“这太技术了，是工程师的事” - 现实是： 现代可观测性工具是为产品团队构建的。你看到的不是堆栈跟踪，而是用户旅程。 - 你看到的不是： “第187行出现空指针异常” - 你看到的是： “AI检索了7个文档，生成响应耗时2.4秒，忽略了3个文档。”如果你能看懂漏斗图，你就能看懂链路追踪。 借口2：“我们没时间做这个” - 现实是：搭建可观测性： 30分钟。 - 在没有它的情况下，调试一次真实故障： 2-3天。 一个金融科技创业公司，花了整整两周时间，去调试为什么他们的Agent会给出鲁莽的投资建议。如果有可观测性，5分钟就能发现，是一个“be aggressive (要激进)”的字符串意外溜进了提示词模板。修复只需一行代码，但损失的信任却需要数月弥补。 借口3：“我们的AI没怎么出问题” - 这是最致命的无知。 AI的失败是“潜在”的：它看起来是对的，即便它错了。 - 一个旅游机器人10%的时间会订错城市 → 只有少数倒霉蛋会抱怨。 - 一个推荐引擎给阿拉斯加人推荐泳衣 → 点击率看起来还行，但收入在悄悄流失。 如果产品不具备可观测性，那就是一只温水里的青蛙。 那如何构建一套可观测的系统呢？ 其实有大量的方案，比如监控token与性能可以使用helicone，如果是统计成功率与失败情况也可以使用类似signoz的数据服务 第一步是要有意识构建观测数据，第二步是实施系统，第三步是定位分析问题，最终才能解决，以下有两个实际生产过程中如何依靠这类可观测系统来解决问题的： 案例一：无限循环的客服Agent 一个客服Agent开始疯狂地给同一张工单回复50多次。 链路追踪显示： - Agent读取工单 ✓ - 判断“需要更多信息” ✓ - 提出澄清问题 ✓ - 客户回复 ✓ - Agent丢失了之前的对话上下文 ✗ - 返回第2步，无限循环… 根源： 缺乏对话状态管理。 结果： 有了可观测性，几小时内修复。没有它，工程师们猜了好几天模型参数。 案例二：你不知道自己构建的“隐藏架构” 一个旅游机器人本应预订旧金山(SF)的机票，却总是推荐圣地亚哥(San Diego)。 链路追踪显示： 一个简单的用户请求，背后竟然并行运行了三个隐藏的Agent（预算Agent、本地体验Agent、研究Agent），这是AI框架自发创建的，并非团队有意设计。这些“额外”的Agent干扰了检索结果。 根源： 真实的系统架构与设想的不符。 结果： 有了可观测性，一条路由规则就解决了问题。没有它，团队还在争论是不是模型“又幻觉了”。 当你了解了这些，就会对团队进一步提出要求 首先PM就应该调整自己的思路 之前（靠希望驱动）： 写10页PRD，充满“应该理解用户意图”等模糊描述，然后丢给工程师。 之后（靠数据驱动）： 分享5条失败的链路追踪：“看，这里机器人把旧金山和圣地亚哥搞混了。”然后定义可衡量的成功标准：“城市解析准确率必须 > 99%。” 需求文档，不再是空洞的需要，而应该是数据。 高级可观测性技术 - A/B测试模型和提示词： 在生产环境中，将5%的流量路由到实验模型，实时对比GPT-4o-mini和Claude-3.5-Sonnet在真实场景下的表现，用数据决定哪个更优。 - 响应拓扑映射 (Response Topology Mapping)： 视觉化地展示AI的决策路径。一个法律AI助手通过这种方法发现，中等长度的查询总是掉进一个“决策盲区”，导致准确率低下。解决方案不是优化提示词，而是直接砍掉这个有问题的决策路径。 - 故障模式谱系 (Failure Mode Genealogy)： 追溯故障的“家族树”。一个客服机器人有23种不同的失败模式，通过谱系分析发现，其中19种都源于3个共同的根本原因。只做了3个底层修复，就解决了83%的Bug。 最后的核心要点： - 链路追踪揭示真实架构： 它往往与你设计的不同。 - PM必须标注数据： 你的判断定义了成功，而不是LLM的。 - 从PRD转向链路追踪： 你的需求，就是你的评估标准。 “AI好像坏了”和“AI在下午3-5点，当用户使用移动设备且查询词超过50个字时会失败”，这两者之间的区别，就是可观测性。 而只有后者，才能真正帮助你定位并解决问题。