最新

在构建依赖于大型语言模型（LLMs）的工作流程时，我们通常使用结构化输出来处理程序化用例，例如将发票转换为行、将会议记录转换为工单，甚至将复杂的PDF文件转换为数据库条目。 模型可能会返回您想要的架构，但其中的虚构值（例如，`invoice_date`可能偏差2个月，或转录数组的顺序错误）。虽然JSON是有效的，但其中的值却不正确。 如今，结构化输出在使用LLMs时占据了重要部分，尤其是在构建确定性工作流程时。 当前的结构化输出基准（例如，JSONSchemaBench）仅验证JSON架构和类型的通过率，而不检查生成的JSON中的实际值。 因此，我们设计了结构化输出基准（SOB），通过测量JSON架构的通过率、类型以及在文本、图像和音频三种模式下的值准确性来解决这一问题。 在我们的测试集中，每条记录都与一个JSON架构和一个经过人工和LLM交叉验证的真实答案配对，因此缺失或虚构的值将被视为错误。 开源方面表现相当不错，GLM 4.7紧随GPT 5.4之后排名第二。 我们注意到不同模式之间的排名变化：GLM-4.7在文本领域领先，Gemma-4-31B在图像领域领先，Gemini-2.5-Flash在音频领域领先。 例如，GPT-5.4在文本中排名第三，但在图像中排名第九。 模型大小也不是一个预测因素：Qwen3.5-35B和GLM-4.7在值准确性上超越了GPT-5和Claude-Sonnet-4.6。Phi-4（14B）在文本上超过了GPT-5和GPT-5-mini。 结构化幻觉是最难解决的bug。这类值在类型上是正确的、在架构上是有效的，并且看起来合理，因此它们往往会逃过大多数保护措施。例如，在一条音频记录中，真实值是“target_market_age”: “15到35岁”，而模型返回的是“25到35”。没有字段级检查，这种错误是不可见的。 我们的目标是成为最优秀的通用模型，以处理确定性任务，而确定性的一项关键方面是可控且一致的输出结构。改善结构化输出的第一步是对其进行测量，并与最佳标准进行对比。

嗨，HN——我开发了Platypus，因为我想将笔记记录、实时转录和知识库管理结合在一个应用程序中。它是Granola / Notebook LM的免费本地替代品。这是一个基于Tauri/Rust的桌面应用程序，通过whisper.cpp进行设备上的会议转录，使用TipTap记录笔记，并在您的知识库中进行按项目的HNSW向量搜索。您可以使用自己的大语言模型（如Claude、OpenAI、Gemini或本地的Ollama）。 有几个有趣的点需要弄清楚： Zoom/Teams会议的自动检测是通过进程检查实现的——Zoom仅在活跃通话期间生成CptHost（而不是在应用程序仅打开时），Teams则是通过audio.mojom.AudioService子进程。无需Zoom/Teams API访问。当地的Whisper在Mac上运行良好。旧款PC的体验不推荐，因此我内置了API转录切换功能，以防本地模型运行缓慢。 代码库：<a href="https://github.com/pixelsmasher13/platypus" rel="nofollow">https://github.com/pixelsmasher13/platypus</a> 网站：<a href="https://platypusnotes.com" rel="nofollow">https://platypusnotes.com</a> 欢迎反馈！