一、一次不该发生的“重复创建”

企业知识库最让人头疼的故障，未必是接口报错。更难发现的情况是：任务看起来正常完成，编译的知识内容却悄悄偏了。

在 53AI 的 Wiki 知识生成管线中，发现过同一个企业、同一个知识库、同一词条类型下，存在两个标题完全相同的活跃词条。一个此前已经生成，另一个由后续处理任务再次创建。

这件事最初很容易让人怀疑 Elasticsearch（以下简称 ES）：是不是旧词条没有同步进索引，导致新一轮生成时没检索到？这确实是一种可能存在的风险，但不是足以下结论。即使 ES 漏了候选，数据库仍然可以作为最终身份核验来源；反过来，即使找到了候选，也不意味着后续系统一定会复用它。

这次的修复过程让我们发现三个工程薄弱点：1、

精确匹配可能被候选数量上限挤掉；2、已有候选仍依赖模型给出合并指令；3、同一生成批次内缺少足够可靠的确定性归并。

二、错不完全在模型，而在于把决定权在谁

一个典型的 LLMWiki生成管线，大致经历四步：从文档中抽取候选词条，查询历史身份，判断是复用还是新增，最后执行写入。

前两步往往混用数据库精确查询、ES 词法检索与语义召回；第三步则适合大模型参与——例如两家公司简称相近、一个概念有多个别名，是否其实指向同一实体，确实需要上下文推理。

问题出在把模型的输出当成了最终业务裁决。

在原先的实现路径中，去重服务会向模型请求一个 

 映射：哪些新候选应该合并到哪些现有词条。当模型返回空的 

 时，流程可能继续保留新候选，最终创建出一条新页面。

这段响应并不能证明大模型“犯了错”。例如对于合法的同名不同实体，不合并是完全正确。但是，

在业务规则已经定义了“唯一精确身份匹配应直接复用”的前提下，系统就不应该再把是否合并交给模型的自由输出。

因此，工程上的问题不是“如何用更强的 Prompt 逼模型返回正确 JSON”，而是：

这次修改不是取消 LLM，而是把它放回真正需要推理的环节。

1. 精确身份召回：确定性查询必须优先

原链路中，词条标题、Slug、别名和检索命中会竞争一个有限的候选集合。当别名候选过多时，精确同名页存在被挤掉的风险。

修复后，精确标题与 Slug 被独立、优先查询；再补充词法、ES 和语义召回。代码中的标题规范化主要是去除首尾空格和转小写，并非语义相似度判断。ES 返回的 Page ID 还会回到数据库，核验企业、知识库、词条类型与状态。

它解决的不是“让检索更聪明”，而是

不能让弱相关候选排挤已经明确的身份线索

2. 唯一精确匹配：由业务规则决定，而不是等待模型点头

在这套 Wiki 的既定身份规则下，如果同一企业、同一知识库、同一词条类型内，只有一个活跃词条的规范化标题与新候选完全一致，则直接复用已有页面，不再调用 LLM 决定是否合并。

但这里有一个容易被忽略的前提：

“唯一同名可以复用”是当前业务域定义的规则，不是所有知识图谱都适用的普遍真理。

 人名、城市名、同名产品型号等场景，标题相同也可能是不同实体。如果身份规则不支持唯一性假设，就应增加稳定业务 ID、来源证据或人工消歧，而不能机械套用标题去重。

3. 多个同名或语义相似：继续让 LLM 消歧

当候选存在真正歧义时，例如多个可能的历史实体，模型仍然有价值：阅读摘要、别名和上下文，提供合并建议。模型建议应受到输入证据、候选范围与输出校验的约束。

不要用确定性规则替代一切语义判断，也不要用语义判断替代明确的业务规则。

4. 同批次重复候选：写入前先做确定性归并

如果一份文档在同一批处理里抽取出两个同类型、规范化标题一致的候选，即便还没查询历史库，也应先按当前身份规则归并，避免相同输入在同批次制造重复页面。对应修复加入了这一层处理。

