tags:

很多人以为大模型API只有聊天接口，其实4SAPI文档里已经列出了文本生成、上下文阅读、图片理解、图片生成、函数调用、Embedding、TTS、语音转文本、内容审核、PDF文件分析、深度研究、联网搜索、结构化输出等多类接口。选对接口，比单纯换模型更重要。

这篇按实际业务场景拆一下：什么时候用chat/completions，什么时候用embeddings，什么时候该走TTS或PDF分析。

1. 文本生成：默认入口

最常用的是：

POST https://4sapi.com/v1/chat/completions

适合：

4SAPI文档中说明，中转里的模型已适配/v1/chat/completions，只需要把模型名称完整复制到model参数即可使用。

最小请求：

{
  "model": "claude-sonnet-4-5-20250929",
  "messages": [
    {
      "role": "user",
      "content": "用三句话总结这段材料。"
    }
  ]
}

1.1 文本生成不只是聊天

文本生成接口经常被叫做“聊天接口”，但真实业务里它能做很多事：

这类任务最好不要都写成开放式问答。比如分类任务应该限制输出枚举，抽取任务应该要求JSON，摘要任务应该限制字数。接口相同，但提示词和参数设计会决定稳定性。

1.2 什么时候要用结构化输出

如果模型回答要给人看，自由文本可以接受；如果模型回答要给程序继续处理，就应该优先考虑结构化输出。OpenAI官方文档把Structured Outputs单独作为指南，就是因为业务系统需要确定字段，而不是一段“看起来像JSON”的文本。

适合结构化输出的场景：

示例要求：

只返回JSON，不要Markdown。
字段包括 category、confidence、reason。
category只能是 refund、bug、consult、other。
confidence是0到1的小数。

2. 图片理解：让模型看图

图片理解也通常走OpenAI兼容聊天接口：

POST https://4sapi.com/v1/chat/completions

适合：

使用时要确认所选模型支持视觉输入。不要把纯文本模型拿来做图片理解，否则要么报错，要么忽略图片。

2.1 图片理解的输入质量很重要

很多图片理解效果差，不是模型差，而是输入图像不适合：

如果你要做截图识别或表格提取，建议先对图片做预处理：裁掉无关区域，提高分辨率，按顺序编号，必要时把多张图拆成多次请求。

2.2 图片理解适合“辅助判断”，不适合无校验入库

比如让模型识别发票、合同截图、商品参数图时，输出结果最好再经过规则校验：

不要让图片理解结果直接写入财务、订单或合同系统。模型可以辅助提取，最终入库要有校验。

3. 函数调用 tools：让模型输出可执行意图

函数调用适合需要模型“决定调用哪个工具”的场景，比如：

请求仍然常见于：

POST https://4sapi.com/v1/chat/completions

区别是你会传入tools参数，让模型返回工具调用意图。生产中要注意：模型只负责生成调用意图，真正执行工具前必须做权限校验和参数校验。

3.1 工具调用的正确边界

函数调用不是让模型真的去执行数据库查询或发邮件，而是让模型输出“它想调用哪个工具，以及参数是什么”。真正执行工具的是你的程序。

安全边界应该是：

模型提出工具调用 -> 程序校验工具名 -> 程序校验参数 -> 程序检查权限 -> 执行工具 -> 把结果返回模型

比如模型想调用refund_order，程序要检查订单是否属于当前用户、金额是否允许自动退款、是否需要人工审批。不要因为模型说“应该退款”就直接执行。

3.2 工具调用适合和结构化输出一起用

复杂Agent里可以把工具调用和结构化输出结合起来：

这能把“模型自由发挥”的部分限制在可控范围内。

4. Embedding：知识库和相似度检索

Embedding接口是：

POST https://4sapi.com/v1/embeddings

适合：

Embedding不是聊天模型。它的输出是向量，不是自然语言回答。Dify、LangChain、LlamaIndex等知识库框架里，Embedding模型通常要单独配置。

4.1 Embedding的核心是“先召回，再生成”

知识库问答通常不是把所有文档丢给聊天模型，而是：

文档切分 -> 生成Embedding -> 存入向量库
用户提问 -> 问题Embedding -> 相似度检索 -> 召回片段 -> 聊天模型回答

OpenAI官方Embedding文档也强调向量可用于搜索、聚类、推荐、异常检测等任务。它更像“语义索引”，不是回答引擎。

