引子：从想不起来开始
读《凡人修仙传》或《冰与火之歌》这类超长篇小说，大概率会遇到一个问题。比如读到后面，一个叫“啼魂”的角色再次出现，你会觉得这个名字很熟，但可能已经想不起来它最早是在哪一章、因为什么事件出现的，以及和主角当前的关系是什么。
这种现象很常见。我们的大脑在处理线性故事时很高效，但当面对一个时间跨度极大、内部关系复杂且动态变化的系统时，就容易出现信息丢失或连接错误（跟LLM的幻觉一样）。这个问题不只存在于阅读。在公司这样的组织里，它以一种更普遍的形式存在：
- 一个新工程师想了解某个核心模块的演进历史，会发现相关信息散落在不同时期的Confluence页面、Slack讨论和个人邮件里。
- 一个产品经理想评估一个新功能，需要知道历史上所有相关的尝试和结果。但这些知识往往是零散的，分布在不同团队成员的记忆里，难以被完整、客观地获取。
在这两种场景下，问题的本质是相同的：我们每个人都身处在一个庞大、动态、非结构化的知识网络中，但我们的视角天然是局部的、割裂的。 我们既受限于空间的广度（无法同时了解所有节点），也受限于时间的深度（很难持续追踪所有变化，并保留完整的历史记录）。
过去，解决这个问题依赖于少数经验丰富的专家，或者投入巨大的人力成本进行手动的知识管理。现在，AI技术的发展提供了一个新的可能性：我们能否将记忆和探索这两项高负荷但相对低难度的认知任务，外包给一个自动化、可扩展的AI系统？
因此我决定以《凡人修仙传》这个极端复杂的案例作为实验场，去探索这个问题的解决方案。我用了一套AI系统工程的方法，将这部千万字的鸿篇巨著，处理成了一个结构化的、可交互查询的知识图谱，可以在这里浏览。这个项目最有价值的部分，不是最终的那个数据库，而是整个探索过程沉淀下来的一套方法论，关于如何与现代AI协作，去解决这类复杂的认知任务。
这套方法论可以被概括为一个有些反直觉的公式：笨数据 + 笨方法 + 笨模型 = 精知识。 下面我们展开谈谈这三个笨办法具体是什么，以及它们为何有效。
拥抱笨数据：构建知识处理的基础模块
在构建AI系统的时候，我们很容易陷入一种对初始数据的洁癖，期望AI在第一步就给出精准无误的结果。比如在提取角色时，我们希望它能立刻识别出第一章的厉师兄和第一百章的厉飞雨是同一个人，并且给出精准的角色叙述。但在一个割裂的、缺乏全局上下文的环境里，这是不现实的。这甚至是一个常见的 failure pattern。很多人试着用 AI 去做类似的文本理解，发现它总有各种各样的问题。在稍微尝试了以后就做出结论，现在 AI 还做不到，就放弃了。
所以我的第一个原则，就是拥抱起点数据必然的笨拙。整个系统设计的出发点，就是假设第一遍扫描产生的数据质量一定很差。它会充满重复、错误和遗漏。这没关系。这就像学习任何复杂技能，我们都不可能一步到位。关键在于建立一个能自我修正的循环。
为此，我首先构建了两个最底层的、可被上层流程反复调用的数据访问模块。
第一个模块是线性扫描。在系统的冷启动阶段，它像一个勤奋但没有记忆的学生，一章一章地阅读全文，目标只有一个：把所有看起来像人名、物品名的词都记录下来，形成一个庞大而粗糙的候选实体池。这一步不追求质量，只追求高覆盖率。这是我们获得的最原始、最“笨”的数据，也是我们所有后续工作的基础原材料。
第二个模块是语义检索。有了这份原始数据后，这个模块提供了另一种更强大的数据访问方式。它利用Embedding，将整部小说转化成一个可以计算语义距离的向量空间。当我需要研究“厉师兄”这个实体时，系统可以瞬间在整个文本中，检索出所有在语义上与他相关的段落，即便这些段落里只出现了“厉飞雨”这个名字。这个过程打破了章节的物理壁垒，让我们可以基于全局上下文，对最初的笨数据进行验证和改进。
这两个模块共同构成了我整个系统的数据访问层。它们是底层工具，本身不直接产出最终的知识，但为上层的所有复杂工作流提供了基础服务。接受起点的不完美，并用一个先扫描、后检索的机制去逐步完善它，是整个知识提炼流程得以启动的基础。
接受笨方法：用知识飞轮实现微小但稳定的进步
有了处理数据的基本工具，下一个问题是：如何系统性地提升知识的准确性？比如，如何为掌天瓶这件贯穿全书的法宝，生成一份全面而精准的生平总结？
这里也有两种思路。一种直观的思路是，设计一个完美的Prompt，让LLM一次性读完所有相关段落并给出最终答案，一步到位找到一个完美解。当LLM做不到时，我们就会感到很沮丧。
另一种思路，也是我的选择，是接受方法的“笨拙”，相信迭代的力量。我设计了一个三步走的迭代循环，我称之为知识飞轮，这个循环可以被反复执行，每一轮都让知识的纯度更高一点。这个飞轮的核心思想，是将一个宏大的问题，分解成无数个微小、可验证的子问题，然后设计一个能持续解决这些子问题的自动化流程。
我们可以用一个具体的例子来说明这个飞轮是如何运转的。假设我们最初的笨数据池里，同时存在厉飞雨和厉师兄这两个独立的实体。它们各自有一份通过初步聚合生成的、不完整的信息。飞轮的一圈循环是这样进行的：
- 首先是触发。系统以厉师兄为目标，启动一次信息精炼任务。这一步可以由过滤所有人物的穷举触发，也可以由用户触发。
- 然后是调用基础模块。系统会调用第一章里提到的语义检索模块，输入厉师兄及其已知的上下文信息。检索结果很可能高分命中了包含厉飞雨的段落。这时，系统会将厉师兄和厉飞雨各自的信息片段，以及相关的原文上下文，一起提交给LLM进行判断。
- 接下来，就产生了微小的进步。LLM根据这些信息，判断出这两个实体极有可能指向同一个人。这是一个非常微小、原子级别的新知识。
- 最后一步是精炼。系统根据这个新知识，执行更新操作。它会聚合原先分属于两者的信息，并修改知识库，将厉师兄标记为厉飞雨的别称，或者将两者直接合并为一个实体。
这个过程看起来非常笨拙。我们可能调用了数次检索和LLM，仅仅是为了合并一个角色的两个别称。而一个角色可能有七八个别称，小说里有数千个角色。这意味着这个飞轮需要不知疲倦地转动成千上万次。但这个笨方法的优势在于它的稳定性和收敛性。每一次循环都是一个逻辑清晰的独立过程，成功率很高。
更重要的是，每一次成功的合并，都意味着知识库的整体质量在确定性地提高。即使每次进步微不足道，但通过大规模的、自动化的循环，这些微小的进步会累积成巨大的质变。并且，这个过程是自我增强的。当厉师兄和厉飞雨合并后，未来以这个更完整的统一实体为种子进行的语义检索，将会找到更全面、更精准的信息，让下一轮的飞轮转动得更有效率。
这个笨方法的核心，是用系统的、自动化的方式，去管理和累积无数个微小的进步。它不依赖于单次调用的灵光一闪，而是相信迭代本身的力量。在当前AI能力和成本结构下，这提供了一条更稳健、更可控的通往精知识的工程化路径。
选择笨模型：从成本焦虑到创造自由
上面这套重型、迭代式的框架，其能实现的关键，在于动力源泉的选择。这里，我提出了第三个，也是最大胆的原则：选择一个在通用能力上更笨的开源模型。我最终在本地部署的Qwen3-32B。这是一个经过蒸馏的、320亿参数规模的模型。无论从哪个通用能力排行榜来看，它的综合性能都无法与gemini 2.5这类顶级的、数万亿参数规模的闭源模型相提并论。
但恰恰是这个选择，最终解放了整个项目的潜能。原因不在于模型本身的能力，而在于它改变了我的工作方式和心态。这可以从我最初尝试使用闭源API的经历说起。当我使用闭源API时，我发现自己始终被两种枷锁牢牢束缚：
第一种是成本焦虑。按token计费的模式，意味着每一次API调用都在消耗实实在在的预算。这带来了一种持续的心理压力。我不敢轻易尝试那些计算量巨大的笨方法，比如让模型对几千个实体进行两两对比。我会花费大量时间去优化prompt，试图用最少的调用次数、最少的token消耗来达成目标。这种心态，让我的思考始终在最佳效果和最低成本之间反复拉扯，极大地限制了探索的自由度。
第二种是节奏拖累。为了节省费用，我倾向于使用能打五折的批处理请求。但这类请求的响应时间通常是以小时来计算的。我的工作流因此变得支离破碎：提出一个想法，提交一批任务，然后是漫长的等待。这种“提交-等待”的模式，完全打断了“思考-验证-调整”的流畅节奏。很多灵感和改进的冲动，都在这漫长的等待中被消磨殆尽了。
整个项目在闭源API上推进的初期，就在这种成本焦虑和节奏拖累的双重困扰下，进展缓慢且充满妥协。而且因为小说的篇幅实在太长，第一个版本还是花了两百多美元。看到账单以后我的心态崩了，所以转向了在本地硬件上部署Qwen3-32B。
这其实不是我第一次做这样的尝试。在过去，我多次试图用开源模型来代替闭源模型，但几乎每次都以失败告终。失败的原因主要有两点：一是模型本身的智能程度确实不够高，很多时候光是让它稳定输出合法的JSON格式，都需要花费大量精力去调整prompt；二是本地推理的效率太低，在消费级硬件比如Macbook上运行，速度慢到不切实际。但这一次我发现，成功的两个关键前提，在近期都已成熟。
第一个前提是模型能力的质变。我选用的Qwen3-32B，它的智能程度和指令遵循能力比我之前用过的开源模型有了显著的提高。在我的任务中，它甚至不需要特别的prompt微调或者强制JSON输出模式，就能非常稳定地生成我需要的JSON格式，这极大地降低了开发和集成的复杂度。
第二个前提是推理平台生态的成熟。我最近升级了硬件，使用了5090集群，同时像vLLM这样的推理框架对新硬件的支持也已跟上。使用INT4量化，我可以用两张5090显卡就运行一个32B 128k上下文窗口的模型的推理实例。在高并发的场景下，我观察到的prompt处理吞吐量可以高达每秒三四千token，生成吞吐量也能达到每秒两三百token（非同时）。这个速度，已经让本地推理变成了一个在实践中完全可用、效率颇高的解决方案。
正是在这两个前提的加持下，我转向本地部署的尝试，才最终取得了成功。这个转变带来的，不仅仅是成本结构的变化，更是一种开发范式上的改变。这个相对笨的模型，我可以完全掌控。一次性的硬件投入之后，每一次调用的边际成本几乎为零。这意味着我获得了近乎无限次的、自由的调用能力。前面提到的那个需要几十万次循环的笨方法，也从一个不切实际的、成本高昂的幻想，变成了一个可以随时启动、运行一整天的后台任务。
成本焦虑消失了，节奏的束缚也被打破了。我可以即时地验证我的每一个想法，流畅地进行迭代。我可以大胆地让模型去执行那些最繁重、最机械的认知穷举任务，而我则可以把全部精力投入到设计和优化整个知识飞轮系统本身。最终，这个笨模型，让我得以真正地驾驭它，而不是被它的成本和延迟所束缚。
结语
将《凡人修仙传》这样的宏大叙事结构化，是一次关于如何应用AI处理复杂、海量非结构化信息的探索。这个过程让我相信，我们正在从一个依赖提示词魔法的阶段，逐渐走向一个更需要系统性思考、拥抱迭代、并善用工具的AI系统工程阶段。
这个由笨办法驱动的知识飞轮，实际上就扮演了我们最初设想的那个角色：一个自动化、可扩展的外部记忆系统。它不知疲倦地执行着记忆和探索这两项高负荷但相对低难度的认知任务，将一个容易遗忘、容易混淆的个人，升级成了一个拥有近乎完美记忆和强大探索能力的增强型读者。
回到我们开篇提到的那个公司知识管理的困境。这套方法论同样提供了一个可行的路径：它能够将散落在Confluence、Slack、邮件等各个角落的、非结构化的信息进行自动化地连接与整合，最终构建出一个组织的可查询的集体大脑。它让那些沉没的、零散的知识得以浮现和连接，降低了组织内部信息获取的成本和摩擦力。
最终，这个项目成功的关键，似乎都指向了那些反直觉的笨办法：接受不完美的“笨数据”，设计可迭代的“笨方法”，并选择一个性能足够但完全可控的“笨模型”。这或许说明，在与AI协作的未来，我们作为开发者的核心价值，将更多地体现在如何设计一个聪明的系统，去驾驭这些强大的工具，而不是单纯地追求工具本身的超级智能。
Comments