Response streaming

📚 学习笔记：LLM 流式传输 (Streaming)

一、 核心问题 (The Problem)

• 延迟问题 (Latency): 在传统的请求-响应模式中，用户发送消息后，等待 Claude 生成完整回复的时间可能很长（例如 ≥ 10 秒，甚至 ≥ 30 秒）。
• 用户体验 (UX): 长时间等待会降低用户体验。用户期望在输入消息后能立即看到响应的开始。

二、 流式传输原理 (Streaming Mechanism)

• 定义: 流式传输允许模型在生成回复的过程中，将内容以小块（Chunk）的形式实时发送给客户端。
• 工作流程:
• 服务器向 Claude 发送初始用户消息。
• Claude 立即发送一个初始信号（不含文本内容），表示已接收请求并开始生成。
• 服务器开始接收一系列事件流 (Stream of Events)。
• 每个事件包含生成回复的一个小片段（Chunk）。
• 服务器将这些片段立即转发给前端应用，实现文本的逐块显示。
• 效果: 用户在聊天界面上会看到文本是“分块”或“逐字”出现，而非等待整个回复完成。

三、 技术实现 (Implementation)

• 低级实现 (Manual/Low Level):
• 使用 client_messages. create(... , stream=True)。
• 需要遍历所有事件，并手动检查事件类型（如 raw_content_block_delta）来提取实际的文本内容。
• （注：代码复杂，需要额外逻辑判断）
• 高级实现 (Recommended/High Level):
• 使用 with client_messages. stream(... ) as stream: 结构。
• 通过 for text in stream. text: 迭代，SDK 会自动提取并提供我们关心的文本片段。
• （注：代码简洁，直接获取所需文本）
• 完整消息获取:
• 在流结束后，可以使用 stream. get_final_message() 方法，将所有接收到的片段重新组合成一条完整的最终消息，用于数据库存储或后续处理。

Takeaways

• 流式传输（Streaming）的目的是解决传统请求-响应模式中因等待完整回复而导致的延迟高（≥ 10 秒）和用户体验差的问题。
• 流式传输的工作原理是在模型生成回复的过程中，将内容以小块（Chunk）的形式实时发送给客户端。
• 推荐的高级实现方式是使用 with client_messages. stream(... ) as stream: 结构，通过 for text in stream. text: 直接迭代获取文本片段，代码简洁。
• 在流传输结束后，可以使用 stream. get_final_message() 方法将所有接收到的片段重新组合成一条完整的最终消息。