# 01、现场：任务成功，词条却重了

复盘里最刺眼的不是报错，而是“成功”。

抽取完成，身份查询返回候选，模型给出判定，写入返回成功。可知识库里多了一个本该复用的词条。

旧路径把候选交给LLM产出merges，返回空映射时，程序仍继续新增。任务状态是绿的，数据身份却裂成了两份。

这类问题很难靠看日志发现，因为每一步都“按约定”完成了。

![部署边界图](https://developer.qcloudimg.com/http-save/yehe-9261324/b6e40b9d95b0dbde8a28c602c07a3f26.png)

---

# 02、拆题：不是模型笨，是责任错位

直觉会说模型判错了。但空merges不是错误答案，是缺省值。

把“是否同一实体”的最终裁决权交给一个可能返回空的字段，本身就是设计缺陷。确定性不变量不该依赖LLM返回。

标题相同不一定身份相同，这是另一半事实。合法同名不同实体若被粗暴合并，损失比重复更重，且不可逆。

所以问题不是“让模型更准”，而是把召回、裁决、写入拆成三层责任。

---

# 03、原理：三层各自守什么

第一层是精确身份召回。在同企业、同知识库、同类型、活跃状态范围内，用规范化标题或Slug查DB。唯一命中就由程序直接复用，不经过模型。这是确定性规则，可测试、可追溯。

第二层是消歧。多个同名实体或语义歧义时，才把候选交给LLM辅助判断。模型输出是建议，不是不变量；空结果必须走保守分支，而不是默认新增。

第三层是写入约束。同批次按规范化标题与类型先归并，再落库。事务与并发兜底要单独验证，唯一索引能否覆盖并发插入，取决于约束设计与冲突处理。

ES在这里只是辅助召回。别名候选配额可能把精确命中挤出结果集，所以精确查询不能排在ES之后。

![跨角色泳道图](https://developer.qcloudimg.com/http-save/yehe-9261324/2d7d71c1947f74167b5562835cf2d817.png)

---

# 04、取舍：为什么不让巡检Agent兜底

有人会提议加一个巡检Agent，定期扫重复再合并。听起来省事，代价是把确定性收敛推给了事后。

巡检能发现已发生的重复，却挡不住写入瞬间的分叉；合并还要面对引用、权限与历史版本迁移。更关键的是，它没有改变“空merges即新增”的根因。

规则优先的代价是范围要写死：企业、知识库、类型、活跃状态缺一不可，跨范围同名必须放行。LLM消歧的代价是不确定性，所以只放在歧义分支，并保留人工可回溯的判定记录。

选择依据很简单：能用程序判的，不交给模型；必须模型判的，不让它决定写不写。

---

# 05、架构：把判定收进服务边界

落地时，身份服务对外只暴露一个语义清晰的入口：给定范围与规范化标题，返回复用、歧义或新增。

复用分支直接返回既有ID；歧义分支带候选列表进入模型；新增分支才构造写入。

批内归并放在写入前，按规范化标题与类型做一次内存归并，避免同批两条互相看不见。

写入侧用事务包住“查—判—写”，并对唯一约束冲突做显式处理，而不是吞掉异常继续插。

![MCP工具调用时序图](https://developer.qcloudimg.com/http-save/yehe-9261324/d10219190a5dffb22d44c671122b8f98.png)

---

# 06、实战：最小校验与测试断言

工具入口先做输入校验，把范围参数变成必填，缺省即拒绝，避免跨库误判。

```java
// 用途：MCP工具入参校验，范围缺失直接拒绝
public IdentityCommand validate(IdentityCommand cmd) {
    if (cmd.tenantId() == null || cmd.kbId() == null
            || cmd.type() == null || cmd.title() == null) {
        throw new IllegalArgumentException("scope required");
    }
    return cmd.normalizeTitle();
}
```

测试断言要盯住行为，而不是模型措辞：唯一精确命中必须返回既有ID，且不调用模型。

```java
// 用途：唯一精确命中时复用，不触发LLM
@Test
void exactHitReusesWithoutLlm() {
    when(repo.findExact(any())).thenReturn(List.of(existing));
    Decision d = service.decide(cmd);
    assertEquals(Decision.REUSE, d.kind());
    verifyNoInteractions(llmClient);
}
```

六类验收测试要覆盖：ES漏召时DB仍能命中；别名配额挤占时精确查询不受影响；空merges走保守分支；批内同名先归并；合法同名不同实体不被合并；并发请求下唯一约束与冲突处理符合预期。

---

# 07、复盘：代码快照不等于生产结论

复盘对照的是2026年10月28日与29日的代码快照，并做了独立机制复现实验。

这能证明旧路径在空merges下会新增，也能证明分层后精确命中可复用。但它不证明生产重复率已下降，也不证明并发写入已被唯一约束完全覆盖。

模拟测试覆盖的是已知分支，生产还有索引延迟、重试与跨服务时序。把这些边界写清楚，比给一个漂亮数字更负责。

---

# 08、洞见：确定性规则别交给模型

Agent做业务写入，最容易犯的错是把“判断”和“执行”混在一个模型调用里。

模型擅长语义消歧，不擅长保证不变量。身份、幂等、唯一性这类规则，应该由代码在明确范围内判定，模型只在歧义处提供建议。

这不是不信任模型，而是让每层只承担它能被验证的责任。当任务成功而数据出错时，先查责任边界，再查模型输出。

---

# 09、小结

重复词条的根因不是一次误判，而是精确召回、模型消歧与写入约束没有分层。

唯一精确匹配由程序复用，合法同名交模型辅助，批内归并和事务并发兜底单独验证。空merges必须走保守分支，ES别名不能挤走精确命中。

确定性不变量，别交给LLM返回。

延伸阅读：可查阅腾讯云开发者社区关于53AI Wiki重复词条的复盘文章，重点看问题链路与修复分层两节。

延伸阅读：Elasticsearch官方参考的Terms query章节，理解精确词项匹配与配额限制的适用边界。

延伸阅读：PostgreSQL官方文档事务隔离章节，核对读已提交与可串行化在并发写入下的行为差异。

延伸阅读：Spring Framework官方参考的事务管理章节，确认声明式事务与冲突处理的适用范围。

抽取完成，身份查询返回候选，模型给出判定，写入返回成功。可知识库里多了一个本该复用的词条。

74:Wiki重复？AI别当法官！

从53AI Wiki重复词条复盘出发，说明文档抽取到写入链路中，精确身份召回、模型消歧与写入约束必须分层：同企业/知识库/类型/活跃范围内规范化标题唯一命中由程

架构师

人工智能

后端

架构设计

重复词条根因是精确召回、模型消歧与写入约束未分层。唯一精确匹配由程序复用，合法同名交模型辅助，批内归并与事务并发兜底单独验证。空merges必须走保守分支，ES别名不能挤占精确命中。确定性不变量不依赖LLM返回，每层只承担可验证责任。

Elasticsearch 

验收测试

代码解释

PostgreSQL

Agent

腾讯云双十一大促

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

74:Wiki重复？AI别当法官！-腾讯云开发者社区-腾讯云

74:Wiki重复？AI别当法官！

74:Wiki重复？AI别当法官！

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