众所周知！大模型应用构建面临的 6大误区

引言

人工智能（AI）正以前所未有的速度改变着我们的生活和工作方式。从语音助手到智能座舱，再从医疗诊断到金融风险预测，AI 的应用场景不断拓展，展现出巨大的潜力和价值。「尽管如此，我们目前仍处于大模型应用构建初级阶段，面对复杂的应用，也会经常犯错」。为此，本文列举分享了大模型应用构建常见的6大误区（如果你参与过大模型应用的开发，很有可能也遇到了类似的问题）。

误区一、强行使用生成AI

每当出现一项新技术，似乎都能听到资深工程师们集体叹气的声音。生成式 AI 也不例外——它看似拥有无穷的能力，但只会加剧人们想把它应用到一切问题上的冲动。曾经有人提出了一个用生成式 AI 优化家庭能耗的点子。即将家庭的高能耗活动列表和按小时计费的电价输入到一个大模型中，然后要求它制定出一个最省钱的日程安排。实验结果显示，这种做法可将电费减少约 30%。但是仔细想一下，如果只是简单地把高能耗活动安排在电价最低的时候，比如晚上十点后洗衣服和给车充电，效果怎么样？

其实基于生成式AI的规划用贪心策略安排也很有效。即便效果不佳，也还有许多更便宜、更可靠的优化方法，比如线性规划。类似的情况还有很多，例如一家大公司想用生成式 AI 检测网络流量异常；另一家想预测客户的来电量；还有一家医院想判断病人是否营养不良。

探索新方法、了解可能性当然有好处，只要你清楚：你不是在解决问题，而是在测试解决方案。「“我们解决了问题”和“我们用了生成式 AI”是两个完全不同的标题，但很多人更想要后者。」

误区二、把“产品差”误认为“AI差”

在另一个极端，很多团队试用生成式 AI 后用户反馈不好，就彻底否定了它的适用性。但其他团队在类似场景下却取得了成功。调查发现其中主要问题并不在AI，而是在产品。很多人告诉我，他们 AI 应用的技术部分其实不难，难的是用户体验（UX）：界面该长什么样？如何无缝集成进用户的工作流程？如何引入人类监督？UX 一直都很难，但在生成式 AI 中更难。我们知道它在改变阅读、写作、学习、教学、工作、娱乐……但我们还不知道“未来”具体是什么样。

以下是几个看似简单、但实际用户反馈很反直觉的例子：

我有个朋友做的是会议纪要总结工具。起初他们关注的是总结的长短——用户更喜欢三句话的总结还是五句话的？但后来发现，用户根本不在乎总结内容，他们只关心会议中「跟自己相关的待办事项」。

有公司开发了一个做岗位匹配的聊天机器人，发现用户并不追求“正确”的回答，而是想要“有帮助”的回答。比如用户问：“我适合这个岗位吗？”机器人回答“你完全不适合”——虽然正确，但对用户毫无帮助。其实用户想知道：差在哪？我该如何补足？

还有公司研发了一个解答税务问题的 AI 机器人。最初用户反响平平，觉得没什么用。调查后发现，「用户其实不喜欢打字」。对着一个空白输入框，不知道机器人能干嘛、不知道该输入什么。

于是他们给每次交互加上几个推荐问题供点击。这样用户更愿意尝试，用得多了信任也建立了，反馈也变得更正面了。「现在大家都用同样的模型，AI 技术趋于同质化，真正的产品差异主要在产品设计上。」

误区三、起步就太复杂

常见例子包括：

• 用智能体（agent）框架处理问题，而其实直接调 API 就够了；
• 纠结用哪个向量数据库，而其实基于关键词的简单检索就能解决问题；
• 坚持微调模型，而其实只用提示词工程（Prompting）就够了；
• 使用语义缓存（semantic caching）；

现在新技术太多，确实容易让人想直接用上所有酷炫工具。但过早引入这些复杂工具会带来两个问题：

1. 抽象过早，掩盖关键细节，导致你无法理解和调试系统；
2. 引入额外 bug；

