用 LLM Wiki 的"编译"思想替代 Dify 的自动解析，砍掉不稳定的分类环节，大幅提升输出质量。

问题诊断

当前工作流存在三个连锁问题：

1. Dify 文档解析差 — 自动分段产生信息碎片，缺乏上下文
2. LLM 问题分类不稳定 — 同一个问题可能被分到不同类别，下游检索随之偏移
3. 输出不稳定 — 垃圾片段进 → 垃圾回答出

核心差异

RAG 和 Compiled Wiki 代表了两种不同的"LLM + 知识"范式，它们在知识的存储、组织和利用方式上存在根本差异。

RAG 的工作方式

RAG（Retrieval-Augmented Generation）的工作流程是：

1. 用户提出查询
2. 系统将查询转换为向量，在知识库中检索相关文档片段
3. 将检索结果作为上下文注入 Prompt
4. LLM 基于注入的上下文生成回答

本指南从工程实践角度讲解如何构建 RAG（检索增强生成） 系统，覆盖文档处理到质量评估的完整链路。

文档加载和分块

文档分块（Chunking）是 RAG 效果的基础：

• 固定长度分块：按 token 数（通常 256-1024）切分，简单但可能切断语义完整段落
• 语义分块：按段落或章节边界切分，保持语义完整性，推荐作为首选策略
• 递归分块：先按大单位（章节）切分，再对过长段落递归切分，兼顾粒度和完整性
• 重叠窗口：相邻块之间保留 10-20% 的重叠内容，避免关键信息恰好在切分边界被截断

RAG（Retrieval-Augmented Generation）是一种将外部知识检索与 LLM 生成能力相结合的技术范式。它通过在推理时动态检索相关文档，将检索结果注入 prompt 上下文，从而让模型在不修改参数的情况下获取最新、特定的知识。

基本原理

RAG 的工作流程分为两个核心阶段：

1. 检索（Retrieval）：用户查询经过 embedding 模型编码为向量，在向量数据库（如 Pinecone、Milvus、Weaviate）中进行语义搜索，找到最相关的文档片段。语义搜索相比关键词匹配能更好地理解查询意图。
2. 生成（Generation）：检索到的文档片段作为上下文，与用户查询一起送入 LLM，由模型基于这些上下文生成回答。