cockpit_realtime_tutorial

Chapter 6｜RAG 检索与知识系统设计（RAG & Knowledge System）

1. 开篇段落与设计目标

1.1 背景

在车载环境中，驾驶员与乘客对信息的获取有着极高的要求：准确（Accuracy）、即时（Immediacy）和简明（Conciseness）。通用大模型（Foundation Models）虽然具备常识，但缺乏特定车辆（Unique VIN）的配置知识。例如，同一款车型的“2023款”和“2025款”在自动驾驶开启方式上可能完全不同。如果模型产生幻觉，不仅影响体验，更可能引发安全事故。

1.2 核心目标

本章旨在设计一个特定于车辆上下文（Vehicle-Context-Aware）的检索增强生成系统。

2. 知识数据源与治理（Data Ingestion & Governance）

数据处理流水线（ETL）是 RAG 系统的灵魂。垃圾进，垃圾出（Garbage In, Garbage Out）。

2.1 异构数据源分类

车载知识库远不止一本 PDF 手册，它是一个异构数据的集合：

数据类型 来源示例 更新频率 特点 处理策略
核心静态数据 车主手册、保修手册、快速指南 年/款更新 结构化极强，含大量表格和警告框 PDF 解析 + 布局分析 + 表格重构
动态服务数 故障码库 (DTC)、TSB (技术通报) 月/周更新 代码 (P0300) 对应 文本解释 键值对索引 (Keyword Search)
运营/生活数据 车机 App 权益、充电桩指引、保险条款 实时/日更新 碎片化、营销话术多 网页抓取 + 语义分块
多模态索引 仪表图标、中控按钮图、机舱部件图 车型换代更新 图像数据 图像向量化 (CLIP/ViT) 或分类标签化

2.2 深度文档解析与分块策略 (Advanced Chunking)

简单的“按字符数切分”在手册场景下是灾难性的。我们需要语义感知分块。

2.2.1 布局感知解析 (Layout-Aware Parsing)

PDF 手册中常有跨页的表格、侧边栏的警告（Warning/Caution）。

2.2.2 父子索引策略 (Parent-Child Indexing)

为了兼顾检索的精准度和生成上下文的完整性，采用父子块策略：

2.3 元数据分类体系 (Metadata Taxonomy)

这是车规 RAG 最关键的设计。每个 Chunk 必须打上以下 Tag：

3. 检索架构设计（Retrieval Architecture）

我们采用混合检索 + 重排的工业级架构，以平衡语义理解和确匹配。

3.1 架构数据流 ASCII 图

[User Audio Stream] 
       | (OpenAI Realtime API)
       v
[User Text/Transcript] + [Context: VIN, Location, Speed]
       |
       v
[Query Understanding Module]
| 1. Query Rewrite: "那个红色的圈圈灯" -> "制动系统故障警告灯"
| 2. Intent Classification: Manual_QA vs. ChitChat vs. Car_Control
| 3. Metadata Extraction: Extract filter tags based on current car state
       |
       v
[Hybrid Search Engine] <=== (Parallel Execution) ===>
|                                                  |
|-- [Vector Search (Dense)]                        |-- [Keyword Search (Sparse/BM25)]
|   (Captures "meaning")                           |   (Captures exact codes/names)
|   Query: Embedding(Text)                         |   Query: "Isofix", "P0300", "5W-40"
|   Filter: model='X' AND year='2024'              |   Filter: model='X' AND year='2024'
|   Return: Top-20 Chunks                          |   Return: Top-20 Chunks
|                                                  |
       v                                           v
[Ensemble & Deduplication] (Merge results)
       |
       v
[Reranker (Cross-Encoder)]
|  Input: (Query, Chunk_1), (Query, Chunk_2)...
|  Action: Deep semantic scoring (Slow but accurate)
|  Output: Top-3 Chunks with Re-rank Score
       |
       v
