GenAI > Bedrock > InvokeModel与Converse

InvokeModel与Converse

Amazon Bedrock Runtime API 中有两种调用方式， InvokeModel 和 CreateConversation/ConversationInvokeStream (这两个组合起来实现会话功能，通常简称为 “Converse”)

特点：单次请求-响应模式，无状态，适用于所有支持的模型

适用场景：

示例用途：

特点：多轮对话模式；保持对话状态和上下文；流式响应；目前仅支持特定的模型（如 Anthropic 的 Claude）

适用场景：需要持续对话的应用；要求模型记住之前的交互的场景；需要实时、流式响应的应用；复杂的、多步骤的任务

示例用途：

其中 Converse 和 ConverseStream 是两种不同的 API 调用方式，它们的主要区别在于响应的处理方式和适用场景。

特点：同步调用，一次性返回完整响应，适用于较短的对话或不需要实时反馈的场景

工作方式：发送请求后，等待模型生成完整响应，响应作为一个完整的数据包返回

适用场景有：简短的问答、批处理任务、不需要即时反馈的应用

优点是实现简单，易于集成；缺点：对于长回复，可能需要较长的等待时间，不适合需要实时交互的应用

特点：异步流式调用，逐步返回部分响应，适用于需要实时反馈的长对话或交互式场景

工作方式：发送请求后，立即开始接收部分响应，响应以流的形式返回，可以逐步处理

适用场景：实时聊天应用，交互式对话系统，以及需要快速反馈的用户界面

优点是提供更快的初始响应时间，允许实时处理和显示部分响应，适合长对话和需要即时反馈的应用

缺点是实现相对复杂，需要处理流式数据，可能需要额外的逻辑来组合和管理部分响应

如果实时性和交互性很重要，ConverseStream 可能是更好的选择；如果简单性和易集成性更重要，Converse 可能更合适。

使用 InvokeModel ：需要处理独立的、无关联的请求；应用不需要维护对话状态

使用 Converse ：构建对话式应用；需要模型记住之前的交互内容；希望获得流式的、实时的响应

需要注意的是，虽然 InvokeModel 不直接支持多轮对话，但可以通过在应用层面管理对话历史，并在每次调用时将相关上下文包含在提示中来模拟对话功能。这种方法虽然灵活，但可能不如使用专门的 Converse API 高效和方便。后面的实验将有这部分介绍

无论是InvokeModel 或是Converse API，都会在CloudTrail中做记录：

但是不会将用户的输入以及Prompt记录下来，只会记录调用是否成功，或失败原因。

当我们在Bedrock Playground提问问题时，调用的是ConverseStream API：

它的payload会把历史的问题及回答传入给bedrock API：

返回结果是event stream:

在cloudtrail日志里，能看到相应事件：