解决LLM流式响应中的Markdown换行符问题 ​

引言 ​

在构建集成大语言模型(LLM)的应用时，流式响应（streaming response）是一项提升用户体验的重要技术。流式响应允许LLM生成的内容实时显示在用户界面上，创造出打字机效果，而不是等待整个响应完成后一次性展示。

然而，在实现这一功能的过程中，我遇到了一个看似简单却令人困惑的问题： LLM返回的Markdown格式内容在前端展示时丢失了换行符 ，导致Markdown格式错误，影响了内容的可读性和展示效果。

本文将详细分析这一问题的技术原因，并分享一个巧妙的解决方案，帮助开发者在流式响应中正确处理和保留Markdown格式。

问题分析：换行符为何会丢失？ ​

表现症状 ​

在我的应用中，LLM返回的响应包含Markdown格式的内容，如代码块、列表和段落等。在后端服务中，这些内容的格式是完整的，包括必要的换行符（ \n ）。然而，当内容通过流式响应传输到前端并渲染时，许多原本应当换行的地方变成了空格，导致Markdown格式混乱。

例如，一个原本格式正确的代码块：

def hello_world():
    print("Hello, World!")

在前端可能被渲染为：

```python def hello_world():    print("Hello, World!") ```

这显然失去了代码块的结构，导致Markdown解析错误。

技术原因解析 ​

经过系统性排查，我发现问题出在 前端使用EventSource接收流式数据 与 后端使用 \n\n 分割LLM响应报文 之间的交互上。

EventSource基础概念 ​

EventSource （又称Server-Sent Events，SSE）是一种允许客户端接收服务器推送更新的Web API。它建立一个单向通道，服务器可以通过这个通道持续向客户端发送消息。

EventSource通信的基本格式为：

data: 消息内容\n\n

其中 \n\n （两个换行符）用于分隔不同的消息。这是EventSource协议的规定，服务器必须以 \n\n 结束每条消息。

问题根源 ​

当LLM生成的Markdown内容中包含连续两个换行符（ \n\n ）时，与EventSource的消息分隔符发生了冲突。在EventSource解析过程中，这些连续的换行符被错误地解释为消息边界，而非内容的一部分。

具体来说，当EventSource客户端接收到如下格式的数据时：

data: 这是第一段内容\n\n这是第二段内容\n\n

它会将其解析为两条单独的消息：

1. 这是第一段内容
2. 这是第二段内容

而不是一条包含段落分隔的消息。

这导致了Markdown中至关重要的换行符被错误处理，破坏了格式结构，尤其是代码块、列表和分段等依赖换行符的Markdown元素。

解决方案：序列化与反序列化换行符 ​

针对这一问题，我设计了一种基于占位符替换的序列化与反序列化方案。

技术方案概述 ​

1. 在后端服务中，将LLM响应中的所有 \n 换行符替换为自定义占位符（如 <|newline|> ）
2. 将替换后的内容通过EventSource发送到前端
3. 在前端接收到内容后，在渲染前将占位符重新替换回 \n 换行符

这种方法类似于序列化和反序列化过程，确保换行符信息在传输过程中不会丢失或被错误解释。

后端实现 ​

# 处理LLM响应的函数
def process_llm_response(llm_response):
    # 将换行符替换为自定义占位符
    processed_response = llm_response.replace("\n", "<|newline|>")
    # 通过EventSource发送处理后的响应
    return f"data: {processed_response}\n\n"

前端实现 ​

// 创建EventSource连接
const eventSource = new EventSource('/api/llm-stream');
// 接收消息并处理
eventSource.onmessage = (event) => {
    // 将占位符替换回换行符
    const content = event.data.replace(/<\|newline\|>/g, '\n');
    // 使用Markdown渲染库渲染内容