1 RAG 可以接哪些数据源
P0 · rag
🏷 标签：rag, data-sources, integration, etl
1️⃣ 考察意图
面试官想考察你对 RAG 数据源多样性的理解深度，而不仅仅是罗列类型。真正刁钻点在于：你是否能区分不同数据源接入时的技术挑战（如结构化数据如何转为向量、非结构化数据解析的坑、实时数据更新策略）。答好了能展示你从“能接什么”到“怎么接、接得好”的系统设计能力，属于工程取舍 + 系统设计混合型考察。
2️⃣ 标准答
RAG 理论上可接入任何能转为文本的数据源，但实际落地需按数据结构和更新频率分类处理。以下从三大类展开：
- **结构化数据（SQL 数据库、CSV、Excel）**接入方式：通过 SQL 查询将行转为文本描述，例如“用户 ID 1001，订单金额 500 元，下单时间 2024-01-01”。关键点是字段选择——只取与检索相关的列，避免噪声。
- 工程取舍：直接向量化整行会导致维度爆炸，通常先做列筛选 + 文本模板化。坑：数据库更新频繁时，需增量索引（如 Debezium 监听 binlog），全量重建成本高。
- 实际解法：用 LangChain 的 SQLDatabaseChain 或自定义 ETL 脚本，每 5 分钟增量同步，结合 Redis 缓存热点查询结果。 半结构化数据（JSON、XML、HTML、Markdown）
- 接入方式：解析为树状结构后，按节点或路径分块。例如 HTML 按
<h1>标签分割，JSON 按 key 层级提取。 - 为什么这么做：保留上下文结构，避免跨块语义断裂。坑：嵌套过深（如 10 层 JSON）会导致分块碎片化，需设置最大深度（如 3 层）并合并相邻节点。
- 工具推荐：Unstructured.io 库可自动识别格式并分块，支持 PDF、HTML 等 20+ 格式。 非结构化数据（PDF、Word、图片、音视频、网页）
- PDF/Word：用 PyMuPDF（fitz）或 pdfplumber 提取文本，注意表格和图片需 OCR（Tesseract 或 PaddleOCR）。坑：扫描版 PDF 直接提取为空，必须 OCR 且后处理纠正错字（如“0”误识别为“O”）。
- 图片/音视频：先转文本（图片用 OCR，音频用 Whisper，视频抽帧后 OCR + ASR），再分块。工程取舍：Whisper 大模型精度高但延迟 5-10 秒，小模型（tiny）快但中文准确率低 15%，需按场景选型。
- 网页：用 BeautifulSoup 或 Selenium 抓取，去除广告和导航栏，保留正文。坑：动态加载内容（JS 渲染）需用 Playwright 模拟浏览器，否则只拿到空壳。 实时数据源（API、Kafka、WebSocket）
- 接入方式：事件驱动更新。例如 Kafka 消费消息后，实时写入向量数据库（如 Qdrant 的 streaming upsert）。定时任务（每 30 分钟）用于全量刷新，避免数据滞后。
- 为什么这么做：实时性要求高时（如客服对话），延迟需 < 1 秒，但向量化计算成本高，通常用异步批处理（攒 100 条或 5 秒触发一次）。
- 实际坑：API 限流（如 OpenAI 的 3 RPM）会导致数据丢失，需加重试队列（RabbitMQ）和指数退避。
总结：RAG 可接任何数据源，但核心是“转文本 + 分块 + 索引”三步，每一步都需根据数据特性做适配。选型时优先考虑更新频率和解析复杂度，结构化数据用 SQL 模板，非结构化用 OCR/ASR，实时数据用流式引擎。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从结构化、半结构化、非结构化、实时数据四个层面回答。结构化数据通过 SQL 查询转为文本模板；半结构化按节点分块保留上下文；非结构化需 OCR/ASR 解析后分块；实时数据用事件驱动更新。总结一句：RAG 理论上可接任何数据源，但实际落地必须根据数据特性和更新频率做适配，否则检索质量会崩。”
4️⃣ 高频追问 & 应对
追问 1：如果数据源是实时股票行情，怎么保证检索结果不过时？
使用流式处理框架（如 Kafka + Flink），每秒消费行情数据，写入向量数据库的 streaming upsert 接口。关键取舍：向量化计算成本高，不能每条都做，需设置时间窗口（如 5 秒聚合一次）。坑：行情数据波动大，旧数据需 TTL 自动过期（如 1 小时），否则检索到过时信息。实际方案：用 Redis 缓存最近 1 分钟行情，向量库存 1 小时聚合数据，检索时先查缓存再查向量库。
追问 2：PDF 中有表格和图片，怎么保证检索时能准确匹配？
先用 PyMuPDF 提取文本层，表格用 camelot 或 tabula 解析为结构化数据（如 CSV），图片用 OCR 提取文字。分块时，表格单独成块并加元数据（如“表格：2024 年财报”），图片文字嵌入上下文。坑：表格跨页时需合并，否则检索碎片化。解法：用 LayoutParser 检测页面布局，按区域分块，再按页号合并。
追问 3：如果数据源是 100 个不同格式的 API，怎么统一接入？
设计适配器模式：每个 API 写一个 adapter，返回统一格式（文本 + 元数据）。用 ETL 工具（如 Airbyte）管理连接，支持 200+ 数据源。坑：API 版本升级会导致 adapter 失效，需加 schema 校验和版本监控。实际方案：用 JSON Schema 验证返回数据，失败时告警并回退到上次成功版本。
5️⃣ 避坑 · 常见错误答法
- ❌ 回答“RAG 可以接任何数据源，直接喂进去就行” → ✅ 正确切入：必须说明不同数据源的解析和分块策略，例如“PDF 需 OCR，数据库需 SQL 转文本，否则检索质量差”。
- ❌ 回答“只接文本数据源，图片和音频不行” → ✅ 正确切入：图片和音频可通过 OCR/ASR 转为文本，但需考虑延迟和精度 trade-off，例如“Whisper 大模型精度高但慢，小模型快但中文差 15%”。
- ❌ 回答“实时数据用定时任务每 10 分钟更新一次就行” → ✅ 正确切入：实时数据需事件驱动，例如“用 Kafka 消费消息后实时 upsert，定时任务只做全量刷新，否则数据滞后 10 分钟”。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“多数据源接入”角度切入，例如“我在项目中接了 MySQL 和 PDF，发现 PDF 表格解析是瓶颈，用了 camelot + OCR 后检索准确率提升 20%”。
- 如果你只做过传统 NLP：用“数据预处理”类比，例如“传统 NLP 处理文本，RAG 数据源类似多模态输入，核心都是转文本，但多了分块和索引策略”。
- 如果你是校招无项目：聚焦“论文复现 demo”，例如“我复现了 LlamaIndex 的多数据源示例，对比了 SQL 和 PDF 的检索延迟，发现 PDF 解析占 80% 时间”。
- 《RAG 数据源接入最佳实践》（LangChain 官方博客）
- 《Unstructured.io 多格式解析技术白皮书》
- 《Whisper 模型精度与延迟对比》（OpenAI 技术报告）
- 《Debezium 实时数据同步方案》（Red Hat 文档）
- 《向量数据库增量索引优化》（Qdrant 官方博客）