打开网易新闻 查看精彩图片

LINE电商客服有个老毛病:用户问"我之前买的那件夹克",AI只能复读数据库里的文字——"棕色飞行员夹克,1月15日下单"。用户想确认的是"是不是那件带金属拉链的",AI却永远答不到点上。

这个盲区存在了整整三年。直到Gemini上个月推送的Multimodal Function Response(多模态函数响应),才让函数返回值里能塞进去图片字节流。

传统架构的卡点在哪

传统架构的卡点在哪

Function Calling的链条很标准:用户提问→Gemini判断要调函数→执行查询→返回JSON→Gemini组织语言回复。问题出在第四步——JSON是纯文本,AI只能"听说"夹克长什么样,从没"见过"。

实际场景更尴尬。数据库里存着三件棕色夹克,用户嘴里的"那件"可能是任意一款。AI没有视觉锚点,只能把三件都列出来让用户自己挑。客服机器人的价值,在这种时刻直接归零。

开发者不是没试过绕路。有人把图片URL塞进JSON,让前端单独渲染;有人干脆不做确认环节,赌用户记忆力好。这些补丁要么破坏对话连贯性,要么增加用户操作成本。

多模态响应改了哪一步

多模态响应改了哪一步

打开网易新闻 查看精彩图片

新架构只动了一个环节:函数返回值从纯JSON变成JSON+媒体文件。JPEG、PNG、WebP、PDF都能塞进去,Gemini在生成下一轮回复时,会同时读取结构化数据和图像内容。

流程变成:用户提问→Gemini调函数→执行查询→返回"订单数据+商品照片"→Gemini看图说话→回复用户。

关键变化在最后一环。Gemini不再只是复述"棕色飞行员夹克",而是能描述"轻量化尼龙材质,两侧有金属拉链口袋"——这些细节原本只存在于图片里,不在数据库字段中。

官方文档列出的支持格式很克制:图片三类,文档一类。但覆盖的场景已经够广:电商看图识货、医疗读检验报告、设计审UI截图,所有需要"函数返回视觉数据给AI分析"的环节都能用上。

实测:同一句话,两种答法

实测:同一句话,两种答法

我用LINE Bot搭了个demo,对比传统模式和多模态模式的差异。

用户输入:"帮我看看之前买的那件夹克"。

打开网易新闻 查看精彩图片

传统Bot回复:"您于1月15日购买棕色飞行员夹克一件,订单号ORD-2026-0115,金额新台币1890元,已送达。"

多模态Bot回复:"从照片来看,这是棕色飞行员夹克,轻量化尼龙材质,两侧配有金属拉链口袋。这是您1月15日的订单ORD-2026-0115,金额新台币1890元,已送达。"附带商品实拍图。

差距不在信息量多寡,而在确认效率。用户问"是不是那件",多模态Bot能直接给视觉证据;传统Bot只能让用户去翻历史订单自己核对。

更隐蔽的收益是容错。当数据库里存在相似商品时,视觉描述能帮AI区分"用户记得的那件"和"系统查到的多件",减少误确认导致的售后纠纷。

落地时的三个坑

落地时的三个坑

第一,图片传输有成本。函数返回的字节流会占用token额度,高清商品图如果不做压缩,单次调用可能吃掉几万token。实测建议把图片控制在500KB以内,或者先传缩略图,用户需要时再调原图。

第二,延迟感知明显。传统Function Calling的响应时间在1-2秒,加上图片上传和视觉分析后,端到端延迟可能飙到4-5秒。LINE的聊天界面没有typing indicator,用户容易以为机器人挂了。

第三,幻觉风险转移。Gemini看图时可能过度解读,比如把"金属拉链"描述成"银色五金件",用户收到货发现是枪黑色,反而引发投诉。需要在prompt里明确约束描述边界,只提确定可见的特征。

目前这个功能在Gemini 1.5 Pro和Flash版本都已开放,LINE Messaging API的对接没有额外门槛。但据我观察,国内电商客服场景还没大规模落地——是成本账算不过来,还是产品经理没意识到确认环节的价值?