新组建 AI 团队的三个常见误区

在企业纷纷组建 AI 团队的当下，如何少走弯路？一位长期为搜索与 RAG 项目提供咨询的工程师，结合自己十余年来从传统搜索到生成式 AI 的实战经验，梳理出新团队最容易踩的三个误区：忽视评估、把检索当成简单勾选项、把上下文等同于文档块。作者承认自己作为被请来救火的顾问，视角偏向「只见难题」，但他认为这些经验与 2010 年代新搜索团队遇到的阵痛高度相似，依然有参考价值。

评估先行：别凭直觉判断「好坏」

作者观察到，成熟的搜索与 AI 团队会将近一半投入放在理解问题上，而不是急于给出方案。核心工具是评估（evals）：寻找产品改进方向需要评估，定位 agent 失败点需要评估，基于用户行为训练模型同样需要评估。

文中提到 Hamel Hussain 和 Shreya Shankar 开设了完整的 AI 评估课程，重点不是通用指标，而是衡量端到端的产品成功，并据此拆解薄弱环节——可能是检索，可能是护栏，也可能是别处。作者举例说，他曾为一家汽车配件公司做内部搜索项目，原本以为员工查询某个零件就是想要这个零件，但实际他们想知道的是「卖这个我能拿多少奖金」。这提醒从业者：评估是科学方法，不是直觉。

• 评估对象：端到端任务成功率，而非单一指标
• 关键动作：假设—实验—复盘—改进
• 常见误区：盲信产品经理判断，把 PM 观点当成结论

检索不是勾选项，而是决定质量的核心

研究反复表明，「检索质量决定 AI 质量」。作者指出，新团队常误以为存在一种通用 RAG 架构可直接套用，但实际检索方案差异巨大：

• 如何切分文档块（chunk）
• 用什么技术召回这些块
• 召回后如何排序
• 如何保证结果多样性

文中引用的一篇论文显示，给 LLM 提供正确上下文后，答案质量提升幅度相当显著；而不同检索策略下，最终答案质量也有明显差距。作者建议先做廉价、易实现的「脏」实验验证方向，再投入重型方案，避免被既有架构绑架。

上下文的本质是元数据，不是文档块

经典的 RAG 思路是把文本切成块、向量化、相似度匹配后塞进 prompt。但作者认为这远不够：RAG 的本质是「把有用的信息呈现给 agent」，让模型判断这些信息的可信度与相关性。

他举了一个对比：如果要喂给 LLM 关于他在 Shopify 工作的一段内容，是只给正文片段，还是带上「标题、平台 Medium、发布日期 2020-07-20」等元数据？后者能让模型判断信息是否近期、是否权威、是否值得深挖。

• 检索三大支柱：词义/向量召回、元数据过滤、查询理解
• 信息单元：不是 chunk，而是带出处和属性的知识节点
• 工具目标：让 LLM 内部的隐式裁判做出更好判断

工程与数据科学需要合二为一

作者强调，AI 团队和搜索团队一样，需要既能搭建可扩展系统，又能用假设驱动方式工作的多面手。传统模式下数据科学家把模型「扔过墙」，工程师几个月后才意识到方向错了，代价巨大。他建议团队成员都要同时培养工程与数据科学两种视角，做出分钟级的权衡——这一点在他看来同样适用于 AI 团队的人才培养路径。