[Context Window Builder]
|  Format:
|  "Context 1 [Ref: Manual Sec 3.1]: ...text..."
|  "Context 2 [Ref: DTC DB]: ...text..."
       |
       v
[LLM Generation (Realtime API Output)]

3.2 关键组件详述

3.2.1 查询重写 (Query Rewriting)

用户口语通常不规范。

3.2.3 重排 (Reranking)

向量相似度（Cosine Similarity）只能衡量“大概像”，无法衡量“逻辑蕴含”。Cross-Encoder 重排模型（如 BGE-Reranker）能显著提升 Top-1 准确率，剔除相关但错误的文档（如剔除“后排空调设置”当用户问“前排空调”时）。

4. 与 Realtime API 的集成策略

RAG 在此处不再是简单的“请求-响应”，而是会话中的工具调用（Tool Call）。

4.1 接口契约 (Tool Definition)

在 Realtime API session 初始化时，定义如下工具：

{
  "name": "search_vehicle_manual",
  "description": "Search the vehicle owner's manual regarding features, warnings, or maintenance. Use this for 'how to', 'what is', or technical questions.",
  "parameters": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "description": "Refined search query" },
      "category": { "type": "string", "enum": ["feature", "warning", "maintenance"] },
      "requires_visual_match": { "type": "boolean", "description": "Set true if user refers to a visible icon/button" }
    },
    "required": ["query"]
  }
}

4.2 延迟掩盖与流式体验 (Latency Masking)

RAG 检索耗时（300ms - 800ms）可能导致语音对话出现尴尬的空白。

4.3 输出策略：语音摘要 + 屏幕详情

车载语音助手不应朗读长篇大论。

5. 多模态 RAG (Visual Grounding)

解决“这（指着屏幕/仪表盘）是什么？”的问题。

5.1 视觉检索路径

  1. 截图/推流：触发对话时，捕获当前驾驶员视角的帧（DMS/OMS 或中控屏截图）。
  2. 视觉解析 (VLM)：
    • 利用 GPT-4o 的视觉能力，将图像转化为文本描述：“仪表盘上有一个黄色圆圈括起来的感叹号图标”。
  3. 文本检索：将描述作为 Query 输入 RAG 系统。
  4. 图像相似度检索 (可选)：如果建立过图标库的向量索引（CLIP Embedding），可以直接用图像 Embedding 搜索最相似的图标 ID，获取其含义。

5.2 策略选择

6. 安全、防幻觉与合规 (Safety & Compliance)

6.1 引用与归因 (Attribution)

6.2 拒答机制 (Refusal Strategy)

6.3 法律免责

对于涉及维修、改装、急救的回答，必须附带简短的免责声明（可在语音中略去，但必须在屏幕文字中展示）。

7. 性能优化 (Performance Optimization)

7.1 多级缓存 (Multi-level Caching)

  1. L1 本地缓存 (In-Car)：高频静态问答（Top 50 FAQ，如“怎么连蓝牙”、“胎压复位”）。零延迟，断网可用。
  2. L2 语义缓存 (Edge/Cloud)：使用 Redis + Vector。当新 Query 与历史 Query 相似度 > 0.95 时，直接返回历史答案。

7.2 边缘计算与离线能力

虽然 Realtime API 依赖云端，但 RAG 索引可以做切片下发。

8. 本章小结

本章构建了一个适应车载严苛环境的 RAG 系统。其核心差异点在于：

  1. 元数据为王：通过 VIN 码和配置过滤，解决“通用回答”的危害。
  2. 深度解析：保留表格和警告框的语义结构。
  3. 口语化输出：适应 Realtime API，区分“听的内容”和“看的内容”。
  4. 安全围栏：无证据不回答，低置信度即拒答。

9. 练习题 (Exercises)

基础题

