Appearance
RAG 平台技术方案提炼与使用边界
来源：本机收到的《RAG平台技术方案(2).docx》。本文是提炼笔记，不复制原始文件；原始文件仍留在接收目录，不纳入 Git。
使用边界： 方案能证明“某系统这样设计过”，不能自动证明“我负责实现过”。用于面试前，必须逐项确认本人职责、实际部署组件、真实故障和可核实指标；无法确认的内容只能作为学习材料和追问准备，不能写进简历或说成个人产出。
结论：放在哪里
这份材料应放在私有面试准备站，以本页这样的“提炼与核对”形式保存；不应将原始 .docx 或带平台名称、认证集成细节、具体接口和缺陷记录的内容放进公开的 fullstack-road。
公开知识站已经有 RAG 入库、解析、权限、可靠性和评测的通用文章。后续只在去掉来源身份、平台名、接口路径和未验证事实后，把真正缺失的通用机制补到对应专题中。
一页架构
文档描述的是一个多租户 RAG 平台，而不只是一个“上传文件后问答”的 Demo：
它将同步 API 和重任务分开：API 处理身份、知识库与文档元数据；文档 Worker 处理转换、解析、分块、图生文和向量写入；对象存储保存可重建的原始资源；关系库保存可管理状态；检索引擎保存召回索引。
文档中真正有价值的设计点
| 主题 | 方案中的做法 | 面试时可讲的工程判断 |
|---|---|---|
| 多租户边界 | 知识库分个人、组织、公开三种可见性；组织与公开库关联不同 API Key | 权限必须进入数据模型和检索过滤，不能只由前端隐藏按钮 |
| 知识库层级 | 公开知识库支持父子树，并在修改父级时排除自身及子树 | 树结构必须防循环；可见性转换会影响授权关系，不能只是改枚举值 |
| 异步入库 | 上传后创建文档记录，提交事务后由 Celery Worker 执行解析、图生文、向量化与状态更新 | 先让数据库记录落地，再投异步任务；任务状态才是重试、进度和恢复的依据 |
| 文档生命周期 | embedding → success / error，文档、段落、图片和对象存储资源有关联 | 状态要区分处理中与失败；删除和重建不能让半成品进入检索 |
| 多格式解析 | DOCX/PDF/TXT/MD 走文本解析，PPTX/XLSX/CSV 按固有结构处理 | “支持格式”不等于读出纯文本；页码、标题、表头、幻灯片和工作表决定引用质量 |
| 层级与递归分块 | 标题树优先；超长文本再按分隔符递归切分；支持 overlap | 先用结构保留条款上下文，再用窗口保证长度上限；规则要通过评测选择 |
| 多模态资源 | 文档图片抽取为资源，插回 Markdown 引用；可调用 VLM 生成描述 | 图像描述应保留来源与位置，作为检索补充，不能替代原始图像和原文 |
| 段落级维护 | 段落可编辑、禁用、删除，并触发向量更新 | 段落是检索最小单位；人工纠错必须同步内容、索引和文档统计 |
与现有项目答辩稿的对应关系
当前的项目一深挖稿和项目一速成稿已经覆盖了异步入库、库级 RBAC、chunk、软删、引用和 SSE。此方案能补强的是下面这些追问，而不是替换已有主线。
DOCX、PDF、PPTX、XLSX/CSV 的具体解析、切分和引用定位策略已整理进项目一深挖稿的“多格式解析与分块”，速成版保留一条可背答案。
| 可补强的追问 | 推荐说法 | 先确认什么 |
|---|---|---|
| 为什么要区分个人、组织、公开知识库 | 这是授权模型，不是 UI 分类；不同可见范围对应不同授予与继承规则 | 项目是否真实存在三种范围；是否使用 API Key 映射 |
| 为什么解析器要按文件类型分派 | PDF、DOCX、表格、幻灯片的可引用结构不同，统一转纯文本会丢页码、标题和表头 | 实际用过哪些解析库、能保留到什么定位粒度 |
| 为什么文档编辑后要重建向量 | 检索索引是内容的派生数据，内容变了必须让旧向量失效或版本化重建 | 实际采用同步重嵌入、异步任务还是版本切换 |
| 为什么删除不能只删数据库记录 | 向量索引和对象存储还有副作用；需要状态机、异步清理和可恢复策略 | 是否软删、是否有清理任务、失败时如何补偿 |
| 为什么任务在事务提交后才投递 | 事务未提交就被 Worker 读取，可能读不到文档或拿到不完整关系 | 实际框架的提交后回调、Outbox 或补偿扫描方式 |
方案中需要主动质疑的地方
这份方案是很好的学习来源，但有些描述不能直接照搬成“最佳实践”：
- 跨 MySQL、Elasticsearch 和对象存储的删除不是单一事务。 文档列出级联删除顺序，但没有说明失败补偿、重试、审计和幂等键。真实实现需要 Outbox、可重放删除任务或明确的清理状态。
- 知识库名称“系统全局唯一”未必适合多租户。 多数产品只要求同一租户或同一父节点内唯一；是否全局唯一是产品规则，不能当技术必然。
- 段落更新的图片关联已明确存在一致性缺陷。 文本中删掉图片引用没有解除图片关系，取消更新也可能留下孤儿关系。这正说明富文本资源应当从文本解析出引用集合，再在一个事务中做差量同步。
- “Elasticsearch 是向量数据库”说得太粗。 面试要追问向量字段映射、过滤条件下推、索引版本、相似度度量、召回不足和文本检索是否并行；文档没有给出这些关键细节。
- 图生文不能默认开启。 它增加成本、延迟、隐私面和幻觉风险。应按文档类型、图片价值和评测结果决定，并保留“这是模型描述”的标记。
embedding / success / error状态过粗。 生产链路通常还需要排队、解析、切分、向量化、发布、取消和可重试失败原因，才能支持可观察恢复。
面试可用的三句话
仅在你能确认系统确实如此实现、且该部分确为本人工作时使用：
- “我把原始文件、结构化元数据和检索索引分开管理：对象存储负责可重建源文件，关系库负责生命周期和权限，检索层只保存可替换的派生索引。”
- “多格式文档不能都按纯文本切；PDF 需要页码和目录，DOCX 需要标题和表格，Excel 与 PPT 更适合按工作表和页处理，这些定位信息最终决定引用能不能让用户复核。”
- “异步任务的可靠性不依赖队列永不丢消息，而依赖数据库中的文档状态可扫描、任务可重放、写入幂等；跨存储清理还要有补偿机制。”
下一步核实清单
- [ ] 这份方案对应的系统、时间和本人角色是什么？
- [ ] 实际队列是 Celery 还是 ARQ，Broker 与结果状态分别放在哪里？
- [ ] 实际检索是 Elasticsearch 向量、pgvector，还是两者并存？是否有关键词召回？
- [ ] 支持的文件格式、解析库、页码/标题/表格定位能力分别是什么？
- [ ] 图片抽取和 VLM 描述是否真的上线，成本与失败处理怎么做？
- [ ] 删除、重嵌入和修改段落时，索引与对象存储如何对账？
- [ ] 是否存在可展示的日志、迁移、任务状态、评测或接口证据？
在这些问题没有答案前，本页只用于补课和准备追问；项目经历仍以01 号答辩稿中已核实的事实为准。