原贴链接

有人将多个大语言模型堆叠起来，使一个大语言模型的输出成为下一个的输入吗？我知道可以通过复制粘贴独立完成，但我指的是一种资源，通过它能更轻松地指定工作流和大语言模型的角色，输入一个提示，然后得到一个经过3 - 4种不同方法优化后的单一输出。我目前看到的唯一选择是复制粘贴方法，或者同时将相同的输入插入一堆大语言模型中，同时得到大量基本相似的输出（开放路由器聊天方法）。

讨论总结

原帖探讨是否存在能方便将LLMs堆叠构建工作流的资源，希望能便捷操作得到经过多种方法精炼的单一输出。评论者们积极回应，有的推荐了如OmniChain、WilmerAI、Tlddraw、Dify等资源，有的分享了自己在堆叠LLMs使用中的技巧，还有的表达了和原帖类似的疑问，也有评论者提出了赞同自动转发优化答案的观点，并且有构建了相关工作流引擎的人分享了自己的项目，还有放射科医生分享了自己工作中的AI应用情况，整体氛围比较积极且充满探索性。

主要观点

  1. 👍 存在工作流程序可满足将LLMs堆叠的需求
    • 支持理由：如OmniChain等程序可实现该功能。
    • 反对声音：无。
  2. 🔥 堆叠LLM有效果但操作较繁琐
    • 正方观点：评论者自身经验表明虽然繁琐但效果不错。
    • 反方观点：无。
  3. 💡 需要单一聊天视图使用不同语言模型
    • 解释：方便在不同语言模型下处理用户提问。
  4. 💡 认可自动转发的想法并阐述类似神经网络的操作模式
    • 解释：可以对答案重新评估优化或添加动态因素。
  5. 💡 存在一个用于编码任务的LLM工作流编排引擎
    • 解释：有评论者构建了这样的引擎且提供免费试用链接和开源项目。

金句与有趣评论

  1. “😂 哈哈，刚问了同样的问题。”
    • 亮点：表明有很多人有相同的疑问。
  2. “🤔 它（OmniChain）相当用户友好，是一个直接面向工作流的LLM系统，与本地和专有AI api配合良好。”
    • 亮点：很好地介绍了OmniChain的优点。
  3. “👀 My tips: * look at Griptape custom nodes. Griptape is a commercial LLM agent service, but they’ve released their comfyui nodes for everyone to use for free and they are awesome.”
    • 亮点：分享了Griptape自定义节点的使用技巧。
  4. “😎 asankhs: We have build a full LLM workflow orchestration engine for coding tasks that stacks LLMs, tools and much more.”
    • 亮点：介绍自己构建的工作流编排引擎。
  5. “🤔 RadSwag21: This looks incredible.”
    • 亮点：表达对工作流编排引擎的认可。

情感分析

总体情感倾向是积极的。主要分歧点较少，大家基本都在围绕如何构建LLM工作流、分享资源和经验展开讨论。可能的原因是原帖是一个寻求帮助和分享的话题，吸引了对LLM工作流感兴趣的人积极参与，大家更多是在交流和互相补充信息。

趋势与预测

  • 新兴话题：关于不同模型下“历史记录”如何运作的疑问可能引发后续讨论。
  • 潜在影响：如果关于LLM工作流相关资源和技巧不断丰富完善，可能会对人工智能领域的开发和应用效率有提升作用。

详细内容：

标题：关于 LLM 舒适工作流的热门探讨

在 Reddit 上，有一个关于 LLM 工作流的热门帖子引起了广泛关注。该帖子提出了是否有人将不同 LLM 组合起来，使一个 LLM 的输出成为下一个的输入，并表示想找一种能更便捷地设定工作流和 LLM 角色，输入提示后能得到经过 3 - 4 种不同方法精炼的单一输出的资源。此帖获得了众多的点赞和大量的评论。

讨论的焦点主要集中在以下几个方面： 有人认为可以寻找工作流程序，实际上有不少选择。还提到，专有应用通常会有更好的支持，有更多人力投入开发，其受欢迎程度也意味着有大量优质文档且通常对用户友好。有人分享了自己编写相关程序的经历，是因为有非常具体的用例要实现，而且这不仅是“最终产品”，更是构建个人“贾维斯”系统的基础。也有人对于“专有开源”的选项提出疑问，担心供应商锁定或本地 API 被视为二等公民。

有用户表示在过去一年里经常进行这种操作，虽然有些麻烦但效果很好。比如可以看看 Griptape 自定义节点，它是商业的 LLM 代理服务，但免费发布的舒适 UI 节点很棒，有内存系统和插件工具。还提到 LLM Party 看起来不错但用不了。要设置与大型封闭服务的 API 访问，并经常保存工作流和输出，建立严格的命名约定。建议工作流采取小行动且数量多，对单个查询不要做太多。还可以对查询进行角色设定，以综合出最佳答案。

还有人提出需要一个根据用户问题使用不同语言模型的单一聊天视图，对于结果来自不同模型时的“历史”如何处理存在疑问。有人喜欢自动转发的想法，认为像神经网络一样，一个答案经过另一个 LLM 重新评估来优化。

有人推荐了 Tlddraw ，还有人提到 Dify 。有人表示构建了一个用于编码任务的全 LLM 工作流编排引擎，提供了链接，并有人分享了试用的经历。也有人提出“电话游戏”或“垃圾进，垃圾出”的观点。

在这场讨论中，大家对于 LLM 工作流的实现方式和优化各抒己见，丰富了对于这一话题的探讨。但对于如何选择合适的工具和方法，以及如何解决可能出现的问题，尚未形成完全一致的看法。

那么，您对于 LLM 工作流又有怎样的想法和见解呢？