我认为 discourse-ai API 需要一次回归

开发
1

Discourse AI 现在使用结构化输出来生成内容，但很多 API 提供商并不支持结构化输出，我所在国家几乎所有的 AI 提供商，如 DeepSeek 或 Qwen 都不支持。使用结构化输出导致 API 选择非常有限，仅限于少数主流 AI 提供商。

我认为，如果 Discourse AI 要打破目前提供商选择的限制，放弃结构化输出是必不可少的，没有它实际上并不会有什么东西被破坏。作为一种解决方案，我们可以使用一些简单的唯一分隔符，或者通过提供 JSON Schema 或示例来要求 AI 生成 JSON，但不使用结构化输出，为什么不呢？

1 个赞
2

您能通过其在中国大陆的API端点尝试Moonshot AI Kimi K2吗？

基础API URL看起来是https://api.moonshot.cn/v1。

我们之所以增加了结构化输出的要求，是因为我曾收到过成千上万的投诉，内容涉及模型添加“这是您的摘要”等问题，或者在获取AI助手建议标题列表时解析失败等。现在，随着翻译功能的加入，当您需要信任数百万次的LLM调用而不希望它们在输出中添加任何额外内容时，这个问题变得更加糟糕了。

考虑到可靠性的需求以及结构化输出的普遍可用性，我们在支持此功能的服务商那里做出了这一决定，但我愿意接受一个PR，为OpenAI提供商的API请求添加一个禁用结构化输出的复选框。

1 个赞
3

那会很好，我不是，也不能要求 Discourse 团队，所以只是提出一些建议。

使用旧的“分隔符”解决方案来实现更健壮的解析，一种类似 XML 的原始内容，如下所示：

<SUMMARY_START>
摘要内容。
<SUMMARY_END>

<SUGGESTIONS_START>
<SUGGESTION_START>
建议 1
<SUGGESTION_END>
<SUGGESTION_START>
建议 2
<SUGGESTION_END>
...
<SUGGESTIONS_END>

然后不关心 <START> 和 <END> 之外的任何内容，我相信即使是最愚蠢的生产 AI 模型也能正确处理标签。

并要求 AI 不要添加额外的描述；然后警告管理员，如果打开该复选框可能会出现问题。谢谢。

我不知道 Discourse AI 生成的请求体是什么样的。但如果不是，只需将系统提示放在由 system 角色发送的第一条消息中，将向量数据库查询结果放在下一条 system 角色消息中，并将帖子内容或其他实际数据放在 user 角色消息中。