LLM Wiki应用之多源融合篇——十份来源如何变成一个完整页面

你拿了 10 篇文章，每篇 2000 字，讲同一个主题的不同侧面。怎么把它们变成一个结构化的 Wiki 页面？

直接拼接？结果是一篇 20000 字的流水账，没人会读完。逐一建页？结果是 10 个碎片化的独立页面，读者永远拼不出全貌。

LLM Wiki 的设计里有一个专门的处理模式——多源融合（Multi-Source Convergence）。它的核心思路是：M 份来源变成 1 个综合页面，而不是 M 份来源变成 M 个独立页面。这篇文章用我的硬件排除页面（10 份来源、从 0 到 10 入站链接）作为完整案例，拆解融合的全过程和关键决策。

什么时候用多源融合

判断标准很简单。适用条件：主题是交叉的——硬件排除涉及电源、时钟、DDR、外设等 8 个不同概念，但排查时需要一个统一入口。每份来源单独看太薄——一份只有上电时序说明的 800 字笔记，单独立页撑不起来。用户明确要求做一个总纲页面。

不适用条件：每份来源本身足够独立成页——YOLOv8 模型转换和 HRNet 姿态估计是独立技术主题。来源之间有大量重复——10 份文档 8 份讲同一件事，融合只会制造冗余。

关键原则：融合解决的是"碎片化"问题，不是"信息过载"问题。如果 10 份来源各自已经是一篇完整的好文章，融合就是画蛇添足。

真实案例：硬件排除页面的诞生

输入材料：10 份排查相关的来源文件，总计约 9100 字。包含电源管理踩坑记录、DDR4 初始化失败日志、传感器时钟异常笔记、外设接口排查步骤、RTSP 推流失败原因、SVB 调压异常分析、DDR 参数配置错误排查、启动失败诊断流程、烧录失败原因分析、环境适应性测试报告。

Agent 的四步融合流程如下。

第一步：选锚点文档。Agent 先读启动失败诊断流程——它覆盖面最广，涉及电源、时钟、DDR 三个排查方向。锚点文档决定了融合页面的组织框架。选择锚点不是选最长的，是选覆盖面最广的。一份 3000 字的纯电源分析不如一份 1500 字的启动失败诊断——因为后者触及多个子系统。

第二步：提取公共维度。从锚点中归纳出故障分类框架。先按故障大类分——烧录失败、启动失败、功能异常、环境异常。再按排查方向分——电源、时钟、内存、外设、网络、传感器。4x6 的矩阵就是融合页面的骨架。维度太少则信息丢失，太多则融合页退化为目录。实践中从锚点提取 3-5 个顶级分类，再从其他来源补充 2-3 个子方向，最终 6-8 个维度最优。

第三步：逐源映射。把 10 份来源一一映射到骨架。电源管理踩坑记录指向排查方向[电源]，DDR4 初始化失败指向排查方向[内存]，传感器时钟异常指向排查方向[时钟]。如果来源内容不匹配任何已有维度，新增维度而不硬塞。环境适应性测试就是新增维度——启动失败诊断的框架里没有这一项，但它确实是一个独立排查方向。

第四步：生成总纲。Agent 按先总后分结构组织——快速诊断决策树在最前（10 行：问题到大类到方向到页面），然后是故障大类展开（4 个大类各一段总述），接着是排查方向详解（6 个方向各含症状和步骤），最后是结构化踩坑记录（每条现象原因解决三段）和关联页面索引。

最终产物：concepts/硬件排除.md，约 400 行，入站链接从 0 成长到 10，仅次于 Hi3519DV500 芯片的 15。

融合中的三个关键判断

哪些信息进总纲，哪些留子页面？总纲写排查框架和入口，不写技术细节。电源排查在总纲里只有一段——常见症状加排查思路。具体寄存器配置和示波器截图都在电源管理页面里。总纲是导航地图不是百科全书。如果融合页的前后段像两篇不同的文章，就该拆。

多源矛盾怎么处理？DDR4 初始化失败日志说训练失败因为走线不等长，SVB 调压分析说因为电压偏低。Agent 不选一个——两个都列上，标记 contested: true。工程实践中很多问题根因不是单一的，Agent 标注"两个都有可能"比选一个更接近真相。

融合后要不要删原始来源？不删。raw/ 里 10 份原始文件保留。Wiki 页面是编译产物，源文件是一手资料——两者共存互为补充。

反面案例：三种融合失败

过度融合：把电源管理原理和电源排查融为一页。前半段讲供电架构，后半段讲万用表测电压——逻辑分裂。原理留在概念页，排查进总纲。

重复融合：电源管理页面已有详细排查步骤，硬件排除里又写一遍。硬件排除只写排查方向指向电源管理，不重复内容。

忽略回链：融合页建好了链了 8 个已有页面，但已有页面没回链。读者从电源管理出发找不到硬件排除。Agent 必须在融合后执行 backlink 同步。

TF-IDF 在融合中的作用

Agent 在融合前需要判断哪些来源讲的是同一件事。靠 TF-IDF 自动聚类。

直觉理解：一个词频繁出现在当前文档中，但在其他文档中很少出现——这个词对当前文档很重要。Agent 对 10 份来源计算 TF-IDF，发现电源管理的高频词是电压、PMIC、上电、纹波；DDR4 初始化的高频词是 DDR、训练、CL、走线；传感器时钟的高频词是时钟、MIPI、晶振、PLL。

这些高频词各不相同——说明 10 份来源讲的是不同侧面，不是同一件事的 10 个副本。如果 TF-IDF 显示所有文档高频词高度重叠，那就是重复内容，不需要融合，直接选最全面的一份。

聚类的实战结果：10 份来源聚为 3 组——电源相关 2 份、内存相关 3 份、外设时钟网络相关 5 份。正好对应排查方向的三大类。环境适应性不属于任何一组——应新增维度。

融合 vs 拆分的决策树

问三个问题。第一：这 10 份来源讲的是同一件事吗？是则融合，否则各自独立建页。第二：单份信息量够建独立页面吗（> 800 字且有独立主题）？够则分别建页，不够则融合。第三：融合后页面超 400 行吗？不会则一页到底，会则拆分为总纲加子页面。硬件排除案例三个问题都指向融合——完美匹配。

融合的 log 记录

每次融合操作在 log.md 留下完整记录。有了这行 log，三个月后可以追溯：硬件排除是怎么建起来的、融合了哪些来源、影响了哪些已有页面——知识演化链条完整可查。

什么时候不要融合：每份来源独立成体系时不融合，大量重复内容时不融合（选一份做基础标注另见副本），矛盾太多时不融合（建对比页面列各派观点）。

融合不是银弹。它解决碎片化问题，但不解决信息冗余问题，也不解决观点冲突问题。知道什么时候不用和知道什么时候用一样重要。