智能汽车问答系统的设计与优化

这是一个实际的产业级项目案例，类似于”懂车帝”内部的 AI 助手。从最初的简单 RAG 到现在的多路融合系统，经历了多个迭代周期。

项目核心目标

构建一个能够处理复杂汽车查询的端到端智能问答系统，处理的场景包括：

看车（车型浏览、推荐）
参数对比（各个维度的差异分析）
泛谈（开放式讨论）

核心架构：从问题到答案

用户Query
  ↓
[Plan 规划模型] - 理解意图 & 生成检索规划
  ↓ 
[多路检索]
  ├─ 网页检索 (互联网数据)
  ├─ 车型库检索 (结构化数据)
  └─ (可选：其他垂直库)
  ↓
[LLMCritic 判别] - 置信度评分，确保质量
  ↓
[答案生成 + 多模态演进] - 汇总信息，支持图文输出
  ↓
[自动化评估] - DeepSeek-R1 或 Doubao 进行质量把关
  ↓
用户答案

主要技术挑战与解决方案

问题 1：意图分流的”强路由”陷阱

痛点

传统 NLP：用多标签分类器给 Query 打标签（看车/对比/泛谈）
问题：
- 边界模糊：很多 Query 处于类别之间
- 错误放大：一旦分类错误，后续路径全盘皆错
- 语义连续：用离散标签无法捕捉灵活表达

我们的演进

第一版：NLP 多标签分类
  ↓ （发现错误率高达 15-20%）
改进版：引入 LLM Plan 模型
  - 所有 Query 先进入 LLM 进行**语义理解 & 任务规划**
  - 不再强行给定标签
  - LLM 输出"检索什么、去哪检索"的规划
  ↓ （效果提升，但仍有误）
最终版：弱化分类，分布式判决
  - 训练专门的**二分类器**：判断"是否需要进入特定路径"
  - 而非判断"属于哪一类"
  - LLM 兜底保证"不智障"回答

效果：准确率从 80% 提升到 94%，容错能力显著提升。

问题 2：RAG 的冗余和质量问题

痛点

多路检索结果高度重合：车型库和网页中都有”特斯拉 Model 3 价格”
信息密度低：冗余填充了 context window
事实准确性：缺乏权威源，容易产生幻觉

解决方案

前置融合：Plan 阶段决策
  - "这个 Query 需要检索什么"（精准 query 改写）
  - "去哪个库检索"（按源头优先级）
  - "是否需要时效性约束"（如实时价格）
  ↓
后置融合：智能合并
  - 如果结果冗余度高 > 阈值（如 >80%），调用**数据融合 LLM**
  - 但大多数情况直接拼接（减少推理成本）
  ↓
权威源优先：架构层面
  - 构建**专有的、边界清晰的权威数据库**
  - 赋予最高召回优先级
  - 减少对通用网页的依赖

效果：

冗余信息减少 40%
准确率提升（权威源优先）
API 调用减少 35%（少了很多不必要的融合操作）

问题 3：总结模型能力不足

痛点

模型在”高噪声、低反馈确定性”环境下学习困难
RAG 检索的冗余干扰了模型学习
答案逻辑性差，容易出现”拼凑感”

解决方案

优化数据链路：
  1. SFT（监督微调）：用高质量的示例调教模型
  2. GRPO（群组相对策略优化）：强化学习调整策略
     - 生成多个候选答案
     - 用强评估器（如 Qwen3-30B）标注质量
     - 模型学会高质量答案的特征

降低干扰：
  - 减少 RAG 输入的冗余信息
  - 让模型专注于"理解与表达"而非"过滤"

效果指标：
  - 逻辑性提升（定量：用自动评估器打分）
  - 用户满意度提升 12%

技术方案详解

核心组件 1：Plan 规划模型

模型选择：Qwen3-30B-A3B（经 SFT 训练）

职责

Query 语义理解
任务拆解（可能需要多路检索）
动态生成检索规划

输出格式 - 结构化规划

{
  "intent": "compare_models",
  "retrieval_plan": [
    {
      "source": "car_database",
      "query": "特斯拉 Model 3 vs BMW 3 系规格对比",
      "constraints": ["price", "performance", "comfort"]
    },
    {
      "source": "web_search",
      "query": "特斯拉 Model 3 BMW 3 系 2026 用户评测对比",
      "time_constraint": "recent_3_months"
    }
  ],
  "confidence": 0.95
}

核心组件 2：车型库检索（Text2RPC/SQL）

挑战：

传统 SQL 准确率仅 76%（生成的 SQL 常有错误）
需要复杂多表 JOIN 和动态过滤

我们的方案：XML 格式而非 SQL

<query>
  <select>price, model_name, engine_type, 0-100_time</select>
  <where>
    <condition field="brand">特斯拉</condition>
    <condition field="year">2026</condition>
    <range field="price" min="250000" max="350000"/>
  </where>
  <order_by field="price" direction="asc"/>
</query>

Schema 路由：通过 Embedding 提取 Top-30 相关属性，拼接成 InputDataSchema。

为什么 XML 胜过 SQL：

更容易处理多表、复杂过滤、排序
LLM 生成 XML 的准确率：~92%（vs SQL 的 76%）
可扩展性更好（新增属性无需重新训练）

核心组件 3：LLMCritic 判别模块

目的：对检索结果进行置信度打分

模型：小参数量（1.7B 或 0.6B）

快速推理
成本低

判别维度

score = {
  "relevance": 0.92,      # 与 Query 相关性
  "factuality": 0.88,     # 事实准确性
  "completeness": 0.85,   # 信息完整性
  "overall": 0.88
}

如果 overall score < 0.7，标记为低质量，可能触发重新检索。

核心组件 4：自动化评估系统

评估工具：DeepSeek-R1 / Doubao-1.6-pro-thinking

方法：提示工程 + 迭代改进

# 示例 prompt
evaluate_prompt = """
请评估以下答案的质量，考虑：
1. 是否正确回答了用户问题
2. 是否有引用支撑（可检验性）
3. 是否包含不必要的冗余信息
4. 用户是否能基于此做出购车决策
 
给出 1-10 的评分和改进建议。
"""

效果：

与人工标注的 Kappa 系数 > 0.75（中等以上一致性）
用于迭代改进 SFT 数据

性能数据

指标	数值
Plan 模型准确率	94%
车型库检索准确率	92%（XML 格式）
最终答案满意度	78%
P90 端到端延迟	1.2s
Qwen3 1.7B 推理延迟 (P90)	91ms

演进规划

短期（2026 上半年）

SFT + GRPO 打通车型库 Tool 链路
完善自动化评估
优化 XML 生成的稳定性

中期（2026 下半年）

引入多模态能力
Plan 模型升级为 VL-LLM（看图懂车）
支持图文并茂的答案生成

长期（2027+）

全链路多模态：输入图片 → 输出图文导购
实时反馈循环：用户交互直接优化 RAG
跨域迁移：汽车系统架构复用到其他垂直领域

面试与项目复盘要点

强调的技术点

从 NLP 分类到 LLM 规划的转变：为什么更优雅
多源融合的工程权衡：何时融合、何时不融合
XML vs SQL 的取舍：不是”哪个更强”，而是”哪个更适配”
质量评估的自动化：如何用小模型快速判别

定量指标

准确率提升：80% → 94%
成本降低：API 调用减少 35%
用户满意度：从 68% 提升到 78%

Quartz 4

Explorer

01-智能汽车问答系统