原贴链接

嗨，开发者们，

在过去的一年里，我的项目主要涉及商业GenAI/LLM相关的系统。最近工作中最让我困扰的是，我们似乎已经降低了对最终产品可靠性和确定性的期望。从应用程序错误率低于百分之一的日子，我们转而说“是的，它会在80%的情况下工作，但你知道这些模型的情况”。随着我们越来越多地将控制权交给LLMs，我们，开发者，正在失去它。

这让我思考——我们为什么首先使用LLMs。在我过去开发的应用中，原因通常是：对话理解。我将给你两个我们公司在deepsense.ai开发的两个应用的例子（由于披露原因，用例可能与实际有所修改，但技术问题保持不变）。

—

酒店员工的聊天机器人应用

该应用的主要功能是回答需要从动态数据源（比如关系数据库）获取信息的问题。问题的特征非常特定于领域。例如，员工会使用该应用来交换班次——这个过程有很多内部规则：谁、何时以及与谁可以交换班次，这对LLM来说很难转化为SQL查询。

为了克服这个问题，我们要求LLM使用一组预定义的方法，而不是生成SQL查询本身。方法可以通过逻辑运算符连接，最终结果可能看起来像这样：

问题：谁可以在下周二或周三与我交换班次？

Employees ->
available_for_shift_swap($CURRENT_USER, “2024-09-10”) OR available_for_shift_swap($CURRENT_USER, “2024-09-11”)

“available_for_shift_swap”方法的底层实现会检查所有班次交换的要求（并创建相应的SQL语句，纯功能性），从而保护LLM免受领域特定复杂性的影响。

你可以在这里获取这种方法的代码并阅读更多：https://github.com/deepsense-ai/db-ally

—

自动酒店预订的电话助手

我们面临的另一个挑战是通过电话助手进行预订。用户会拨打电话号码，由我们的助手迎接，然后引导完成预订过程。

当我们接手这个项目时，最初的方案是让LLM通过系统提示指定对话场景来完成整个过程。LLM负责推动对话，决定下一步做什么，保存信息，并在最后创建预订。这并不太有效——没有护栏，机器人很容易分心。将整个责任转移到LLM上使其难以改进和调试。

在这个项目中，解决方案再次是将LLM的责任限制在对话理解上——控制对话流程，“状态”（已经获取的信息），在代码中检查所需信息的完整性。LLM与这个管道的交互接口非常薄，模型会从一组小的预定义命令中选择来与状态交互，例如：

SetSlot(slot_name, slot_value) - 保存到状态（例如保存用户的名）
StartFlow(flow_name) - 启动预定义流程（例如房间预订流程）
流程本身是一组预定义的步骤，确保我们会从用户那里收集到完成特定场景所需的所有信息。

—

好奇听到这里是否有人有类似的LLMs工作经验？或者你知道任何其他使LLM应用更可靠的工具/库吗？

讨论总结

本次讨论主要围绕开发者是否应从大型语言模型（LLMs）手中重新夺回应用控制权展开。讨论中涉及多个关键话题，包括LLMs在应用中的可靠性、开发者对LLMs的控制权、传统解决方案的适用性以及用户体验设计等。许多评论者分享了他们在使用LLMs开发应用时的经验和挑战，提出了通过限制LLMs的责任来提高系统可靠性的方法。同时，也有评论者对LLMs在某些应用中的必要性表示质疑，认为在某些情况下，传统的解决方案可能更为合适。总体而言，讨论呈现出对LLMs应用的深入思考和多角度观点。

主要观点

  1. 👍 开发者应限制LLMs的责任以提高系统可靠性
    • 支持理由：通过预定义方法和流程来限制LLMs的责任，可以显著提高系统的稳定性和可维护性。
    • 反对声音：部分评论者认为这种方法可能限制了LLMs的灵活性。
  2. 🔥 质疑LLMs在某些应用中的必要性
    • 正方观点：在某些情况下，传统的解决方案（如编写SQL查询或使用简单的沟通工具）可能更为合适。
    • 反方观点：LLMs在处理自然语言交互方面具有独特的优势，不应轻易放弃。
  3. 💡 LLMs应被视为自然语言用户界面，而不是全能解决方案
    • 解释：许多公司对LLMs的期望过高，应将其视为自然语言用户界面，而不是全能解决方案。
  4. 👀 开发者应选择那些即使结果不完美也能带来显著收益的问题
    • 解释：开发者应选择那些即使结果只有80%正确也能带来显著收益且错误答案风险较低的问题。
  5. 🤔 LLMs本质上是一种推理工具，而不是可信赖的知识来源
    • 解释：需要通过其他技术来增强系统的可信度，如检索增强生成（RAG）技术。

