LLMWiki_VS_RAG调研

First Post:

Last Update:

🛠️ 传统 RAG vs LLM Wiki：全维度技术栈实现对比

技术维度 核心考量点 传统 RAG (动态运行时架构) LLM Wiki (静态编译期架构)
**1. 文档分块
(Chunking)**​		 文本切分的
语义完整性​		 机械切割 (Naive Splitting)
依赖递归字符分隔或固定Token窗口强行切分。极易破坏表格、代码块和长逻辑链条的完整性。		 语义重构 (Structural Parsing)
基于自然语言边界解析，并由LLM动态重写为逻辑自洽的Markdown卡片，保留完整的可读性与上下文。
**2. 数据摄入
(Ingestion)**​		 算力消耗的
时空置换​		 “无脑”向量化 (Embarrassingly Parallel)
摄入极轻，仅做向量编码。所有语义关联计算堆积到“用户查询时”，导致查询延迟高。		 大模型驱动ETL (LLM-Powered ETL)
摄入极重，调用LLM做实体抽取、消歧。空间换时间，预烧Token以降低查询期算力。
**3. 交叉引用
(Cross-Ref)**​		 关系推理的
效率与准确性​		 临时暴力计算 (Post-Retrieval)
块间天然孤立。依赖大模型在有限的Context Window里临时“盲猜”隐藏逻辑，易产生幻觉。		 预置知识图谱 (Auto KG)
编译期自动提取实体关系，生成双向链接(Backlinks)。查询时通过图遍历“顺藤摸瓜”，精准高效。
**4. 知识归档
(Archiving)**​		 资产沉淀与
复利效应​		 无归档，仅有索引 (Index Only)
RAG只存储原始碎块和向量。无法沉淀人类的推导、总结和洞察。知识库是静态的死数据。		 结构化知识库 (Living Knowledge Base)
核心优势。LLM在摄入时会生成摘要、FAQ和洞见，并将其固化为Wiki页面。知识库随使用指数级增值。
**5. 答案生成
(Generation)**​		 结果的持久性
与复用性​		 临时生成，即刻丢弃 (Stateless/Ephemeral)
每次对话结束后，大模型生成的优质答案直接丢弃。下次遇到同样问题，需重新检索、重新计算，造成算力浪费。		 反馈闭环，自我进化 (Feedback Loop)
可将对话中产生的优质问答对（QA）反向合并（Merge）入Wiki。一次计算，永久复用，形成“集体记忆”。
**6. 存储与基建
(Infrastructure)**​		 运维成本与
系统复杂度​		 重型微服务 (Microservices Spaghetti)
强依赖Vector DB、Embedding API及编排框架。分布式数据一致性难保，运维是“灾难级”。		 极简本地化 (Local-first & Git-based)
无需数据库，纯文本Markdown + Git。像管理代码一样管理知识，git pull即部署，支持离线运行。

为什么“归档”和“丢弃”如此致命？

1. RAG 的“西西弗斯陷阱”（The Sisyphean Trap）

在 RAG 体系下，你的团队每天都在做重复性劳动。

  • 场景：用户问：“我们公司2024年的报销政策是什么？”

  • RAG 的做法：检索3个PDF碎片 -> 大模型拼凑答案 -> 用户得到回复 -> 结束。

  • 问题：第二天另一个用户问一模一样的问题，系统还得重新检索、重新拼凑、重新消耗 Token。你永远在推石头上山，知识没有积累。

2. LLM Wiki 的“复利效应”（Compounding Returns）

在 LLM Wiki 体系下，你的每一次交互都在建设数字资产。

  • 场景：同上问题。

  • LLM Wiki 的做法：

    1. 编译期：已将2024报销政策写成清晰的 Wiki 页面 Policy_2024.md。

    2. 查询期：直接读取该页面，给出答案。

    3. 归档期（杀手锏）：如果用户追问了一个 Wiki 里没有的细节（例如“海外出差补贴”），LLM 在回答后会自动生成一个新的 Wiki 页面 Overseas_Travel_Allowance.md，并链接回主政策页。

  • 结果：你的知识库会自动生长，越来越聪明，运维成本越来越低。

🚀 架构选型

  • 选 RAG 如果：你的数据是短暂且海量的（如实时新闻流、全网爬虫），你不需要保留中间的推导过程，只要最终答案。

  • 选 LLM Wiki 如果：你的数据是高价值的私有知识（如内部手册、技术文档、项目复盘），你希望团队的知识能够沉淀、传承和复用，且极度厌恶高昂的重复算力成本。

    🔗 反向链接

    以下页面引用了本文：