WebSocket 在大模型应用中的实战场景
WebSocket 的双向通信特性在大模型（LLM）应用中有非常实际的价值。国内开发者在对接国外大模型 API（如 OpenAI）时面临几个挑战：网络访问受限、API Key 安全、内容合规审核。这些挑战恰好可以通过代理 + WebSocket 的组合方案来解决。
核心问题：Stream 类型响应与内容审核的冲突
大模型的 API 响应普遍采用 SSE（Server-Sent Events）流式格式，数据是一个字一个字"吐"出来的，而不是一次性返回完整结果。这给内容审核带来了难题：
- 一次性响应：可以等完整数据返回后，将整段文本发送给第三方内容审核平台（如腾讯云、阿里云的内容安全服务）进行检测，确认安全后再返回给用户
- 流式响应：每个 token 都要发送一次审核请求，经济成本高、性能差、用户等待时间长
两种审核策略
方法一：前置审核（强审核）
服务端缓存完整的 stream 数据（如存入 Redis），等数据全部接收完毕后发送给内容审核平台，确认安全后再返回给用户。
- 优点：安全性高，违规内容不会展示给用户
- 缺点：用户需要等待完整响应，失去了 stream 模式提升体验的意义
- 适合场景：图片生成、文件处理等本身就需要较长等待时间的场景
方法二：后置审核（弱审核）
允许 stream 数据先直接展示给用户，同时将完整数据发送给审核平台。如果审核结果发现违规内容，通过 WebSocket 从服务端主动推送消息给前端，前端将敏感内容替换为星号或删除。
- 优点：用户体验好，保留了 stream 的即时感
- 缺点：用户可能短暂看到违规内容（"一闪而过"）
- 适合场景：文本对话、代码生成等场景
WebSocket 在后置审核中的角色
用户请求 -> 服务端（proxy 代理） -> 大模型 API
|
stream 响应
|
用户 <------ 直接展示 <-------- 服务端缓存数据
|
异步发送给审核平台
|
审核结果返回（如有违规）
|
WebSocket 推送 -> 前端替换/删除内容
text
关键点：服务端需要知道往哪个 WebSocket 连接上发送消息。这就需要在用户建立 WebSocket 连接时，将用户身份（userId/token）与 WebSocket 连接实例绑定起来。
为什么需要代理层
直接从用户侧请求大模型 API 存在三个问题：
- 网络不通：国内无法直接访问部分国外 API
- Key 泄露风险：API Key 暴露在前端代码中，用户可以无限制调用
- 无法做内容审核：前端直连大模型，服务端无法介入审核流程
通过在服务端加一层代理（Proxy），所有请求先到我们的服务器，由服务器转发给大模型 API，同时可以在服务端进行内容审核、请求频率限制、用量统计等操作。
↑