Quivr项目中聊天LLM模块的代码重构实践

在Quivr项目的后端架构中，聊天LLM功能模块存在明显的代码重复问题。本文将深入分析这一问题，并提出基于工作流配置的优雅解决方案。

问题背景分析

Quivr的后端系统在处理聊天LLM功能时，存在两个高度相似的实现：

1. backend/core/quivr_core/chat_llm.py中的核心实现
2. backend/api/quivr_api/modules/chat_llm_service/chat_llm_service.py中的服务层实现

这两个模块都重复实现了brain.py和rag_service.py中的核心逻辑。这种重复不仅增加了维护成本，还可能导致功能不一致的问题。

技术现状剖析

当前架构中，聊天LLM的处理流程主要包括两个关键步骤：

1. 历史对话过滤(filter_history)
2. 响应生成(generate)

这些步骤实际上与大脑(Brain)和RAG(Retrieval-Augmented Generation)服务的核心功能高度重叠。重复实现这些逻辑违反了DRY(Don't Repeat Yourself)原则。

解决方案设计

基于Quivr项目新引入的工作流引擎和YAML配置系统，我们可以采用更优雅的解决方案：

1. 动态工作流构建：在运行时创建专门用于聊天LLM的轻量级工作流
2. 最小化流程配置：该工作流只需包含filter_history和generate两个必要步骤
3. 配置驱动开发：通过YAML文件定义工作流，实现业务逻辑的可配置化

实现方案详解

工作流配置示例

chat_llm_workflow:
  steps:
    - name: filter_history
      module: core.history_processor
      params:
        max_turns: 5
    
    - name: generate
      module: core.llm_generator
      params:
        model: gpt-4
        temperature: 0.7

架构优化点

1. 去重核心逻辑：将重复的brain和RAG逻辑统一到核心模块
2. 轻量级服务层：聊天LLM服务只需负责工作流编排和结果返回
3. 配置灵活性：不同场景的工作流可通过配置调整，无需修改代码

预期收益

1. 代码可维护性提升：消除重复代码，减少维护成本
2. 架构清晰度提高：各层职责更加明确
3. 扩展性增强：新功能可通过配置快速实现
4. 一致性保证：所有LLM调用使用相同的核心逻辑

实施建议

1. 渐进式重构：先在新功能中使用工作流模式，逐步迁移旧代码
2. 测试保障：建立完善的工作流测试用例
3. 文档补充：详细记录工作流配置语法和使用规范

这种基于工作流的架构改造，不仅解决了当前的代码重复问题，还为Quivr项目的长期演进奠定了更坚实的基础。