金句与有趣评论

  1. “😂 LLMs本质上是一种推理工具，而不是可信赖的知识来源，因此需要通过其他技术来增强系统的可信度。”
    • 亮点：强调了LLMs的局限性，提出了增强系统可信度的方法。
  2. “🤔 开发者不应放弃，而应设计包含检查、故障恢复和审批机制的工作流程。”
    • 亮点：提出了应对LLMs不确定性的实用方法。
  3. “👀 在某些情况下，使用LLM可能不是最佳选择，简单的UI和SQL查询可能更为合适。”
    • 亮点：质疑了LLMs在某些应用中的必要性，提出了更为简单的解决方案。
  4. “😂 开发者应选择那些即使结果只有80%正确也能带来显著收益且错误答案风险较低的问题。”
    • 亮点：强调了在选择LLMs应用场景时需要考虑的风险和收益。
  5. “🤔 将LLM作为抽象层下的“Oracle”或“Seer”，并将其错误率考虑在内，能够更有效地使用LLM。”
    • 亮点：提出了有效使用LLMs的策略，考虑了其错误率。

情感分析

讨论的总体情感倾向较为复杂，既有对LLMs应用的积极探讨，也有对其必要性和可靠性的质疑。主要分歧点在于LLMs在实际应用中的适用性和可靠性，部分评论者认为LLMs在某些情况下可能并不必要，而另一些评论者则强调了LLMs在自然语言处理方面的优势。这种分歧可能源于对LLMs的不同理解和应用经验。

趋势与预测

  • 新兴话题：未来可能会出现更多关于如何有效限制LLMs责任以提高系统可靠性的讨论和工具。
  • 潜在影响：随着LLMs在应用中的普及，开发者将更加关注如何平衡LLMs的灵活性和系统可靠性，可能会推动更多相关工具和方法的发展。

详细内容：

标题：开发者是否应从大型语言模型（LLMs）手中夺回应用控制权？

在Reddit上，一位开发者分享了其在涉及商业GenAI/LLM相关系统项目中的经历与思考，该帖子获得了众多关注，评论数众多。原帖指出，在工作中随着对LLMs的依赖增加，开发者逐渐失去了对产品的确定性控制，应用错误率从极低提升到了约20%。并以酒店员工聊天机器人和电话自动预订助手这两个应用为例，详细阐述了在开发过程中使用LLM所面临的挑战及解决方案。原帖还询问大家是否有类似经历，或者是否知晓能让LLM应用更可靠的工具或库。

讨论的焦点与观点分析如下：

有人表示自己虽不是专业开发者，但梦想创建一个用于冒险游戏的LLM游戏管理员，并通过限制LLM的信息输入来实现。有人认为可以先在OpenAI或Claude的平台上调整提示词，也有人推荐了SillyTavern项目作为起点。

一位在酒店连锁软件部门工作的人质疑了使用LLM实现部分功能的原因，认为投入大量精力控制LLM却仍保留传统业务逻辑的方式值得商榷。而原帖作者解释称，用户希望通过自然语言与系统交互，这使得LLM成为明显选择，其背后是为了实现信息民主化获取或自动化预订流程。

有人认为对于简单问题，原帖的处理方式正确，复杂系统则可能需要使用代理。也有人指出LLM开发者似乎不明白非IT人员只关心工作能否高效完成，而非与LLM交流。

有人认为应寻找生成内容正确率80%仍有巨大价值且错误回答风险较低的问题，将LLM进行分区处理。还有人提出要定量测量系统输出质量，以优化系统。

有人好奇模型大小及是否需要微调，得到的回复是项目曾使用Llama2-70B，近期尝试用Llama3-8B也能取得不错效果，且微调可能有帮助。

有人认为最终仍需将LLM的结果指向实际数据来源，对让自主代理在系统中造成不确定性表示怀疑。

有人觉得第一个案例本可用简单的UI和SQL查询解决，第二个案例则更有趣，项目开始前需明确LLM的职责并建立基准和测试用例。

有人认为LLM编程热潮可能是科技公司浪费竞争对手时间的手段，也有人直言应停止在工作中使用错误的工具，开发者应精通工具。

总的来说，关于是否应在项目中使用LLM以及如何更好地运用LLM，大家各抒己见，讨论热烈。您对此又有怎样的看法呢？