你拿了 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三个月后可以追溯硬件排除是怎么建起来的、融合了哪些来源、影响了哪些已有页面——知识演化链条完整可查。什么时候不要融合每份来源独立成体系时不融合大量重复内容时不融合选一份做基础标注另见副本矛盾太多时不融合建对比页面列各派观点。融合不是银弹。它解决碎片化问题但不解决信息冗余问题也不解决观点冲突问题。知道什么时候不用和知道什么时候用一样重要。
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三个月后可以追溯硬件排除是怎么建起来的、融合了哪些来源、影响了哪些已有页面——知识演化链条完整可查。什么时候不要融合每份来源独立成体系时不融合大量重复内容时不融合选一份做基础标注另见副本矛盾太多时不融合建对比页面列各派观点。融合不是银弹。它解决碎片化问题但不解决信息冗余问题也不解决观点冲突问题。知道什么时候不用和知道什么时候用一样重要。