Q1: 为什么在车载 RAG 中，重排（Reranking）步骤几乎是必须的？ > **Hint**: 向量检索（Embedding）通常基于语义相似，而不是逻辑正确。 > > **答案**: > 向量检索只能找到“语义相关”的内容。例如用户问“后视镜加热”，向量检索可能召回“后视镜调节”、“后视镜折叠”和“后镜加热”。如果不进行重排，模型可能会被混杂的上下文干扰。Cross-Encoder 重排模型可以精确计算 Query 和 Document 的相关性得分，将真正的“加热说明”排在第一位，并剔除得分低的干扰项，从而大幅减少幻觉风险。
Q2: 描述“父子索引（Parent-Child Indexing）”如何解决检索粒度与上下文完整性之间的矛盾。 > **Hint**: 容易被搜到的块不一定容易被读懂。 > > **答案**: > 矛盾在于：为了精准检索，我们需要很小的分块（Child，包含特定关键词）；但为了让 LLM 理解并生成连贯回答，我们需要较大的上下文（Parent，包含前后文、警告、前置条件）。 > 解决方案：索引时对 Child 建立向量索引；检索时，命中 Child 后，取出其对应的 Parent 块喂给 LLM。这样既保证了召回率，又保证了生成的准确性和完整性。
Q3: 针对表格数据（例如“轮胎气压表”），最推荐的预处理方式是什么？ > **Hint**: 直接转成纯文本通常会丢失行列对应关系。 > > **答案**: > 最推荐的方式是将表格转换为 **Markdown 格式** 或 **JSON 对象**，并保留表头信息。对于复杂的跨页表格，需要进行合并处理。如果表格极其复杂，可以生成表格的文本摘要（Summary）用于检索，同时保留原始结构数据用于生成。
Q4: Realtime API 是流式的，如何在 RAG 检索耗时较长（例如 2秒）时保持良好的用户体验？ > **Hint**: 避免“死寂”。 > > **答案**: > 1. **注入填充语 (Filler Words)**：Agent 在决定调用搜索工具时，先立即下发一段音频（如“我查一下手册…”）。 > 2. **非阻塞式思考**：如果支持，播放填充语的同时后台并行检索。 > 3. **视觉反馈**：在车机屏幕上显示加载动画或“正在搜索知识库”的状态。

挑战题 (开放性思考)

Q5: 设计一个“主动式 RAG”场景。当车辆发生故障码 P0300（多缸失火）时，系统如何在用户开口前做好准备？ > **Hint**: 结合车端信号与云端缓存。 > > **答案**: > 1. **信号触发**：车端网关监测到 DTC P0300 上报。 > 2. **预取 (Prefetch)**：车端 Agent 或云端服务立即以 "P0300" 和 "Engine Misfire" 为 Key，触发 RAG 检索。 > 3. **缓存热加载**：将检索到的解释、危害等级、建议措施加载到当前会话的 Context 缓存中。 > 4. **主动交互**：当用户询问“车怎么抖了”或“那个灯亮了”时，LLM 无需等待检索，直接利用缓存信息秒回，甚至主动发起对话：“我检测到发动机有异常震动（P0300），建议您...”
Q6: 假设用户驾驶的是一辆 10 年车龄的老车，手册早已更新多次。如何确保 RAG 回答的是当年那个版本的知识？ > **Hint**: 数据版本控制与车辆档案。 > > **答案**: > 1. **知识库版本化**：在数据入库时，不只是覆盖旧数据，而是建立多版本索引（Versioned Index）。每个 Chunk 必须包含 `effective_date_start` 和 `end`，或者关联特定的 `model_year`。 > 2. **车辆画像 (Vehicle Profile)**：会话开始时，注入车辆的 VIN 和出厂日期。 > 3. **过滤条件**：检索时强制带上 `filter: model_year == 2015`。严格禁止跨年代检索，因为老车的物理按键操作可能在新车上变成了屏幕菜单操作。

10. 常见陷阱与错误 (Gotchas)

10.1 陷阱：PDF 解析丢失空间语义

10.2 陷阱：过度依赖向量检索匹配专有名词

10.3 陷阱：忽略否定词

10.4 陷阱：多模态“张冠李戴”