# 业务域必须先定义 identity_scope 与 exact_identity_key
candidates = merge_same_batch(candidates, identity_scope)
for item in candidates:
    exact = db.find_exact_identity(item, scope=identity_scope)
    if len(exact) == 1 and policy.allows_unique_exact_reuse(item):
        decision = Reuse(exact[0].id)
    elif len(exact) > 1 or has_semantic_ambiguity(item):
        decision = validate(llm_disambiguate(item, bounded_candidates(item)))
    else:
        decision = CreateCandidate(item)
    persist_under_authorized_policy(decision)

 是工程目标而非已经被此次提交证明具备完整并发保护的现有实现。若要求

，还需要在适用的身份键上设计数据库唯一约束、幂等键、事务内重新校验或锁；仅在应用层做一次“查询后创建”，仍可能存在竞态。对于允许合法同名的知识域，也不能粗暴建立“标题唯一”的数据库索引。

四、同一条管线，修复前后究竟改变了什么

为了避免把方法论讲成口号，我们进一步核对了两个真实代码快照：2026 年 10 月 28 日的实现版本（

）和 10 月 29 日的确定性去重修复（

）；master 侧还存在对应热修复（

一：唯一精确匹配，不再等待模型返回 

修复前，找到候选后仍主要依赖 

if len(existingPages) == 0 {
    continue
}
resolved, err := s.dedup.PlanDedup(ctx, WikiDedupInput{
    NewItems:      []WikiDedupItem{item},
    ExistingPages: existingPages,
})

修复后新增了一个在模型调用前执行的分支：

if len(exactTitleMatches) == 1 {
    merges[item.Slug] = exactTitleMatches[0].Slug
    continue
}

两段代码对比的意义不在于减少一次模型调用的成本，而在于

。模型仍然负责多个历史同名实体之间的歧义消解。

二：精确召回不再与别名和模糊候选争夺相同额度

在此前的查询路径中，候选以限定条数的检索集合返回，存在精确同名词条被其他候选挤出的风险。修复后增加独立精确标题查询，核心数据库谓词为：

Where("eid = ? AND library_id = ? AND status = ? AND page_type = ?",
    eid, libraryID, model.WikiPageStatusActive, item.Type).
Where("LOWER(TRIM(title)) = ?", title).
Order("id ASC").Limit(candidateLimit)

随后再叠加 ES、别名与语义召回。这样实现的是“明确身份线索优先”，并非完全取消候选上限，也不能据此断言所有同名实体都是同一身份。

三：批内先归并，并保留已确定决策

修复提交还增加了按类型和规范化标题执行的同批次归并。`normalizeWikiDedupTitle` 在代码中使用 

strings.ToLower(strings.TrimSpace(title))

。如果其他候选的 LLM 消歧出错，已确定的精确同名归并仍应保留。这一行为在 master 热修复中有专门的测试源码。

一组真正可复现、但证据层级不同的测试

为形成可公开复核的技术材料，我们准备了一个

仅依赖 Go 标准库的独立最小机制复现

，它按上述代码逻辑模拟旧路径与新护栏，不连接数据库、ES 或真实 LLM；在本轮环境中执行 

，5 项测试全部通过，记录如下：

五、真正的可靠性，不是“模型每次都判断正确”

从这次修复得到的收获，可以归纳为三道相互配合的防线。

 将精确匹配与模糊匹配分层，限制候选规模但不牺牲明确身份；ES 是召回辅助，不是身份真实性的唯一来源。

 对规则已确定的情况使用代码，对歧义情况使用 LLM；对模型返回的空映射、错误目标和异常响应，采用显式且可审计的处理策略。当前修复中，已确定的归并不应因其他候选的 LLM 失败而被取消。

 写入前统一归并，保留测试覆盖；对于严格唯一性要求，进一步考虑存储层和并发约束。模型升级、Prompt 调整、召回权重改变之后，也应该重新跑这些不变量测试。

工程上更应该观察的是“不变量是否被破坏”，而不是“模型输出看起来是否合理”。例如，测试至少要覆盖：

 包含对应逻辑与针对性测试源码；另有 

 涉及 ES 身份词法召回、提交后同步及按企业回填能力。这些材料足以支撑“我们采取了哪些工程措施”。它们本身不能替代生产事故时间线、上线记录与运行指标。因此，本文不提供未经核实的重复率下降百分比、故障耗时缩短或模型准确率提升等数字。

