一、为什么多轮对话这么难？

最近在给电商平台搭建智能客服时，发现LLM处理多轮对话有三个头疼问题：

• 长文本吃显存：用户连续问10个问题后，对话历史token数轻松突破4000，直接撑爆显存
• 状态丢失：用户说"上次说的那款手机"时，系统经常一脸懵（需要跨轮次记忆）
• 高并发乱序：促销期间2000+并发请求时，用户常收到别人的对话历史

二、技术选型：三大流派对比

我们测试了三种主流方案：

1. RAG（检索增强）
2. 优点：不需要微调，知识更新方便

3. 缺点：上下文拼接效率低，实测P99延迟>800ms

4. Fine-tuning（微调）

5. 优点：对话风格可控

6. 缺点：每个业务场景都要重新训练，成本高

7. Prompt Engineering

8. 最终选择：通过动态prompt管理上下文，平衡性能和成本

三、核心架构设计

采用分层架构，关键组件如下：

1. 对话状态机实现

class DialogStateMachine:
    def __init__(self):
        self.states = {
            'INIT': {'next': ['QUERY', 'COMPLAIN']},
            'QUERY': {'next': ['CONFIRM', 'CLARIFY']},
            # ...其他状态
        }
        self.current_state = 'INIT'

    def transit(self, intent: str) -> bool:
        """状态转移逻辑"""
        if intent in self.states[self.current_state]['next']:
            self.current_state = intent
            return True
        return False

2. 上下文压缩算法

采用TF-IDF保留关键信息：

def compress_context(texts: List[str], keep_ratio=0.3) -> str:
    from sklearn.feature_extraction.text import TfidfVectorizer

    tfidf = TfidfVectorizer().fit_transform(texts)
    importance = np.array(tfidf.sum(axis=0)).ravel()
    top_indices = importance.argsort()[-int(len(importance)*keep_ratio):]

    vocab = tfidf.get_feature_names_out()
    return ' '.join([vocab[i] for i in top_indices])

四、生产环境实战

性能优化成果

经过3轮调优后：

• QPS从50提升到210（4台A10G服务器）
• P99延迟从1200ms降到190ms
• GPU内存占用减少37%

避坑经验

遇到过的典型问题：

1. 不要用全局变量存会话：多进程部署时会数据错乱
2. 避免同步调用LLM：用asyncio+httpx实现异步请求
3. 动态超时设置：根据query复杂度自动调整等待时间

五、延伸思考

几个值得探索的方向：

1. 当用户同时发送图片和文字提问时，如何统一管理对话状态？
2. 模型突然输出危险内容时，如何在响应前实时过滤？
3. 有没有量化指标能评估多轮对话的连贯性？

最后的小建议

如果刚开始做多轮对话，建议先实现最小闭环：

1. 用Redis存最近5轮对话
2. 添加基础状态管理
3. 实现简单的超时机制

等跑通流程后，再逐步引入更复杂的优化策略。