4.2 影响知识库效果的不是只有模型

知识库效果由多因素决定：

如果知识库答得不好，不要第一时间换聊天模型。先检查召回片段是否正确。

5. TTS与语音转文本

4SAPI文档里列出了文本转语音和语音转文本接口，例如：

POST https://4sapi.com/v1/audio/speech

适合：

音频任务通常不是按普通聊天逻辑计费和处理，接入前要先看模型价格和任务限制。长音频建议分段处理，避免超时和失败后重跑成本过高。

5.1 TTS要关注的不只是声音好不好听

文本转语音上线时要看：

如果是客服播报，建议短句生成；如果是课程音频，建议按段落生成并缓存。重复生成同一段音频会浪费成本。

5.2 语音转文本要处理噪声和分段

会议录音、访谈、客服录音都可能有噪声、多人说话和停顿。建议：

语音转文本不是最终答案，只是把音频变成可处理文本。后续摘要、分类、质检还要走文本生成或结构化输出。

6. 内容审核与安全前置

内容审核接口常见路径是：

POST https://4sapi.com/v1/moderations

适合：

如果你的产品面向真实用户，建议把审核放在链路前后两端：

用户输入审核 -> 模型生成 -> 输出审核 -> 展示/发布

这不是为了增加复杂度，而是为了减少合规和品牌风险。

6.1 审核不是只审用户输入

真实产品里至少有三类内容要审：

OpenAI官方也把Moderation作为独立能力介绍。它不是为了替代业务规则，而是作为安全链路的一部分。

6.2 审核结果要和业务策略结合

审核接口给出风险信号后，业务可以有不同动作：

低风险：正常进入模型
中风险：提示用户修改或进入人工审核
高风险：拒绝处理并记录安全日志

不要把审核做成“一刀切”，否则会误伤正常用户；也不要完全忽略审核，否则风险会累积到发布环节。

7. PDF分析与联网搜索

4SAPI文档中还列出了PDF文件分析、deep-research和Web search等能力。其中联网搜索相关能力可能使用Responses接口：

POST https://4sapi.com/v1/responses

适合：

这类任务更要注意数据隐私。不要把合同、身份证、医疗记录、客户名单等敏感材料直接上传到公共链路；确实要用时，先做脱敏，并确认团队的合规要求。

7.1 PDF处理要先判断“文档类型”

PDF大致分三类：

如果是文本型PDF，先用程序提取文字再交给模型，通常更省成本；如果是扫描件，才需要视觉或PDF分析能力。不要所有PDF都直接丢给多模态模型。

7.2 PDF问答建议保留引用位置

企业文档问答最怕“答得像真的，但找不到出处”。建议在处理PDF时保留：

生成回答时要求模型附上来源位置。这样用户能回到原文核对，也方便审计。

8. 接口选择表

可以按这张表快速判断：

普通问答/写作/代码解释 -> /v1/chat/completions
看图/截图理解 -> /v1/chat/completions + 视觉模型
工具调用/Agent -> /v1/chat/completions + tools
知识库向量化 -> /v1/embeddings
文本转语音 -> /v1/audio/speech
内容审核 -> /v1/moderations
联网搜索/深度研究 -> /v1/responses 或对应文档接口

选接口前，先问自己：我要的是自然语言回答、向量、音频、审核结果，还是工具调用意图？答案不同，接口就不同。

9. 一个多模态客服质检方案

把这些接口组合起来，可以做一个客服质检流程：

客服录音 -> 语音转文本
聊天截图 -> 图片理解
对话文本 -> 内容审核
质检规则 -> 文本生成/结构化输出
违规片段 -> 人工复核
质检报告 -> TTS播报或工单归档

这里没有一个模型包打天下。不同接口处理不同环节，中转站负责统一调用入口和成本记录。

10. 总结

4SAPI这类大模型API中转站的价值，不只是把Claude、GPT、Gemini、DeepSeek等模型放到一个入口里，更在于让文本、图片、音频、PDF、搜索、Embedding等能力可以用统一思路接入。对开发者来说，真正高效的方式是先按任务选接口，再按成本和效果选模型。

下一篇可以继续拆“联网搜索与Deep Research”，专门讲怎么做可追溯的资料调研型应用。

参考资料：