北京
一个入职三周的市场运营，被老板问了一句：七月底试用用户的MQL为什么掉了？她翻了四十个聊天串、一段58分钟的会议录音、改过两次的手册页、共享盘里还写着25分的老PDF、CRM里的线索评分字段、一个仪表盘、一个合并请求。七个工具翻完，她还是不确定是谁、在什么时候、为什么做了那个决定。
这是HandbookBrain想解决的问题，作者为Graph Hacks黑客松的“公司大脑”赛道做了它。核心判断很直接：搜索找得到文档，但Maya要的是一条路径——会议、决定、谁拍的板、落地这个决定的改动、被改掉的章节版本，以及所有依赖它的东西。这是一张图的问题，所以他就按图来做。
三个设计支点
第一，版本化的是章节，不是文档。一个页面被拆成若干章节，每次改动生成新的章节节点，取代上一版，带生效与失效时间。旧内容不被覆盖，所以能读任意日期的那张图，被删掉的规则也还找得到。
第二，答案本身是节点。一个答案会引用它用到的确切章节版本，就靠这条边，后来的改动才能找到自己被谁引用、又弄坏了哪些答案。
第三，决定是一等公民。每个决定从会议、聊天或工单里抽出来，带发言人和原话引用，连到它涉及的章节，再通过读代码差异，对上真正实现它的那次提交。
检索是混合式的，全部放在FalkorDB里：章节向量的向量索引，加上标题和正文的全文索引，用倒数排名融合，再过滤到当前版本。向量、全文和图遍历在一个库里，就不用再维护第二个存储去同步。智能体本身是一个工具调用循环，跑在10个参数化的只读查询工具上，每条结论都必须带一个工具真正返回过的引用，这一点在代码里校验。
那条阈值的故事
演示用的是GitLab公开的上市手册，按日期回放2026年4月到10月的74个真实合并请求。围绕这些请求的会议和聊天是合成的，由大模型生成、锚定真实改动，每个合成文件都做了标注。
5月21日，真实请求!19600给页面加上试用阈值评分，系统把它连到13天前的一场会议。6月1日，新来的分析师问：试用用户多少分算MQL？答案是25分，引用的是那个章节版本。7月17日，周会决定上调。7月23日，真实请求!20534把25改成31。6月1日那个答案被判定过期，CODEOWNERS里的负责人收到通知，答案刷新为31，会议、决策人和合并请求一并附上。Maya问一个问题，拿到整条路径。
那个89%对0%
作者最初的头条数字是“89%对0%”，在“为什么”类问题上对比普通检索基线。看着很漂亮，但不公平。逐条事实核对后发现，普通检索在找会议日期和决策人上并不差，它拿0%只是因为那个合并请求根本不在它的数据里。
于是他重做了评测：能写代码判分的就用代码，只有开放答案才用模型裁判；既有该答的问题，也有该拒答的问题；每题跑3次，关掉大模型缓存。还加了一个更强的基线，把整份合并日志当文本喂进去。29题乘3次的结果说明：找会议是检索问题，检索能解决；图真正加上的，是决定到落地改动、再到版本历史的那条链，包括已经被删掉的规则。即便把整份合并日志放进上下文，模型也很少能自己把会议对上正确的合并请求。而在普通查询上，图什么也没加，智能体还更慢更贵。
作者也把保留意见写了出来：题目是他自己出的，只来自一个数据集，而且他是看完这些题上的失败之后才去修的智能体，换新题数字应该会更低。
评测确实挖出了真bug。一个叫“试用阈值评分”的章节被埋在泛泛的“MQL与线索评分”下面，智能体答了100而不是31，修法是搜索里加标题匹配候选。宽表格被按列读错，修法是把行线性化。被删掉的规则看不见，修法是搜索也返回说过更多的旧版本，连同删掉它的那个请求。只在聊天里达成的规则曾被当成制度、还配了手册引用，修法是标注“只在聊天里说过”，智能体必须照实讲。
四条经验：让答案成为节点；在章节级别做版本；按事实逐条衡量，对着公平的基线；用独立来源审计大模型建出来的边——抽链接的模型不该同时当裁判。
代码在github.com/danhe6/handbookbrain，用FalkorDB、Python、FastAPI和LiteLLM搭起来，大部分代码是在作者指挥和审阅下由AI编程助手Claude写成的。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
