wiki方案的工程实现

[Altergom]

相关链接

背景

• 传统RAG方案过于笨重，本项目文档数量预计1000以内RAG方案存在浪费资源的问题
• RAG方案只能提取query相似度高的答案，但在面试场景中通过A和B在某些地方的关联性深入追问到B是常见行为，
  RAG难以实现关系性效果必须引入知识图谱增大耦合
• wiki天然具备文档内联性关系，能通过文档A了解文档B是wiki的基本要求
• wiki全程仅需grep操作无需引入任何外部工具，轻量

个人理解

• 要实现wiki我们需要三个基本组件（schema、raw、wiki）
• shema：核心中的核心，定义模型行为规范
• raw：原始知识库，只能添加不能删除绝不能修改，尤其是修改命名
• wiki：知识库的结构化产物，包含来源摘要、实体页、概念页、操作日志等，由模型全权维护，是 raw 经过提炼和综合后的持久输出
• 项目最核心的资产是 schema 的 git 演化历史，沉淀的每次踩坑后形成的决策规则

落地方案

• 三个组件，分工清晰：
  schema
  └── 模型行为规范，定义 ingest/query/lint 流程
  命名规范、边界决策规则、页面结构约定
  raw/
  └── 原始来源，append-only
  文章、论文、会议记录等，模型只读不写
  wiki/
  └── 模型全权维护
  index.md、log.md、来源摘要、实体页、概念页、综合页等

• 工作流程：
  你往 raw 里加文档
  → 告诉模型 ingest
  → 模型更新 wiki 相关页面
  → 你在 Obsidian 里浏览结果
  → 定期让模型 lint 检查健康度

可预见的问题

• 跨 session 连续性
  模型每次都是空白启动，完全依赖 log.md 和 index.md 重建上下文。这两个文件一旦维护不好，模型就会失忆行为开始不一致
• 内联质量不稳定
  模型生成的 wikilink 密度难以控制，早期页面链接天然不完整，不同 session 命名不一致会增大模型理解成本，这要求我们在 schema 里严格定义命名规范，同时还需要人工定期检查
• 检索能力的规模天花板
  小规模靠 index.md 够用，中规模开始需要引入 BM25+向量混合检索
• schema 边界规则缺失
  模型在面对"并入已有页面还是新建页面"、"来源矛盾怎么处理"这类歧义时完全依赖 schema 的规则。规则没覆盖到的情况模型每次决策可能不一致，wiki 会随时间变乱
• 模型能力的隐性依赖
  整个方案的质量上限就是模型的能力上限，换模型可能导致行为和之前 schema 预期的不匹配，需要重新校准

[Altergom]

认真思考后得到以下结论

• schema决定了追问的方向，进而决定追问的效果
• 我们可以通过图的思想去构建wiki，高度数的节点必然是基础知识，完全可以从基础知识出发也符合面试的流程
• obsidian有可视化能力，完全可以通过拖拽的形式减少大量人为定义schema的成本
• 节点与节点之间关系大体可分为深挖、横向、跨域三个方向，完全可以通过预定义边类型的形式控制模型搜索路径