六、修好了 Bug，为什么不做一个巡检 Skill？

这里我们在实践中也做过一次方向调整。

起初觉得：既然 Wiki 产生过重复词条，不如开发一个 Skill，定期去找重复项、检查索引，并给出报告。但进一步推敲会发现，

如果根因是代码缺陷，正确的第一动作应该是修代码、补回归测试，而不是再用 AI 反复发现同一个 Bug。

DB 与 ES 的同步状态确实需要持续监控，因为网络失败、进程异常和异步延迟可能在修复后继续发生。但这类差集比对、状态核验，首先应由确定性监控与规则引擎承担。没有必要为了“看起来智能”而增加一层模型判断。

那 AIOps Skill 在哪里有价值？是在监控已经发现异常之后，需要综合不同信息源排查“为什么”的环节：读取有权限的事件日志、梳理最近的版本变更、检查索引同步与候选召回链路、整理可能的原因和证据缺口，并为值班人员提出下一步验证建议。即使在这个阶段，自动执行数据修复也应受到权限和人工审批约束。

我们最后把这次实践的重点放回确定性护栏，而不是把每个问题包装成 Skill。这并不否定 AIOps；恰恰是明确了

监控、工程约束、模型推理和人工授权各自应该负责什么

七、对企业 Agent 和知识大脑意味着什么

企业 AI 进入生产系统以后，真正重要的变化不是模型会写更长的答案，而是模型开始参与影响业务状态的决策：创建一个客户档案、合并两条知识、更新一项跟进状态、触发一个操作。

两类能力不是竞争关系，而是互补关系。一个好的 Agent 不是“尽可能把更多决定交给大模型”，而是

把确定性的部分从模型手里拿回来，让模型专注于真正不确定的部分。

这也是我们对企业 AI 落地的一点更深的认识：系统可靠性不能建立在“这次 Prompt 恰好让模型答对了”之上。能够被工程化表达的边界，就应该成为工程边界；需要推理的地方，再让模型发挥价值。

八、AI时代的工程能力，是知道什么不该交给 AI

这次 LLMWiki 重复词条事件表面是一次 Bug 修复，但它留下了一个更普遍的提醒：

模型可以给出建议，系统必须对最终结果负责。

我们不需要刻意展示 Agent 能力而把每次遇到的问题都做成一个能解决问题的 Skill，也不需要要求 LLM 永远不出错。真正值得建设的是一套可检验、可回归、遇到歧义能升级处理的工程机制：确定的规则由程序保证，不确定的情况由模型辅助判断，重要的写入动作由明确的授权边界约束。

一次 Wiki 重复词条故障之后，对“模型判断”与“程序约束”边界的重新划分

本文以 53AI 知识系统一次 Wiki 词条重复生成故障为例，探讨大模型语义判断与确定性业务规则的职责边界。通过分析故障原因、对比修复前后的真实代码，并结合可复现实验，展示如何利用精确身份召回、确定性归并和模型辅助消歧，避免关键业务规则过度依赖 LLM 的不确定性输出。文章总结了企业 AI 系统可靠性建设的工程实践：让 AI 处理复杂语义，让程序守住业务不变量，实现智能性与可靠性的平衡。

人工智能

后端

架构设计

在大模型驱动的知识生成管线中，重复词条问题源于精确身份匹配与模型消歧间缺乏确定性约束。核心解法是：优先执行精确标题与Slug查询，唯一匹配直接复用现有页面；仅在存在真正歧义时调用LLM；同批次候选写入前先归并。通过将确定性规则与模型推理分层，让程序守住业务不变量，AI专注处理语义不确定性。

Elasticsearch 

知识图谱

回归测试

数据库

AIOps

Agent

JSON

腾讯云双十一大促

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

一次 Wiki 重复词条故障之后，对“模型判断”与“程序约束”边界的重新划分

一次 Wiki 重复词条故障之后，对“模型判断”与“程序约束”边界的重新划分

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