Ch46: 挑战深读⑧——Memory 冲突与平台互操作

Part 10 · 合并 challenges #10 + #11 · Ch15 Memory vs RAG · Ch33 Dify 源码走读

结论先行：#10 Memory 记对话推断，RAG 引文档事实——矛盾时无行业标准，产品应 文档优先 + 矛盾显式提示，而非静默覆盖。#11 chunk schema、向量存储、API 协议 五平台互不兼容；MCP 统一了 调用，未统一 数据。大师在 WeKnora 内做 可配置裁决策略 + 标准 chunk export；跨平台用 中间 JSONL + 解析/检索分离，而非幻想一键 import Dify chunk。

一、日常类比：便签本 vs 员工手册

Memory 像用户随身便签（「我们已迁 PostgreSQL」）；RAG 像公司印刷的员工手册（仍写 MySQL）。#10 是助理同时信便签和手册，回答自相矛盾。#11 像五家公司用不同档案柜格式——RAGFlow 的 PDF 解析柜、WeKnora 的检索柜、Dify 的流程柜，标签字段对不上，搬档案要手写胶水脚本。

二、Memory vs RAG（#10）

典型冲突：用户说已迁 PostgreSQL（Memory），KB 仍写 MySQL（RAG）→ 幻觉或双版本答案。

WeKnora 自维护 Wiki 可 标记矛盾 Ch31，不自动裁决——与 DB-Agent-Memory 双系统见 rag-agent-integration。

反例：文档过时、Memory 正确（口头已上线新栈）→ 纯「文档优先」错；需 时效元数据 + 用户确认写入 Memory。

三、互操作三层不兼容（#11）

MCP 能 / 不能：

• 能：Claude / CatDesk 经 MCP 调 WeKnora 检索 Ch12
• 不能：Dify 导出 chunk 直接 import WeKnora 向量库

最小架构（解析—检索分离）：

DeepDoc/RAGFlow → Markdown/JSONL 中间格式
       ↓
统一 ingest（WeKnora chunker + embed）
       ↓
SoT 检索在 WeKnora；Dify 仅编排 UI（或反之，只选一家 SoT）

走读对照：Ch33 Dify · Ch34 RAGFlow · Ch37 五平台实验。

四、标准 chunk schema（贡献靶心）

建议中间 JSONL 字段（概念）：

{"text":"...", "metadata":{"doc_id":"","lang":"zh","source_credibility":0.9,"version":"2026-07"}}

五、实验

#10：构造 5 条「Memory 新 / 文档旧」用例（含 PostgreSQL/MySQL），对比：仅 RAG / 仅 Memory / 双标记 / 文档优先+提示 / 询问用户。记录用户可理解的 矛盾 UX 草图（一句提示即可）。

#11：从 lab/corpus 导出 Markdown → 手写 JSONL → WeKnora ingest；记录 丢失字段 清单（与 Dify chunk 文档对照）。可选：MCP 检索 + Dify HTTP 节点编排 只调 API、不迁向量 的最小 demo。

Issue：case-1761 缓存与 Memory 边界；case-1774 API 分层。

六、贡献方向

• Admin：文档优先 可配置 + 矛盾时 UI 双来源 chip
• Memory 写入 opt-in 确认（防口误固化）
• WeKnora 标准 chunk export/import + scripts/migrate-chunks/ PoC
• MCP 文档：与 Dify Workflow HTTP 对接示例（链 Ch33）
• Wiki inspector 输出与 Memory 冲突对齐 Ch31

章末自检

• 说清 Memory 与 RAG 各自适合什么信息（各 2 例）
• 举一例「文档过时、Memory 正确」及你的裁决策略
• 区分 MCP 解决的「调用统一」与未解决的「数据统一」
• 列 2 个无法直接跨平台迁移的 chunk 字段差异

延伸阅读

• Ch15 Memory vs RAG · Ch33 Dify 源码
• Ch31 Wiki 自维护 · Ch37 五平台实验
• rag-agent-integration § 三种集成模式 · challenges.md §10 + §11