haystack 聊天消息内容仅支持字符串,不允许用户传递图片,

5lhxktic  于 4个月前  发布在  其他
关注(0)|答案(7)|浏览(66)

您的功能请求是否与问题相关?请描述。

在与我们的机器人交谈时,用户被允许发送一张图片。这张图片被发送到视觉启用的LLM机器人。Haystack ChatMessage类content只允许字符串,但它需要允许一个列表被传递。这里是Haystack参考的OpenAI页面,其中content允许数组,image_url可以通过这种方式发送。

描述您希望解决的问题

ChatMessage能够处理传入的图片。

描述您考虑过的替代方案

不使用生成器组件是我能探索的唯一其他替代方案。

附加上下文

Haystack的ChatMessage content:链接
OpenAI的聊天消息参数:链接
如何从生成器中获取ChatMessage的内容:链接

nkhmeac6

nkhmeac61#

我会尝试添加这个功能:)

xa9qqrwz

xa9qqrwz2#

我已经审查了基本代码,并建议我们允许将“ChatMessage”的“内容”设置为包含“str”、“Path”或任何用于编码图像的类型的列表。这将要求我们重写“to_openai_format”方法,并在涉及图像的调用中将图像处理与“base64”相结合。我们还需要解决序列化问题,但一旦#7849合并到主分支,我们就可以避免合并冲突,然后再处理这些问题。

主要挑战是在输入列表中准确地区分图像和文本,尤其是当输入是字符串时。如果知道您希望支持哪些数据类型来表示图像,将会很有帮助。我会在提到的PR合并后开始着手处理这个问题。

5ktev3wc

5ktev3wc3#

主要挑战将是在输入列表中准确地区分图像和文本,尤其是当输入是字符串时。了解您希望支持哪些数据类型对于图像会有所帮助。
我认为我们不应该尝试自己提取这些信息。我们应该让用户指定。我的想法是创建一个ContentPart类,包含type、text、image_url、base_64和detail。然后在这个类中添加一些辅助方法来帮助格式化。
基本上,我们可以允许这样的操作:

message = ChatMessage.from_user([
    ContentPart.from_text("What’s in this image?"),
    ContentPart.from_image_url("example.com/test.jpg"),
    ContentPart.from_base64_image(base64_image)
])

我们还应该研究在ChatMessage中弃用Functions并支持Tools,因为这也发生了变化。

im9ewurl

im9ewurl4#

我将实现这个功能。关于函数的弃用,我们可以单独开一个问题来处理。

2exbekwf

2exbekwf5#

主要挑战将是在输入列表中准确地区分图像和文本,尤其是当输入是字符串时。了解您希望支持哪些数据类型对于图像会有所帮助。
我认为我们不应该尝试自己提取这些信息。我们应该让用户指定。我的想法是创建一个ContentPart类,包含type、text、image_url、base_64和detail。然后在这个类中添加一些辅助方法来帮助格式化。
基本上,我们可以允许这样的内容:

message = ChatMessage.from_user([
    ContentPart.from_text("What’s in this image?"),
    ContentPart.from_image_url("example.com/test.jpg"),
    ContentPart.from_base64_image(base64_image)
])

我们还应该研究在ChatMessage中弃用Functions并支持Tools,因为这也发生了变化。
我同意这个方向。我们需要查看所有LLM提供商的多模态消息格式,并推导出共同的分母。从简短的快速浏览来看,我相信这些多模态/多部分消息都是各种格式(模式)的json有效载荷。所以让我们想出一个漂亮的抽象(如上面提到的ContentPart想法),抽象实现细节,看看它们如何Map到各种LLM提供商的数据结构。

holgip5t

holgip5t6#

我们可以让它变得更简单。
目前,模型可以接收和生成以下内容:

  • 文本
  • 图片
  • 音频
  • 视频
  • 所有上述内容的异构列表

我们已经拥有了定义上述内容的所有必要抽象。
str 显然是用于文本。
haystack.dataclasses.ByteStream 是用于图片、音频和视频的。
然后是 List[Union[str, ByteStream]] 列表。
鉴于我们说 ChatMessage.content 类型应该是 Union[str, ByteStream, List[Union[str, ByteStream]]]
这在高层次上抽象了模型接收和生成的所有支持的数据类型。如果模型 X 需要以某种格式输入或生成输出,其生成器将处理转换,但这是实现细节。
在我看来,引入新的类或新的抽象并不是正确的方法。

klsxnrf1

klsxnrf17#

我喜欢你解决方案的简洁性,但我刚刚阅读了'ByteStream'的代码,我们应该期望元数据用一些标志来填充内容类型,否则我们将无法区分。这就是为什么我认为'ContentPart'的方法更容易处理,并允许我们为不同格式提供兄弟输入类型。
一旦#7849合并到主分支,我将立即进行这个实现。

相关问题