MemPalace实体检测与消歧实战：entity_detector如何精准识别同名不同人

MemPalace实体检测与消歧实战entity_detector如何精准识别同名不同人【免费下载链接】mempalaceThe best-benchmarked open-source AI memory system. And its free.项目地址: https://gitcode.com/GitHub_Trending/me/mempalaceMemPalace 是一个开源 AI 记忆系统它的核心组件之一 entity_detector 负责实体检测从你的笔记和聊天记录里自动认出谁是人名、什么是项目名。而更棘手的问题是实体消歧——当Max既是人名又是普通单词、当 AI 助手和你的女儿同名时它如何不认错人这篇文章带你完整看懂这套机制。为什么实体检测对AI记忆系统如此重要记忆系统要回答我上周和谁去了哪里这类问题前提是先搞清楚文本里的命名实体谁是人person、什么是项目project、什么是话题topic。识别错了后果很直接把项目名Click当成人名 → 检索时按人过滤结果全错把普通单词max当成人名 → 满库都是虚假记忆把 AI 助手当成真人 → 工作记忆和生活记忆混淆entity_detector 的设计目标就是高召回地找出候选高精确地分类拿不准的交给用户确认。实体检测三步流水线提取 → 打分 → 分类整个检测过程是一条两步式流水线见 entity_detector.py 文件头注释核心函数是detect_entities()。第一步候选提取出现 3 次才入围extract_candidates()源码 L303-L363扫描文本只保留出现 3 次以上的大写候选词——偶然出现一次的词几乎没有实体价值。提取过程中有三道防线停用词过滤The、I 这类词直接排除各语言的模式都放在 i18n/en.json 的entity段里新增语言零代码改动COCA 实词过滤Tier 2像 Code、Phase、Note 这种句首/标题里常大写、却不是专有名词的常见词用语言学词表 coca_content_words.json 拦截避免Code被误认成人名已知系统复合词词典Tier 3known_systems.json 维护 Claude Code、GPT-4 这类多词产品名整体识别并遮蔽后再做单词匹配防止被拆成两个错误实体。长词优先Visual Studio Code 不会输给 Visual第二步信号打分person vs projectscore_entity()源码 L417-L497给每个候选打分左右互搏加分方信号权重 人物对话标记Riley: ...说话人格式每次 3 人物人物动词Riley said / laughed每次 2 人物名字附近 3 行内出现代词每次 2 人物被直接称呼Hey Riley每次 4 项目项目动词deployed Acme每次 2 项目带版本号Acme-v2每次 3 项目代码文件引用Acme.py每次 3细节很讲究单行的裸冒号可能是Created: 2026-04-21这种元数据必须命中≥2 次才算对话标记防止日期行污染人物证据。第三步阈值分类宁缺毋滥classify_entity()源码 L503-L578按人物得分占比做裁决占比 ≥ 0.7 且至少两类不同信号同时出现 →person高置信。只有一类信号刷分比如某个词恰好总在句首会被降级为uncertain占比 ≤ 0.3 →project中间地带 →uncertain标注mixed signals — needs review这种双信号要求是防误报的关键它承认单一证据再强也不足以定罪。消歧核心EntityRegistry 如何认出同名不同人检测只是起点真正的消歧发生在 entity_registry.py —— 一个持久化的个人实体注册表存储于~/.mempalace/entity_registry.json它知道 Riley 是人名、ever 是副词见 文件头注释 L1-L16。三级信息来源按优先级裁决lookup()源码 L448-L509依次查询Onboarding用户在mempalace init时明确告诉系统的人/项目—— 置信度最高Learnedlearn_from_text() 从历史会话中高置信推断出的Researched对未知词做 Wikipedia 摘要查询推断的类型默认不联网需显式开启allow_networkTrue隐私优先名字 普通单词上下文模式对决这是同名消歧最精彩的场景。COMMON_ENGLISH_WORDS 收录了 50 多个既是人名又是日常词的词Max、Grace、Bill、Mark、May、Chase……以及 Monday、March 这类句首看起来像名字的词。一旦命中_disambiguate() 会拿两组成语模式对上下文辩论人物模式PERSON_CONTEXT_PATTERNSMax said、with Max、Maxs、my son Max…概念模式CONCEPT_CONTEXT_PATTERNShave you ever、ever since、the mark of…人物证据多 → 判定为人名概念证据多 → 判定为普通词两边打平才真正放行给人名注册表兜底。一句话I had dinner with Max里是儿子have you ever tried it里是副词。别名合并Maxwell 和 Max 是同一个人初始化时通过seed()源码 L396-L444传入的别名映射如{Max: Maxwell}会让注册表同时登记两个名字并互相指向规范名canonical。检索时extract_people_from_query()源码 L667-L688无论用户查 Max 还是 Maxwell都命中同一个人——同名不同写法从此不再分裂记忆。最棘手的同名真人 vs AI 助手如果你给 AI 助手起名叫 Riley而你女儿也叫 Riley两者会在文本里大量共存。MemPalace 用 corpus_origin.py 解决mempalace init会分析语料来源识别出用户给 AI 代理起的名字agent_persona_names。随后_apply_corpus_origin()源码 L688-L735在检测结果上做一次重分类凡是命中 AI 人设名的候选直接从people里挪进独立的agent_personas桶置信度拉到 0.95。真人 Riley 和 AI 助手 Riley 就此分库而治检索时互不串味。人工确认不确定就不硬猜confirm_entities()源码 L763-L815是流程的最后一步也是新手最友好的一步。运行mempalace init时终端会打印类似这样的清单PEOPLE: 1. Riley [####.] dialogue marker (8x), pronoun nearby (3x) PROJECTS: 1. Acme [####.] project verb (5x) UNCERTAIN (need your call): 1. Mark [##...] mixed signals — needs review你可以直接回车全部接受、edit删掉误判项、add补上漏掉的人。每条候选都附上了为什么signals而不是黑箱结论——这是理解上面整套打分机制的最好入口。多语言与文件索引实体识别不是英语的专利所有词汇模式人物动词、代词、对话标记、候选字符集都住在 mempalace/i18n/ 各语言 JSON 的entity段中detect_entities(paths, languages(en, zh))可任意组合。想加新语言只需在对应 locale 文件里加一段配置无需改代码实现说明 L15-L24。想了解去看检测全流程mempalace/entity_detector.py注册表与消歧mempalace/entity_registry.py过滤词表mempalace/data/coca_content_words.jsonAI 人设识别mempalace/corpus_origin.py检测逻辑测试tests/test_entity_detector.py、tests/test_entity_registry.py总结三层防线层层递进MemPalace 的实体检测与消歧可以概括为三层防线提取层频率门槛 停用词 实词过滤 复合词词典把噪音挡在门外分类层人物/项目信号双通道打分双信号才敢下结论拿不准就标 uncertain消歧层持久化注册表用三级来源 上下文模式对决 别名合并 AI 人设分离专治同名不同人这套设计的哲学很一致自动化负责广度确定性留给证据最终裁决权留给用户。对于想构建可靠 AI 记忆系统的开发者这套检测—打分—消歧—人工确认的完整链路非常值得借鉴。【免费下载链接】mempalaceThe best-benchmarked open-source AI memory system. And its free.项目地址: https://gitcode.com/GitHub_Trending/me/mempalace创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考