去年帮一家工业设备厂商上线企业知识库的时候,我们本以为最难的部分是"把文档喂进去、让它答得准"。真正上线跑了半年,才发现难的从来不是这个。难的是——当一个"能问就答"的系统,真的放到一群人手里之后,会发生什么。

这篇不谈版本、不谈参数,只讲三件把我们绊了一跤、然后逼着我们重新设计的事。如果你也在给公司搭知识库,大概率会遇到同样的坑。

一、那条分享链接,差点让我们赔进去一单

事情是从销售小王的一次"顺手操作"开始的。

厂里给核心产品线配了个问答助手,把整理好的产品资料、报价逻辑、技术参数都灌了进去,内部用着很顺。有天客户 A 来问几个技术细节,小王嫌一条条转述太累,直接把助手的会话分享链接发了过去:"这个您自己点进去问,比我说得全。"

客户 A 用得很开心。问题出在,他转手把这条链接又发给了同行 B——一个正在跟他们竞标同一个项目的对手。

同行 B 点进去,问的可不是产品参数。他问:"这款设备的最低成交折扣是多少?""成本价大概什么水平?""你们的核心供应商是谁?"

而这个助手,老老实实地,把它知道的都答了。

等销售总监发现的时候,后台的问答记录已经躺在那儿了。没人越权、没人攻击,系统只是忠实地执行了"谁问都答"这个我们从没质疑过的默认设定。

复盘时最扎心的一句话是总监说的:"这套系统里,压根就没有'谁能看什么'这个概念。"

他说得对。我们花了大力气让它"答得准",却从没想过它应该对不同的人,答得不一样。一条链接甩出去,售前咨询和内部机密,走的是同一个门。

分清楚"谁在问",才是第一件事

所以我们做的第一件事,不是加更多内容,而是给每个会话装了一个登录开关。

逻辑很朴素:一个问答助手到底面向谁,建它的人最清楚。

• • 对外的售前助手——就该免登录,客户点开链接就能问,越顺越好,这是获客的入口,加一道登录门槛只会赶客户走;
• • 对内的知识助手——必须先登录,而且系统要清楚地知道现在坐在对面的到底是谁。

关键在后半句。登录不只是拦一道门,更是把访问者的真实身份带进整条问答链路。谁在问,就决定了他能检索到哪些资料、看到哪些答案。同行 B 那种"拿到链接就能掏空知识库"的路,从根上被堵死了。

实现上,我们给每个助手(无论是普通对话还是 Agent 工作流)加了一个 require_login 开关,分享校验时把身份透传下去:

def _resolve_share_auth(dialog, token, current_user):
    if not dialog.require_login:
        return {"visitor_id": None}          # 售前:匿名放行

    if not current_user:                      # 内部:未登录直接拦
        raise Unauthorized("this assistant requires login")

    # 把真实身份带进检索链路,下游据此做权限过滤
    return {"visitor_id": current_user.id}

一个布尔开关,看着简单,却是"知识库有没有边界"的分水岭。先分清谁在问,再谈答什么——这是那次事故给我们上的第一课。

二、同一个东西,一线的人有八种叫法

第二个坑,藏得更深,因为它不报错,只是让人"搜不到"。

上线两个月,售后同事跑来吐槽:"我搜'回款',啥都搜不出来,可财务明明写了一堆流程啊?"

我们扒了一下才发现:财务文档里写的是"收款确认",销售嘴里说的是"到账",售后填工单写的是"回款"。三个词,指的是同一件事,但在机器眼里,它们是三个毫不相干的字符串。人脑里天然连通的概念,在知识库里是三座孤岛。

这类问题在企业里遍地都是:

• • 产品有型号、有代号、有客户昵称;
• • 同一道工序,老师傅和图纸上的叫法不一样;
• • 一个部门缩写,新人根本对不上全称。

你没法要求所有人说话都统一。能统一的,只有机器对这些词的理解。

