115 lines
7.3 KiB
Markdown
115 lines
7.3 KiB
Markdown
# Karpathy用「harness」彻底终结了RAG
|
||
|
||
> 来源: https://mp.weixin.qq.com/s/ABzwrSGeFs1Wv2RUBjLtwg
|
||
> 抓取时间: 2025-04-10
|
||
|
||
---
|
||
|
||
假期的时候，Karpathy 大神发了一个llm.wiki的想法。 这条推文火爆了。
|
||
|
||
在LLM Agent时代，分享具体代码或应用的意义正在变弱，现在只需要分享想法，然后把它交给 Claude、Grok 等 Agent，它就可以根据你的需求，自动搭建一个属于你自己的个人知识库。
|
||
|
||
还有最近特别火的各种 personal skill ，同事.skill、前任.skill、自己的skill，甚至卡兹克把自己的创作skills都开源了。。。。
|
||
|
||
整体看下来我觉得它们都在做一件事情：把现实世界里原本只能"看"的东西，编译成 AI 可以持续操作的东西。
|
||
|
||
llm.wiki 在编译知识。创作 skill 编译方法论。persona skill 编译人格。
|
||
|
||
全网的博主都在分享理论。今天我们分享一下如何能跑通这种知识的编译。
|
||
|
||
llm.wiki这套理论虽然看起来就是又一次渐进式披露的实践。
|
||
|
||
但是很多人觉着，这不只是一个 AI 工具，而更像是一种元框架（meta-framework）。它并不依赖某个具体模型或技术栈，而是在尝试定义一种人类与 AI 协作管理知识的方式。随着模型不断迭代、框架持续演进，让 LLM 帮助编译并维护一个持续生长的 Wiki 这一模式，反而具备更长期的稳定性和适用性。
|
||
|
||
## 所以llm.wiki在干什么？
|
||
|
||
过去，大模型使用文档，都是用RAG。问一个要综合五份文档的问题，模型每次都要重新找、重新拼。没有积累。NotebookLM、ChatGPT 的文件上传，其实都是这个模式。
|
||
|
||
但是llm.wiki的模式是： 你丢一份新材料进去，模型不是索引它等着以后检索，而是立刻读它、提炼它、把关键信息编入已有的 wiki。更新实体页、修订概念页、标注新旧数据的矛盾。一份材料可能触及十几个 wiki 页面。
|
||
|
||
而且知识编译一次，然后持续维护。不是每次都从头来。
|
||
|
||
这个模式其实非常有意思，不止可以用在建个人wiki场景，还可以往很多场景拓展，比如记忆。
|
||
|
||
karpathy大佬举了一些场景case，如下图，也很实用。尤其是今天的ai发展的这么快。前脚龙虾，后脚就hermes。上个月的harness，可能这个月就要拆掉一些了。 这种知识的管理。不论是对个人，还是对自己的agent系统都非常重要。
|
||
|
||
正常情况下，如果想打通这种自动wiki工作流，很容易遇到各种奇形怪状的数据。但是llm.wiki 这些，都假设数据是干净的markdown，这还还挺不符合实际场景的。
|
||
|
||
所以，我找了一批更符合真实场景的数据，但是也没有精挑细选。主要是Anthropic、OpenAI关于harness的博客。还有新模型mythos的博客、智谱glm5.1的博客、以及智谱的招股书（本来准备下载财报的，好像下错了，不过这个500多页pdf，也有很多复杂的图表）。
|
||
|
||
然后就可以开始按照llm wiki的要求3层架构构建了。
|
||
|
||
把llm.wiki丢给agent，会自动构建好目录结构。 我用的 cursor + opus 4.6。raw 放原始材料，wiki 放 AI 维护的知识中间层，AGENTS.md 告诉 AI 这个 wiki 怎么组织。
|
||
|
||
整体的一个壳子大概长下面这个样子。
|
||
|
||
然后第一道坎就来了。
|
||
|
||
如果你的实际数据不是规整的txt，或者markdown，ai用pdfplumber转成的markdown就会变成这个样子。文字换行、缩进、表格、图片，这些都没法保留，甚至可能混乱。
|
||
|
||
不管是简单的博客，还是复杂的文档，解析成这个样子其实对模型都特别不友好。
|
||
|
||
还好我用的opus 4.6，对这些东西会鲁棒一些，如果用国产平替估计影响就比较大了。
|
||
|
||
但是。正好，我们最近有一些业务涉及到复杂的word格式文档处理，订阅了合合信息 TextIn 的 API，所以我顺手做了个对比。
|
||
|
||
比如，这是TextIn转写的博客结果，图片和格式排版这些都有保留。
|
||
|
||
TextIn对表格的表示用的是用的html形式的，所以它可以表示更复杂的无线表、合并单元格这些。
|
||
|
||
可以看下图。在招股书的解析里边，图表的结果也非常的不错。
|
||
|
||
最后，还附上TextIn api的耗时参考。目前，这套解析，在我们现在内部的一个业务上跑的还不错。可以在这里测试TextIn的解析：https://cc.co/16YSdj
|
||
|
||
搞定预编译之后，开始走 ingest 流程。这里有一个很蠢的坑，模型喜欢偷懒，一次性看一点文档，然后ingest很多的文档。
|
||
|
||
结果每份材料都是浅读，生成的 wiki 页面跟目录没什么区别。信息密度极低。
|
||
|
||
所以这里我优化了一下默认的AGENTS.md，让它一份份处理，超过的还要分段来处理。
|
||
|
||
这个小优化会带来比较明显的数据处理质量的提升。
|
||
|
||
10 份材料全部 ingest 完之后，结构是这样的：
|
||
|
||
大概的一个流程是，解析->然后模型会按照AGENTS.md 梳理每份内容的要点，文档要点示例如下：
|
||
|
||
然后会整理出实体、概念。 以下是二者的示例。都会有明确的跟其他文件的link关系。
|
||
|
||
concept之间还会自动构建起对比，comparisons示例：
|
||
|
||
最后，从结果来看，因为我已经用了最顶级的Opus4.6模型了，所以不论是不是最好的解析方式。
|
||
|
||
带来的wiki结构密度其实差异不大。但是信息密度差异比较大。用TextIn API解析的数据可以保留更多的原始信息，让整个库的信息密度更高。
|
||
|
||
所有有考虑搭建这种自动更新wiki的同学，可以考虑，尽量用最好的解析策略。
|
||
|
||
接下来就可以看出来这种关联wiki的魅力了。
|
||
|
||
比如Harness，我放了4篇博客，包含Ralph Wiggum的反对多Agent的博客，以及OpenAI、Anthropic的相关博客。
|
||
|
||
这样，在Agent Harness概念页就出现了同时容纳了正反两方的观点，还用表格对比了两种流派的差异。
|
||
|
||
这种跨文档的交叉引用和矛盾标注，RAG 是做不到的。RAG 能从单份文档里检索片段，但它不会主动发现两个人其实在用不同方式解决同一个问题。但是通过这种模式，构建的wiki 它就全都懂了。
|
||
|
||
或者需要结合多个跨文档综合的问题。比如「智谱跟 Anthropic 的商业化策略有什么不同」。
|
||
|
||
Agent就可以依据信息的链接跳转，自动的去探索需要的信息，找到最终的答案了。
|
||
|
||
而传统的利用单文档的longcontext chatbot 或者 RAG，其实很难做这些事情。但是wiki已经把他们编译好了。
|
||
|
||
## 写在最后
|
||
|
||
坦率的讲，跑完整个流程之后我有一个很强的感受。
|
||
|
||
llm.wiki 这个模式从理论上肯定是跑得通的。你在里面能看到 GraphRAG 的影子，能看到 Skills 的影子，能看到 Context Engineering 的影子。这些东西换了不同的名字，但做的事情有很大的重叠。
|
||
|
||
而在 Harness Engineering 爆火的今天，llm.wiki 其实又是在强调，过去那些手动维护知识库的包袱，可以扔了。一整套编译工作，交给模型就行。
|
||
|
||
但一个东西没变。
|
||
|
||
garbage in, garbage out。今天依然成立。
|
||
|
||
解析，仍然是很多项目真正的卡点。如果你现在还在被这个问题困扰，可以试试 TextIn，地址在这里：https://cc.co/16YSdj
|
||
|
||
实验的完整目录结构、AGENTS.md、解析脚本均已开源。https://github.com/Nipi64310/llmwiki-test
|