工具作者也会犯错。在很多框架的代码中都发现了默认提示里的拼写错误。如果你使用的框架更新了提示词却没告诉你，你的应用行为可能发生了变化而你却完全不知情。

当然，「抽象是好东西」，但必须在成熟后再引入。在这个 AI 工程的早期阶段，最佳实践还在形成，我们使用任何抽象工具都要格外小心。

误区四、 Demo容易优化难

对于很多公司做大模型应用开发，用 1 个月时间就能实现了他们想要的 80% 体验，然后又花了 「4 个月」 才从 80% 提升到 95%。一开始的快速进展，让他们严重低估了之后优化的难度，尤其是在减少幻觉（hallucination）方面。一家做电商 AI 销售助理的初创公司曾说：从 0 到 80% 的时间，与从 80% 到 90% 是一样长的。他们遇到的问题包括：

• 「准确性 vs 延迟」：越多规划和自我纠正，流程节点越多，延迟越高；

• 「工具调用」：AI 很难分清多个相似工具；

• 「语气问题」：比如“像奢侈品牌礼宾员一样说话”的系统提示很难做到完全一致；

• 「意图理解」：很难准确理解顾客真正的需求；

• 「测试难度」：请求组合几乎无限，难以构建完备的单元测试；

UltraChat 论文中，Ding 等人也指出：“从 0 到 60 很容易，而从 60 到 100 则极其困难。” 这是 AI 产品开发者最早学到的痛苦教训之一。「做个 demo 很容易，做个产品很难。」

除了幻觉、延迟、准确性/延迟权衡、工具使用、提示、测试等问题，还有：

• 「API 不稳定」：有团队曾说有 10% 的 API 请求超时，这个问题个人曾经在体验Agent应用的时候就遇到过多次。
• 「合规问题」：例如模型输出版权、数据访问/共享、用户隐私、检索系统带来的安全风险、训练数据来源的不明确；
• 「安全问题」：产品可能被滥用，或产生冒犯性内容；

在制定产品的里程碑和资源规划时，记得考虑这些潜在障碍。一位朋友称之为“「谨慎的乐观」”。要记住：「很多炫酷的 demo，并不能转化为优秀的产品」。

误区五、 放弃人工评估

为了自动评估 AI 应用，很多人选择了“AI 评 AI”（LLM-as-a-judge）的方法。一个常见错误是「完全依赖 AI 评审而不做人类评估」。「AI 评审当然有用，但并不确定可靠」。其效果取决于背后的模型、提示词以及应用场景。如果 AI 评审设计不当，可能会给出误导性的评分。AI 评审也要像其他 AI 应用一样不断优化。一些好的模型产品基本上都有人工评估机制，每天人工评估部分样本（30～1000 条不等），主要有以下原因：

1. 「对比人类与 AI 的评分」：如果人类分数下降，AI 分数却上升，就该检查评审模型了；
2. 「更深入理解用户行为」：可能为你提供优化思路；
3. 「发现数据中隐藏的用户行为变化」：尤其是与当前事件有关、自动探索无法发现的部分；

人工评估的可靠性也取决于清晰的标注指南（annotation guidelines）。好的指南可以帮助你改进提示词，如果人都看不懂，模型也不会懂。而且这些指南还可以用于后续微调数据的构建。

有些项目只需 「盯着数据看15分钟」，几乎都能发现一些关键问题。人工检查数据其实是最有价值的事情，但也是最不体面的事情。

误区六、用众包方式决定方向

在公司为能够在早期追赶生成式 AI热点，并没想好该聚焦哪些应用方向，于是向全公司“众包”点子。“我们招聘了这么多聪明人，就让他们告诉我们做什么吧。”结果就是，我们得到了上百万个 text-to-SQL 模型、Slack 机器人和无数代码插件。

当然，听取员工建议是对的。但个体往往会关注对自己日常工作影响最大的问题，而不是对公司 ROI 最高的问题。「没有全局战略的引导，就容易陷入一连串低影响、碎片化的项目，最终得出‘生成式 AI 没有价值’的错误结论。」