原贴链接

尝试使用大语言模型（LLMs）根据给定模式将文本转换为JSON输出。尝试了Jsonformer和许多预训练模型，但它在JSON输出的值字段中给出了错误输出。最后根据这篇文章选择了Outlines：[使用大型语言模型进行引导式文本生成](https://medium.com/productizing - language - models/guided - text - generation - with - large - language - models - d88fc3dcf4c)，它一直能给出正确的JSON模式输出（键的值不是，因为从给定文本中识别是大语言模型的工作）。由于我正在进行的项目的限制，我不能使用大型大语言模型，因为我必须将大语言模型本地加载到各个机器上，而不使用云或第三方API。虽然GPT - 4的函数调用给了我关于模式和值最准确的结果，但它是闭源且依赖云的，所以不考虑它。我需要的是对于以下限制的任何一种或组合方法的意见：一个轻量级（<8B参数）的开源或可免费使用的模型；与在单个机器上本地部署的兼容性（最好有GPU支持）；在有限数据集上预训练/嵌入的潜力；如果链/代理有助于提取过程的选项。示例JSON模式（此处省略具体模式内容）。示例输入输出（此处省略具体示例内容）

讨论总结

原帖寻求满足如轻量级、开源、本地部署等约束条件的文本到JSON转换的模型或方法。评论者们纷纷给出自己的建议，包括推荐不同的模型如Gemma2、qwen2.5等，也有推荐使用相关技术或工具如Llama.cpp with grammar、Guidance等。还有人分享自己的测试经验，如对多个模型进行测试后的性能比较，以及在处理JSON样本时的一些设置经验。期间也有个别评论偏离主题，提出用编程语言类型系统替代模式的想法。总体氛围是积极地探讨与分享。

主要观点

  1. 👍 Gemma2 9B在类似任务的性能表现出众，与4o - mini相当
    • 支持理由：多人测试得出该模型在小于700亿参数模型里表现出色，可能与对JSON提取的调校有关
    • 反对声音：该模型存在上下文大小受限的缺点，如vLLM只能做到4K，用特殊技术才能达到8K
  2. 🔥 推荐研究Llama.cpp with grammar来解决原帖需求
    • 正方观点：为原帖寻求解决方法提供了一个方向
    • 反方观点：未提及
  3. 💡 Outlines会使生成速度变慢
    • 解释：有评论者测试发现使用vLLM时，在RTX3060上吞吐量会减半
  4. 💡 Hermes 3 8B处理JSON样本效果好
    • 解释：评论者用其处理数百万个JSON样本，只有小部分响应不符合模式，认为不需要再找其他模型
  5. 💡 推荐qwen2.5 8或14b模型用于结构化输出
    • 解释：被认为在结构化输出方面表现出色

金句与有趣评论

  1. “😂 Gemma2 9B wiped the floor with all other models, was toe to toe with 4o - mini for performance (performance being defined as "don’t miss stuff when converting" in this instance)”
    • 亮点：生动地描述了Gemma2 9B在性能上远超其他模型的情况
  2. “🤔 The annoying thing about Outlines is how slow it makes generation, with vLLM I was seeing througput drop to half on my rtx3060 and I ended up disabling it unless json schema validation failed then id just go again with it on”
    • 亮点：详细阐述了Outlines使生成速度变慢这一问题及自己的应对方式
  3. “👀 我测试过30多个用于从自由格式文本中提取搜索条件的模型，在小于700亿参数的模型里，只有Gemma2:9b这个模型表现出色。”
    • 亮点：表明测试的模型数量多，从而突出Gemma2:9b的优势
  4. “👀 我的怀疑是，JSON提取是Gemma2调校的一个重要部分，在同类模型中，它在这个特定任务上有着异常出色的表现。”
    • 亮点：对Gemma2在JSON提取任务表现出色提出了可能的原因
  5. “👀 确保你的重复惩罚设置为1.00（即禁用），应该就没问题了。”
    • 亮点：给出了使用Hermes 3 8B处理JSON样本时的一个有效设置经验

情感分析

总体情感倾向是积极的。主要分歧点在于不同模型的性能表现，例如对于qwen2.5模型，有人推荐其8或14b版本在结构化输出方面表现出色，但也有人尝试其1.5B - Instruct版本未得到准确结果。可能的原因是不同版本的模型在功能和性能上存在差异，以及不同的测试场景和数据集也会影响模型的表现。

趋势与预测

  • 新兴话题：nuextract与其他工具如outlines或者llamacpp结构化语法结合使用的可能性。
  • 潜在影响：如果能找到满足原帖约束条件的理想模型或方法，将有助于文本到JSON转换相关项目的本地部署，降低对大型闭源模型（如GPT - 4）的依赖，对相关自然语言处理领域产生积极影响。

详细内容：

标题：探索轻量级开源 LLM 以实现自定义模式的文本到 JSON 转换

在 Reddit 上，有一篇关于尝试使用轻量级开源 LLM 将文本转换为特定 JSON 输出的热门讨论。该帖子作者尝试了多种模型和方法，最终选择了 Outlines，但也提到了其中的一些问题。此帖获得了众多关注，评论众多。

帖子主要探讨了在特定约束条件下寻求合适的文本到 JSON 转换方法，这些约束包括：需要一个轻量级（小于 8B 参数）、开源或免费使用的模型，能够在本地单机部署（最好支持 GPU），有在有限数据集上进行预训练/嵌入的潜力，以及具备有助于提取过程的链化/代理选项。

讨论焦点与观点分析： 有人测试了 Mistral 0.3、Llama 3.1、Nemo、Phi 和 Gemma2 等模型，发现 Gemma2 9B 在性能上表现出色。但也有人指出 Outlines 会使生成速度变慢，使用 vLLM 时在 rtx3060 上的吞吐量会减半。 有人提到最新的 7B - 9B 模型在遵循指令和生成 JSON 输出方面已经非常出色，清晰的系统提示和足够的示例能提高成功率。但对于错误部分，可根据情况使用相应方法处理。 还有人推荐了 Llama.cpp 与语法结合的方式，以及 Hermes 3 8B 等模型，并分享了相关使用经验。 对于 Gemma2，有人怀疑其在 JSON 提取方面有针对性的优化，所以在同类模型中表现突出，但也存在上下文大小受限的问题。

总体而言，大家在讨论中对于不同模型的性能和适用场景各抒己见，共同探索在给定约束下的最佳解决方案。

希望这些讨论能为正在面临类似问题的人提供有价值的参考和思路。