RAG 进化史：从“幻觉”到“可信”，及前端流式渲染实战

在 2020 年之前，以 GPT-3 为代表的大模型展现出强大的生成能力，但研究者很快发现了两个致命缺陷：

• 知识截止（Knowledge Cutoff）：模型参数中存储的知识是静态的，训练数据截止于某个时间点。例如，2020 年训练的模型无法知晓 2021 年的事件。
• 幻觉（Hallucination）：当模型被问及训练数据中不存在或模糊的信息时，它会基于统计概率'编造'一个看似合理但实际错误的答案。例如，问'2024 年诺贝尔物理学奖得主是谁？'，模型可能会自信地给出一个虚构的名字。

如何发现的？ 通过大规模评测（如 TriviaQA、Natural Questions 等开放域问答数据集）发现，模型在回答需要精确事实（如'某公司的 CEO 是谁'）的问题时，准确率远低于检索系统。这表明模型记忆能力有限且不可靠。

2. 理论探索：从'检索 + 阅读'到'检索 + 生成'

在 RAG 概念提出前，学术界已有类似尝试：

• DrQA（2017）：斯坦福大学提出，使用传统检索（TF-IDF/BM25）找到文档，再用 RNN 模型从文档中抽取答案。这是'检索 + 阅读理解'的雏形。
• REALM（2020）：Google 提出在预训练阶段就引入检索机制，让模型学会'查资料'。

3. 范式确立：Meta AI 的里程碑论文

2020 年 5 月，Meta AI（原 Facebook AI）的 Patrick Lewis 等人在论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中正式提出 RAG。

• 核心洞察：将模型的参数化记忆（Parametric Memory，即模型权重中的知识）与非参数化记忆（Non-parametric Memory，即外部知识库/向量数据库）结合。
• 解决方案：在生成每个 Token 时，不仅依赖模型内部参数，还依赖从外部知识库检索到的上下文。这相当于给模型装了一个'外部大脑'，解决了知识更新滞后和幻觉问题。

总结：RAG 的诞生源于对 LLM'一本正经胡说八道'这一痛点的深刻洞察，旨在通过引入动态、可更新的外部知识源，将生成过程锚定在事实依据上。

二、前端流式渲染实现：SSE 与 WebSocket 的实战

在 RAG 系统中，由于检索和生成链路较长（检索向量库 + LLM 推理），如果等待后端全部生成完毕再返回，用户将面临长达 10-20 秒的'白屏等待'。流式渲染（Streaming）通过'边生成边返回'解决了这一体验痛点。

技术选型：SSE vs WebSocket

• SSE (Server-Sent Events)：基于 HTTP 的单向通信（服务端推客户端）。协议简单，自动重连，适合 AI 对话这种'一问一答'的场景（推荐）。
• WebSocket：全双工通信。协议稍复杂，适合需要频繁双向交互的场景（如在线协作编辑）。

具体实现过程（以 SSE + React 为例）

后端（Python FastAPI）实现

后端需要开启流式接口，将 LLM 生成的 Token 逐个推送给前端。

from fastapi import FastAPI
from fastapi.responses import StreamingResponse
import asyncio

app = FastAPI()

@app.get("/chat")
async def chat_stream(query: str):
    # 1. RAG 检索阶段（非流式，需先完成）
    context = await retrieve_documents(query)  # 从向量库检索相关文档
    
    # 2. 构造 Prompt，包含检索到的上下文
    prompt = f"基于以下资料：{context}\n\n请回答：{query}"
    
    # 3. 流式生成函数
    async def generate():
        # 调用 LLM（如 OpenAI API），设置 stream=True
        response = await openai.ChatCompletion.acreate(
            model="gpt-4",
            messages=[{"role": "user", "content": prompt}],
            stream=True  # 关键：开启流式
        )
        
        # 逐块读取流
        async for chunk in response:
            content = chunk.choices[0].delta.get("content", "")
            if content:
                # 按照 SSE 协议格式推送：data: {content}\n\n
                yield f"data: {content}\n\n"
    
    # 返回流式响应，媒体类型为 text/event-stream
    return StreamingResponse(generate(), media_type="text/event-stream")

前端（React）实现

前端使用 EventSource 监听流，并实时更新 DOM。

import { useState, useRef } from 'react';

function ChatApp() {
    const [message, setMessage] = useState('');
    const [isLoading, setIsLoading] = useState(false);
    const messageEndRef = useRef(null);
    const [answer, setAnswer] = useState('');
    
    const handleSend = async () => {
        if (!message.trim()) return;
        setIsLoading(true);
        let fullText = '';
        
        // 1. 构建 SSE 连接 URL（包含查询参数）
        const eventSource = new EventSource(`/chat?query=${encodeURIComponent(message)}`);
        
        // 2. 监听 message 事件（服务端推送的数据）
        eventSource.onmessage = (event) => {
            // 接收到一个 Token
            const chunk = event.data;
            fullText += chunk;
            
            // 3. 更新状态，触发重新渲染（逐字显示）
            setAnswer(fullText);
            
            // 滚动到底部（模拟打字机效果）
            messageEndRef.current?.scrollIntoView({ behavior: 'smooth' });
        };
        
        // 4. 监听 error 或 close 事件
        eventSource.onerror = () => {
            eventSource.close();
            setIsLoading(false);
        };
    };
    
    return (
        <div>
            <div>{answer}</div>
            {/* 用于滚动锚点 */}
            <div ref={messageEndRef} />
        </div>
    );
}

关键细节与避坑指南

1. 数据格式：SSE 协议要求每条消息以 data: 开头，以 \n\n 结尾。后端必须严格遵守，否则前端 EventSource 会解析失败。
2. 连接管理：生成结束后，后端应关闭流，前端需在 onerror 或自定义结束标记（如 [DONE]）时调用 eventSource.close()，防止内存泄漏。
3. 性能优化：对于长文本，不要每次 setState 都渲染整个字符串（可能导致卡顿）。可考虑使用 useRef 直接操作 DOM 或使用防抖渲染。

通过上述流程，用户提问后，前端会立即看到文字逐个蹦出的效果，极大提升了 RAG 系统的交互流畅度与可信感。