前言

目的

这次的目标很明确：搭一个房产销售助手，让用户能直接问小区的基本信息、户型资料。目前先聚焦在一个楼盘上，算是把路趟通。

目标

做这件事，想达成这么几件事：
- 搞明白知识库的处理思路和方法；
- 摸清Coze知识库的用法，文本、表格、图片三类都要会用；
- 能查到楼盘详情和物业信息，比如车位、物业费这些；
- 能查到户型信息，还能看到户型图。

思路

方案很直接：用Coze的Agent，通过设定好人设和回复逻辑的prompt，直接去查知识库里的内容就行。

内容概述

这一篇主要聚焦在文本知识库上，核心任务就是把文本分割策略和召回策略怎么调、效果怎么样，彻底跑一遍。

内容文本

先看下要处理的知识库内容长什么样：

全是文本信息，都是关于楼盘的各类数据。

特点

这类内容有个明显特点：知识点之间关联度很低，而且单个知识点体量不大。这就给知识库的构建带来了一些特殊的挑战。

策略

文本分割策略

分割策略是第一步，也是决定后续召回效果的基础。这里尝试了两种不同的路线。

其一，按知识点来分割

思路很简单：一个知识点切一块。优点很明显——token消耗少，作为上下文的干扰信息也少。但缺点同样突出：当用户一口气问好几个问题时，就需要设置更大的召回数量；而且每条内容的匹配度分值会比较低，必须降低最小匹配度阈值，否则可能根本查不到对应的知识点。

其二，按token数量分割，同时保证信息完整

比如用500个token作为一个chunk，同时确保每个知识点是完整的。因为这里数据量不大，手动分割就能搞定，控制起来很方便（以后用代码实现分割时，再单独聊自动分割的策略）。这种方式的优势是，多个知识点挤在一个chunk里，不用把召回数量拉太大。但代价也很实在：干扰信息变多了，token消耗也跟着涨上去了。

召回策略

测试

理论说再多，不如上手跑一遍。接下来就用实际测试来验证两种策略的效果。

以知识点来分割的策略

分割后的chunk效果如下：

问题1：提问一个知识点

召回设置

知识库召回的知识点

回答
token消耗

分析：单知识点查询，能正常召回准确信息，没有问题。

问题2：提问两个知识点

召回设置

知识库召回的知识点，因为是两个问题，知识点的匹配得分只有0.60。

回答
token消耗

分析：召回的知识点里缺少开发商信息，所以回答不完整。问题的根源在于“开发商”信息那条的匹配得分低于最小匹配度阈值。尝试把匹配度降到0.3再看看。

再次尝试：知识库召回的知识点
回答
消耗token

分析：问题确实出在匹配度阈值上。把最小匹配度降低后，所有需要的信息都能召回了。

总结

采用“按知识点分割”的策略时，如果用户提问横跨多个知识点，就需要降低最小匹配度阈值，同时适当扩大最大召回数量。具体设多少，得靠测试来找到那个最合适的数字。

文本分割策略二

分割后的chunk效果：

问题1：提问一个知识点

知识库召回的知识点
回答
消耗的token

分析：能查到所需的chunk，但和按知识点分割相比，token消耗明显更多了。

问题2：两个知识点在同一个chunk里面

知识库召回的知识点
回答
消耗的token

分析：能准确获取所需chunk，而且多个问题都在这个chunk里，匹配分更高，答案更准。这种情况下token消耗反而更少。

问题3：两个问题不在一个chunk里

知识库召回的知识点
回答
消耗的token

分析：没能准确召回想要的chunk。原因和策略一的情况一样，匹配分值低于预设值。同样尝试把最小匹配度降到0.3。

再次尝试：知识库召回的知识点
回答
消耗token

分析：能召回所需chunk了，但问题是按token分割时，一个chunk中可能混杂了多个知识点，导致token消耗更大，还可能带来混淆信息。

总结

做知识库应用，核心就是两件事：chunk怎么切，召回怎么调。既要保证能查到需要的信息，又要兼顾效率和成本。

从测试结果来看，给出一个明确的倾向性判断：如果文本中每条知识点内容少、相互之间没关联，用“按知识点分割chunk”的策略，同时把召回数量设大一点、匹配度门槛设低一点，然后让大模型去处理这些查到的信息。这样做既能保证信息完整和准确，又能有效控制token消耗和运行效率——这才是平衡点。