基于 LLM 开发应用的误区

在过去，我会觉得机器学习距离我很遥远，是玄而又玄的内容，后来了解了一些原理，但还是觉得能力有限，潜力很大但仍然无法投入实际使用，但最近各类 LLM 发展迅猛，对话式的交互让人感觉更加易于上手也愿意多做尝试，正巧我在工作中也接收到了一些尝试将AI融入系统的任务，就有了跟 AI 亲密接触的机会。

在尝试利用 LLM 设计产品之前，我首先使用了以 Google Gemini(Bard)、OpenAI ChatGPT、Microsoft Copilot 为首的一众对话交互大模型应用，尝试搞清楚这些大模型们具体能做些什么。我刻意的用他们代替搜索引擎、知识问答社区，增加与他们互动的频次，后来又学习了一些吴恩达的 Prompt 工程课程，使得我的使用效率大幅进步。然后从某天开始，我遇到问题或者想要探索新领域下意识里会先去问问 LLM，而不是使用搜索引擎，我知道是时候开始尝试使用 AI 做具体的产品了。

LLM 带给我的冲击是非常剧烈的，这让我在设计产品之初把他当成了无所不能的 API，所以第一个粗浅的想法是做一个纯 Prompt 工程，感觉做好关键词管理和迭代控制就足够了，但落实到具体的产品场景中时能很快发现，LLM 远远达不到“具体”的无所不能，比如他不能理解A产品和B产品细节上的差别，当客户问到这类问题时，他会出于训练逻辑给出一些模棱两可的回答或者只是一些完全不符合事实的说法，这在闲谈中这种回答也许能作为玩笑话一带而过，但在严肃的产品咨询中，这种问题是最为致命的，如果 LLM 不清楚怎么回答，什么都不说，或者直接说不知道都比随便说点什么好的多。

所以千万不要陷入大模型是无所不能API这种陷阱里，如果在产品对比这种问答环节里体验就让人感到尴尬，那在医疗、教育、安全类的场景中就是极为危险的举动，我坚信AGI的到来，但在这天到来之前，还是需要谨慎对待LLM，仔细评估他究竟能做什么，不能做什么，哪个部分能够交给他处理，什么环节是坚决不可以放松的。

回到具体的使用案例中，还是产品对比这类应用场景，LLM 如果结合具体的知识库去使用，同时在 Prompt 中限定好角色身份、回答范围、超出范围如何回复，最终效果是非常好的，但这与理想中“大模型助理”的形象还是差了一点距离。

如果可以通过LLM完成更具体的工作就好了，最理想的情况是把业务逻辑甚至业务代码给LLM讲讲清楚，让她自己依据对话交互的逻辑建立新的业务流程，但问题是现在LLM这个状态，又有谁敢对她这么毫无保留？如果被对话拐骗把业务库删除了怎么办？那更进一步物理隔离出来一套独立的业务资源给LLM用呢？然后定期向主业务库同步确保业务安全的前提下让业务能走下去，但这一切值得吗？从成本、效率上来说都是及其不理想的。

我们再退回到“可以通过LLM完成更具体的工作”这个想法，如果LLM没有实际完成，而只是看起来完成是否可行呢？毕竟我们的系统后台对于客户来说是个黑盒，只要最终效果足够好，其中的逻辑不需要明说，如果放下“所有交互都由AI完成”这个执念，只需要考虑“看起来是AI完成的”这点，整个任务就轻松得多了。

具体来说，前期引导和问答环节可以放心交给LLM去做，但一旦涉及到严肃的业务场景，就由原来的业务逻辑接手，用既有固定化流程嵌入到对话中，使得业务可以在对话中流畅地进行，这样就能尽可能大的发挥LLM优势、避免重复开发、严谨对待原有的业务逻辑，达到一个相对平衡的结合点，但这仍然需要后端在既有业务流程中做适配性开发，前端也需要一些时间考虑在对话中如何植入既有业务以及如何退出。