您尚未登录账户
您的企业账号申请正在审核中
Spotify如何在Sidekick中改进其LLM聊天机器人
Spotify的工程师Ates Goral认为，虽然使用大型语言模型（LLM）聊天机器人可以带来创新的解决方案，但为了使用户体验尽可能自然，需要付出一些特定的努力，以防止渲染延迟和降低延迟。
由于特殊的Markdown字符（如）在完整表达式（例如，直到收到）之前是模棱两可的，将LLM返回的Markdown响应进行流式处理会导致渲染延迟。同样的问题也适用于链接和所有其他Markdown操作符。这意味着Markdown表达式在完整之前无法正确渲染，这意味着在短时间内Markdown渲染不正确。
为了解决这个问题，Spotify使用了一个缓冲解析器，在Markdown特殊字符之后不发出任何字符，并等待Markdown表达式完成或接收到意外字符。
在进行流式处理时，需要使用一个有状态的流处理器，它可以逐个消耗字符。流处理器要么按照收到的字符顺序传递字符，要么在遇到类似Markdown的字符序列时更新缓冲区。
尽管原则上这种解决方案相对容易手动实现，但支持完整的Markdown规范需要使用现成的解析器，Goral说道。
另一方面，延迟主要是由于需要进行多次LLM往返以消耗外部数据源扩展LLM的初始响应。
LLM对于一般的人类语言和文化有着深入的了解，但它们并不是获取最新、准确信息的好来源。因此，我们告诉LLM在需要超出其了解范围的信息时告诉我们，通过使用工具来实现。
换句话说，基于用户输入，LLM提供的初始响应还包括要咨询的其他服务，以获取丢失的信息。当这些额外的数据接收到时，LLM生成完整的响应，最终显示给用户。
为了防止用户等待直到所有外部服务都响应，Sidekick使用了“卡片”的概念，即占位符。Sidekick渲染了从LLM收到的初始响应，包括任何占位符。一旦附加请求完成，Sidekick将占位符替换为接收到的信息。
Sidekick实现的解决方案充分利用了这个工作流程中固有的异步性，并将响应解多路复用步骤与Markdown缓冲解析器集成在一起。
