Knowledge Atlas by Fini

Hey Product Hunt 👋 我是 Deep，Fini 的联合创始人。

过去几个月，我们花了 300 多个小时观察客户如何维护他们的知识库。有一点始终不变：每个人都讨厌这件事。客服团队每周要花 20 小时手动更新帮助中心。功能上线了、政策变了，CX 团队的人就不得不在周五重写文章。每一次更新都是“紧急”的。

更深层的问题是：AI 客服智能体给出错误回答时，几乎从来不是模型的问题，而是知识的问题。过时的文章、矛盾的文章、缺失的文章。你无法靠 prompt engineering 来弥补糟糕的源数据。

所以我们构建了 Knowledge Atlas——一个能自我更新的知识库：
- 接入你的源（帮助中心、PDF、历史工单、Slack），Atlas 会构建一棵带有引用文章的结构化树
- 每个已解决的工单自动变成一篇新文章
- 文章之间的矛盾会在客户看到之前被捕获并标记
- 每个回答都精确指向唯一来源

而且底层没有用 RAG。搜索是 LLM 原生的：智能体像人一样导航这棵树并阅读整篇文章，而不是检索片段再拼接成混合答案。我们那些银行和医疗领域的合规型客户更在乎这种单源可追溯性，而不是任何准确率指标。

Wefunder 已经上线了：自主解决率提升 22%，知识覆盖率提升 30%，团队没变。知识现在是在积累，而不是在衰减。

我们会在 24 小时内用你的真实文档免费构建一个 Atlas，这样你可以用自己的知识来评估它，而不是看一个精修过的演示。

今天我会全天在线。欢迎问我任何问题，尤其是那些尖锐的问题——比如我们为什么放弃 RAG。

听起来非常有趣，我之前没见过按解决次数定价的模式。我更关心的是部署/上手阶段。如果需要接入你的 API，那基本上就是一次完整的产品集成，而不是一个附加扩展。对于一家 SaaS 公司，从注册到完全自主运行，典型的 onboarding 时间是多长？我猜需要你们的 CTO 花很多时间才能搞定。

从已解决的工单自动生成帮助文章，这个维护循环是大家都会跳过的部分，所以我会先测试输入质量这个关卡。当一个工单是通过变通方案或一个错误但被客户接受的答案解决的，是什么机制阻止它成为 AI 会自信引用的标准文章？另外，冲突检测：它只是发现两篇文章矛盾，还是也能检测出某篇文章因为产品变更而变得过时，但还没有人为此提交工单的情况？

把冲突检测作为机制比单纯的 TTL 更可靠，这说得通。之前让我们吃亏的案例不是两篇明显重叠的文章，而是两篇关键词完全不相关但内容矛盾的文章：一篇旧政策文档里的退款窗口，和一篇新 FAQ 里的退款窗口。没有任何文本将它们关联起来，所以简单的同主题检查直接放过了它们。你们是靠语义聚类，还是靠引用重叠，来判断两篇文章是否在讲同一件事？

推广关卡看起来挺扎实，Gal 的那条 thread 也促使你们展示了 diff 和 reject 的 UI，这很有帮助。我担心的另一种失败模式是“退役”。自动生成文章会让知识库迅速膨胀，但三月份正确的答案，等政策一变就变成了一条被自信引用的错误回答。在我们自己的自更新知识库里，添加内容很容易，但检测新文章与旧文章矛盾并让新文章覆盖旧文章——那才是真正的工程难点。Atlas 会检查新文章与现有文章是否有冲突吗？还是说这个循环主要是做加法？

把它接入我们的帮助台后，光是缺口检测一项就每周省了我们几小时的再培训时间。老实说，它在银行业边缘案例上一直保持的准确度令人印象深刻，而且我们不用时刻盯着。