Spotify工程师Ates Goral探讨LLM聊天机器人的用户体验优化

在使用大型语言模型（LLM）聊天机器人时，Spotify工程师Ates Goral指出，为了提供尽可能自然的用户体验，需要在防止渲染抖动和减少延迟方面做出特定努力。

问题：Markdown流式传输导致的渲染抖动

LLM返回的Markdown响应在流式传输时会导致渲染抖动。原因是特殊的Markdown字符（如*）在接收到完整表达式之前是模糊的。例如，在接收到结束的*之前，Markdown表达式无法正确渲染。这同样适用于链接和其他Markdown操作符。因此，Markdown表达式在完整接收之前无法正确渲染，导致短时间内渲染不准确。

解决方案：缓冲解析器

为了解决这一问题，Spotify使用了缓冲解析器。该解析器在遇到Markdown特殊字符后不会立即发出字符，而是等待直到完整的Markdown表达式接收完毕或接收到意外字符。这种方法需要使用有状态的流处理器，逐字符处理输入。流处理器要么直接传递字符，要么在遇到类似Markdown的字符序列时更新缓冲区。

尽管这个解决方案在原理上相对容易手动实现，但Goral指出，要支持完整的Markdown规范，需要使用现成的解析器。

延迟问题及其解决方案

延迟主要是由于需要多次往返LLM以获取外部数据源来扩展LLM的初始响应。LLM虽然对通用人类语言和文化有很好的理解，但在提供最新、准确信息方面表现不佳。因此，Spotify通过工具让LLM在需要超出其掌握范围的信息时告知用户。

基于用户输入，LLM的初始响应还包括需要咨询的其他服务以获取缺失的信息。当这些额外的数据被接收后，LLM会生成完整的响应，最终显示给用户。

为了防止用户等待所有外部服务响应完毕，Sidekick使用了“卡片”概念作为占位符。Sidekick首先渲染从LLM接收到的初始响应，包括所有占位符。一旦额外的请求完成，Sidekick会用接收到的信息替换占位符。

异步工作流的充分利用

Sidekick中实现的解决方案充分利用了这一工作流程的异步性，并将响应解复用步骤与Markdown缓冲解析器集成在一起。如需了解更多详细信息，建议阅读Goral的原文。