给知识库配一本"行话词典"

于是有了第二件事:让知识库支持在检索层面维护一套同义词规则,把散落的说法归并成同一个概念。

我们把它做成两种简单的规则,一行一条,业务同事自己就能维护:

# 等价组:组内词互相等价,搜任意一个,其余全命中
到账, 回款, 收款确认
甲供料, 甲方供料, 业主供料

# 映射:把左边的各种叫法,统一指向右边的标准词
到账 => 收款确认
回款 => 收款确认

配好之后,检索时系统会自动把这些"行话"展开:

def expand_query_with_rules(query, rules):
    expanded = [query]
    for term, synonyms in rules.match(query):
        # 同义词以较低权重加入,补召回但不喧宾夺主
        expanded += [(s, 0.2) for s in synonyms]
    return expanded

有个细节我们琢磨了挺久:同义词是用较低的权重(约原词的 0.2 倍)加进去的,而不是同等对待。原因是——你搜"到账",最该命中的还是真写了"到账"的那篇;"收款确认"只是补上一层召回,别喧宾夺主。它管的是"别漏",不是"抢答"。

这件事的价值,不在技术多复杂,而在于它承认了一个朴素的事实:知识库要迁就人说话的习惯,而不是逼着人去迁就机器。

三、知识库也需要一份"体检报告"

前两件事解决的是"答得对不对、该不该答"。第三件事,解决的是一个更让人头疼的问题:这个知识库,现在到底是个什么状态,没有人说得清。

上线小半年,库里堆了几千个文档。可但凡有人问一句,负责的同事就答不上来:

• • 这半年到底谁在用、都在问些什么?
• • 这几千份资料,有多少是一年前的老古董,早就该更新了?
• • 有没有哪些文档,传上来就一直解析失败,躺在那儿是个摆设?
• • 用户反复在问、但库里压根没有答案的,又是哪些?

这些问题,原来只能靠人一个个文档翻、翻到崩溃。知识库成了个只进不出、无人体检的黑箱——你不知道它哪儿健康、哪儿生病。

把黑箱变成一块仪表盘

第三件事,就是给知识库做一个概览页,像体检报告一样,一屏看清家底。我们把它拆成四块:

① 使用情况——这半年谁在用、问得多不多、热门问题是哪些。让你知道这库到底是被天天翻,还是建完就吃灰。

② 资产盘点——总共多少文档、覆盖哪些主题、新鲜度如何。一眼看出有多少内容"过期"了,该安排谁去更新。

③ 需要处理——那些解析失败、格式异常、状态卡住的文档,集中列出来,不用再逐个排查。哪儿堵了,一目了然。

④ 知识缺口——用户反复在问、库里却答不上来的问题,自动汇总。而且能一键带到问答页去补齐——从"发现缺口"到"动手补"只差一步。

配合这些,整个界面我们也彻底重做了。老界面是"给管理员看的表格",信息密密麻麻却抓不住重点;新界面用卡片和图表,把最该被关注的东西——异常、过期、缺口——直接推到你眼前。知识库不该是个只管往里塞的仓库,它得能回头告诉你:我现在过得好不好。

写在最后

回头看,这三件事——分享会话的登录边界、检索层的同义词治理、知识库的概览体检——没有一个是"更强的模型"或"更炫的功能"带来的。它们全都来自同一件事:

当知识库从"能用"走向"给一群真实的人天天用",你关心的问题会彻底变一遍。

从"它答得准不准",变成"提问的的人、答对的话";
从"塞了多少内容",变成"这些内容还活着吗、有没有人真的用得上"。

这也是 KnowFlow 未来的知识运营很重要的一环，从问答准不准到知识库落地后，知识如何治理和运营。

这三课,是我们在 KnowFlow 上踩着坑一点点补出来的。如果你也在给公司搭知识库,希望你能少摔这几跤——或者,至少摔得明白一点。