原贴链接

给我你最难的提示/模式，我将尝试在不使用任何语法之类东西的情况下解决它——直接使用提示。我需要的是：1. 你试图使用的模型——不需要有函数调用能力，普通提示即可。2. 你想要的模式——如果使用TypeScript定义编写更方便的话可以使用。3. 你尝试过的一个提示（因为我需要看到任务是什么）——可以缩写。4. 一个测试输入。你可以链接一个GitHub Gist、Pastebin或者直接写在这里。完全免责声明：我是BAML（https://github.com/BoundaryML/baml）的开发者之一，这使我们能够使用不同于大家在使用pydantic/约束生成（https://www.boundaryml.com/blog/sota - function - calling?q = 0）时所用的提示技术来打破函数调用基准。我们还没有对较小的开源模型进行基准测试，但我们已经看到它们有非常好的性能。

讨论总结

原帖寻求最难的结构化输出提示/模式，希望大家提供相关内容以便其尝试解决。评论者分享了各种观点，包括不同难度的结构化数据提取情况，如从简单到复杂的信息提取挑战；也给出了具体的任务示例，像打印机工单信息提取；还有人提及框架存在的问题如依赖初始输入答案、繁琐和漏洞等；部分评论涉及代码审查相关话题；整体讨论热度不高，话题多样且分散，主要围绕结构化输出相关的技术领域展开。

主要观点

  1. 👍 提取“结构化事物列表”难度因情况而异
    • 支持理由：在不知道事物数量和模式等情况下提取较难，不同情况的提取难度不同。
    • 反对声音：无。
  2. 🔥 多数框架依赖初始输入中的答案存在局限
    • 正方观点：部分答案存在时会有问题。
    • 反方观点：无。
  3. 💡 原帖方法有趣且有用，但问题不只是函数调用
    • 解释：原帖方法有价值，但在缺少参数时询问用户内容等方面也是问题所在。
  4. 💡 对原帖工作表示认可但质疑学习新DSL的必要性
    • 解释：认可原帖工作但认为可能无需学习新DSL就能达成目的。
  5. 💡 希望使用更小且能准确执行任务的模型
    • 解释：目前有模型在任务中有成果，但想找更小且准确的模型。

金句与有趣评论

  1. “😂 在我的经验中，最困难的提取挑战是获取“结构化事物的列表”，特别是当你事先不知道这些事物是只有1个、3个还是10个，或者你不太确定模式的时候。”
    • 亮点：形象地阐述了结构化事物列表提取的困难之处。
  2. “🤔 Most frameworks I’ve seen like this rely on the answers being in the initial input. What if it’s only a partial answer?”
    • 亮点：指出框架依赖初始输入答案存在的潜在问题。
  3. “👀 这是一个非常有趣的方法 - 而且很有用。虽然我认为问题不仅仅是函数调用。”
    • 亮点：肯定原帖方法同时补充了不同观点。
  4. “😉 这里有一个极其困难的提示。给定一个TTTPG（例如OGL的《开拓者》）的规则手册以及一个名称或描述来查找，找到包含信息和简要描述的相关页面。”
    • 亮点：给出了一个特定的困难提示任务。
  5. “💡 Okay I like that you’re working on this but couldn’t you have achieved this without requiring we learn a new DSL 😭”
    • 亮点：表达对原帖工作认可的同时提出质疑。

情感分析

总体情感倾向较为中立。主要分歧点在于对原帖提出的一些概念如BAML、学习新DSL等存在不同看法，有人认可，有人质疑。可能的原因是大家来自不同的技术背景和应用场景，对这些技术概念的需求和理解不同。

趋势与预测

  • 新兴话题：关于BAML能否在多次调用中填充模式等相关功能探讨可能引发后续讨论。
  • 潜在影响：如果关于数据处理、模型选择等方面的讨论深入，可能会对相关技术领域的数据处理效率、模型应用等产生影响。

详细内容：

标题：Reddit 上关于结构化输出提示和模式的热门讨论

最近，在 Reddit 上有一个关于结构化输出提示和模式的帖子引起了广泛关注。原帖作者表示愿意尝试解决大家提出的最难的结构化输出提示和模式，且无需使用语法规则，仅通过直接提示来解决。此帖获得了众多的点赞和大量的评论。

帖子引发的主要讨论方向包括提取复杂数据、处理不同类型的列表和文件、优化模型表现等。文章将要探讨的核心问题是如何应对各种具有挑战性的结构化输出任务，以及不同方法的效果和可行性。

在讨论中，有人提出在提取“结构化事物列表”方面存在很大挑战，特别是在事先不确定列表数量和架构的情况下，比如收据或发票的提取。还有人提到要为不完整的架构让 LLM 添加新字段，处理包含多个不相关或相关结构化事物列表的文档等，难度逐步增加。

有用户表示，多数类似框架依赖初始输入中的答案，若只是部分答案该如何处理。还有用户认为，某些框架在正式测试不足的情况下频繁推送有问题的库，导致相关功能失效。但也有人对新的方法充满期待，希望能以更少的代码和更小的本地模型实现可靠的效果。

比如，有人提到在处理打印机问题的票时，要提取打印机型号、客户面临的问题以及请求的紧急程度。还有人分享了自己在幻想部落游戏中的代码问题，并提供了相关链接。

总之，Reddit 上的这场讨论展现了大家在结构化输出领域面临的各种难题以及对新方法的探索和期待。