MVP 技术方案一致性 Review
# MVP 技术方案一致性 Review
1. Review 结论
MVP 技术产品整体可以自洽，但原方案存在一个关键职责重叠：RAGFlow 与独立 Qdrant 同时承担 RAG/向量检索能力。
已调整方案：
- RAGFlow 是 MVP 的智能体、RAG、问答和引用事实入口。
- Meilisearch 是 MVP 的人用全文搜索入口。
- Agent Access API 是外部智能体使用 LLM-WIKI 的受控入口。
- 不单列独立向量数据库产品；向量存储纳入 RAGFlow 实施方案，当前倾向优先评估 pgvector。
- LLM-WIKI 控制面负责治理、编排和 adapter，不重新实现 RAG 引擎、搜索引擎或文档站。
2. 发现的问题
2.1 RAGFlow 与 Qdrant 职责重叠
原方案中：
- RAGFlow 负责文档解析、chunk、检索、重排、问答和引用。
- Qdrant 也被定义为 MVP 向量检索产品，负责 chunk 向量索引、RAG 召回和引用定位。
这会导致两套 RAG 事实源。
风险：
| 风险 | 说明 |
|---|---|
| 双 chunk | RAGFlow 和 Qdrant adapter 可能切出不同片段。 |
| 双 embedding | 两套索引可能使用不同 embedding 模型。 |
| 双 metadata | 页面路径、heading anchor、source ref 不一致。 |
| 双删除 | 文档删除后可能仍从另一套索引召回。 |
| 双引用 | 问答引用和页面回跳来源不一致，责任不清。 |
处理：
- MVP 删除独立 Qdrant 索引链路。
- RAGFlow dataset / RAG 索引负责问答召回。
- 删除 Qdrant 单列文档；向量存储决策进入 RAGFlow 技术方案。
2.2 RAGFlow 与商业 LLM API 的边界
潜在重叠：
- RAGFlow 可以管理模型供应商和模型 key。
- LLM-WIKI 文档中也定义了
ModelProvider抽象。
处理：
- MVP 中模型 key 优先配置在 RAGFlow。
- LLM-WIKI 只保留
model-policy.yaml，用于描述用途、预算和策略。 - 除非控制面需要直接调用模型，否则不实现独立 ModelProvider。
2.3 RAGFlow 问答 API 与 LLM-WIKI Answer API 的边界
潜在重叠：
- RAGFlow 可以直接提供问答 API。
- LLM-WIKI 又定义 Answer API。
处理：
- LLM-WIKI Answer API 是薄封装，不是第二套问答引擎。
- 它只负责权限、scope、标准化输出、引用格式、反馈任务和前端协议稳定。
- 生成答案、RAG 召回和引用证据由 RAGFlow 负责。
2.4 Meilisearch 与 RAGFlow 搜索的边界
潜在重叠：
- RAGFlow 能做知识检索。
- Meilisearch 也做搜索。
处理：
- RAGFlow 面向问答召回和智能体上下文。
- Meilisearch 面向人的站内关键词搜索、导航和搜索结果页。
- 搜索结果可提供“转问答”入口，但不参与答案生成事实链。
2.5 Agent Access API 与 RAGFlow/Answer API 的边界
潜在重叠：
- RAGFlow 可以回答问题。
- Answer API 可以对人和智能体提供问答。
- Agent Access API 也暴露 ask 工具。
处理：
- RAGFlow 是问答和 RAG 事实执行者。
- Answer API 是面向前端和人的标准化问答接口。
- Agent Access API 是面向智能体的工具入口，除 ask 外还提供 search、get-page、get-context、create-feedback 和 create-improvement-task。
- Agent Access API 不生成第二套答案，只做 scope、权限、ContextPack、审计和工具编排。
2.6 Docusaurus 与 GitHub 编辑的边界
没有实质冲突。
边界：
- Docusaurus 只展示已审批文档。
- 编辑入口跳转 GitHub PR 流程。
- Docusaurus 不保存正式内容，不直接修改
publish/**。
2.7 GitHub Issues 与 RAGFlow 任务的边界
没有实质冲突，但需要明确主从关系。
边界：
- GitHub Issues 是任务事实源。
- RAGFlow 是任务执行者。
- RAGFlow 输出必须回到 GitHub PR，不能直接关闭任务或发布内容。
3. 调整后的产品边界
| 技术产品 | MVP 职责 | 不负责 |
|---|---|---|
| GitHub | 仓库、PR、审批、Actions、Issues、权限、审计 | 文档渲染、RAG、搜索生成 |
| LLM-WIKI 控制面 | 配置、三方 diff、发布目录治理、adapter、标准协议 | 通用文档站、RAG 引擎、搜索引擎、模型服务 |
| Docusaurus | 展示已审批文档、页面入口、前端挂载点 | 保存正式内容、审批、RAG |
| RAGFlow | 文档迭代、RAG 索引、问答、引用、Agent 执行 | Git 审批、正式发布、站内关键词搜索 |
| Agent Access API | 智能体工具访问、scope、ContextPack、反馈桥接、调用审计 | RAG 生成、文档发布、直接写 Git |
| Meilisearch | 人用全文搜索 | RAG 答案事实链、文档改写 |
| 商业 LLM API | 模型能力 | 流程治理、文档发布 |
4. 调整后的数据流
5. 最终 MVP 技术组合
| 类别 | 技术产品 | 状态 |
|---|---|---|
| 治理底座 | GitHub | 必选 |
| 控制面 | LLM-WIKI 自研 | 必选 |
| 展示 | Docusaurus | 必选 |
| 智能体/RAG/问答 | RAGFlow | 必选，已部署 |
| 智能体访问 | LLM-WIKI Agent Access API/tool adapter | 必选 |
| 全文搜索 | Meilisearch | 必选 |
| 模型 | 商业 LLM API | 必选，由 RAGFlow 优先管理 |
| 向量存储 | RAGFlow 内部 实施，优先评估 pgvector | 不作为独立 MVP 产品 |
6. 实现约束
- 不建设独立向量索引 workflow，除非后续 ADR 明确把向量数据库升级为独立产品。
docs-index.yml只更新 RAGFlow dataset 和 Meilisearch。- Answer API 只能调用 RAGFlow 生成答案，不直接拼装第二套 RAG。
- Agent Access API 只能编排 RAGFlow、Meilisearch、GitHub 和元数据，不直接生成第二套知识事实源。
- Docusaurus 只读已审批
publish/**构建产物。 - GitHub Issues 是反馈任务事实源。
- RAGFlow Agent 输出必须转为 Release PR。
7. 后续可选决策
如果未来要把向量数据库从 RAGFlow 实施细节升级为独立产品，需要先做 ADR，至少回答：
- RAGFlow 是否继续负责问答召回。
- 独立向量库与 RAGFlow 的 chunk schema 谁是事实源。
- embedding 模型由谁管理。
- 删除、回滚、版本如何同步。
- 引用回跳由谁生成。