探索 GPTs：穿风衣的 ChatGPT？

原文 ↗ Hacker News 讨论 ↗

OpenAI 的新“GPTs”——可定制的、基于 ChatGPT 的机器人，可以赋予指令、工具和私有知识库——被视为朝着让 AI 代理对非技术用户更易用迈出的有力但并不均衡的一步。评论者将其与 Assistants API 进行比较，争论它们相较于巧妙的提示工程究竟带来了多少实际价值，并指出检索性能薄弱、隐藏提示不透明，以及与外部数据和 OAuth 集成别扭等现实问题。许多人仍将其主要创新视为 UX 和分发：GPTs 降低了构建和分享专用代理的门槛，同时也引发了关于数据收集、企业控制，以及 AI 介入更多客户与个人交互的新担忧。

GPTs 与 Assistants API / 技术差异

  • 许多人将 GPTs 视为“带了预提示词的 ChatGPT”，也就是自定义系统指令加上可选工具和文件。
  • Assistants API 被描述为更底层：对线程、上下文初始化和 UI 有更多控制，但你必须自己构建前端并处理轮询。
  • 一些人表示，实际上 Assistants 只带来了有限的额外控制；对话流程仍然主要由 OpenAI 驱动。
  • 一个被提到的差异是：多个 Assistants 可以附加到同一个线程，而 GPTs 是单模型的。

Actions、Function Calling 和认证

  • GPTs 可以通过由 OpenAPI 规范支持的“actions”调用外部 API，功能上与 function calling 类似。
  • GPT actions 支持 OAuth，但受域名规则约束；配置起来可能很棘手。
  • POST actions 往往需要反复“Allow/Deny”；一个特殊头部（isConsequential: false）可以减少提示。

RAG / “Knowledge” 与文件处理

  • GPT 的“knowledge”本质上就是 RAG：文件会被分块、嵌入，并存入向量数据库（某些流程里可能是 Qdrant，不过也有人提到 Azure 服务）。
  • 行为似乎与大小有关：小文件可能会直接内联到提示词中；大型集合通常把多个文件合并成单个文本文件效果更好。
  • 一些用户报告检索质量差或不稳定、引用控制不佳以及索引失败，尤其是在文件很多或文件很大时。
  • 原始文本文件通常比复杂格式更好用；PDF/Markdown 则效果时好时坏。

提示词透明度与控制

  • 人们强烈希望有一个用于查看 GPT 提示词和配置的“view source”选项；很多人对隐藏指令和未知 API 感到警惕。
  • 用户指出，只要查询足够巧妙，GPT 提示词经常会泄露；试图隐藏它们通常会被破解。
  • 有人认为，“view source”主要会服务于高级用户，但也可能推动社区驱动的改进。

使用场景与 UX 印象

  • 被提到的用途包括：复古游戏主机、领域专用分析师、培训/工作坊自动化、针对技术文档的 RAG、个人助手，以及使用 JavaScript Code Interpreter 的实验。
  • GPTs 因为对不懂技术、但又难以处理系统提示词和自定义指令的用户带来了巨大的 UX 改善而受到称赞。
  • 也有人认为，与直接向基础模型提问相比，它们只是没必要的“玩具”。

风险、数据与商业担忧

  • 担忧包括：劣质批量内容、企业客户服务推诿、去人性化的效率，以及 OpenAI 将上传文档和用户创造力作为竞争护城河来收集。
  • 对于 GPT 上传的文档是否会被用于模型训练，一些人并不清楚；据称 API 上传不会。