EDM SDK：为AI记忆系统构建情感数据层的开源工具

deepadata-edm-sdk是一个开源SDK，用于从用户内容中提取符合EDM v0.7.0标准的情感数据工件，为AI记忆系统提供结构化的情感语义层。

当前的大语言模型和AI助手在对话中展现出惊人的语言理解和生成能力，但它们在处理"记忆"时往往停留在表面。大多数系统将对话内容简单地存储为原始文本或向量嵌入，在需要检索时依赖语义相似度匹配。这种"关键词匹配"式的检索方式有一个根本缺陷：它只能找到"说了什么"相似的内容，却难以捕捉"为什么重要"的情感和意义层面。

想象一下，你向AI助手讲述了一段关于祖母的回忆。几个月后，当你提到"夏天"或"老房子"时，你希望AI能记起那段关于祖母的对话——即使这些词在当时根本没有出现。传统的向量检索很难做到这一点，因为它缺乏对情感重要性、记忆触发点和身份关联的显式建模。

这就是EDM（Emotional Data Metadata）规范试图解决的问题。EDM不是替代传统的向量检索，而是为其增加一个"意义层"——一个显式编码情感权重、回忆触发器和身份线索的结构化数据层。

deepadata-edm-sdk是EDM v0.7.0规范的开源实现，提供了一套完整的工具链，用于从用户内容中提取、验证和封装情感数据工件。该SDK的设计理念可以概括为三个关键词：提取而非推断、结构化而非原始、可移植而非锁定。

EDM SDK严格区分"提取"和"推断"。SDK使用大语言模型（支持Claude、OpenAI、Kimi等）从文本和图像中提取显式陈述或明确暗示的情感信息，但不会进行超出输入内容的心理推断。例如，它会提取"用户提到感到悲伤"这样的显式陈述，但不会推断"用户可能患有抑郁症"这样的诊断结论。

这种设计不仅是技术上的谨慎，更是合规性的考量。根据欧盟AI法案，情感数据提取属于较低风险类别，而情感推断系统则可能面临更严格的监管要求。EDM SDK通过明确的"解释约束"确保其应用符合相关法规。

EDM v0.7.0定义了10个核心域（Domain），涵盖了从元数据、核心情感、情感分类到上下文、显著性、动机状态等维度。每个域都有明确的字段定义和数据类型，形成了一套完整的情感数据本体论。

这10个域分别是：

• meta域：身份标识、数据来源、同意基础等元信息
• core域：核心情感元素，包括锚点（anchor）、火花（spark）、创伤（wound）、燃料（fuel）、桥梁（bridge）、回声（echo）和叙事（narrative）
• constellation域：情感分类和原型映射
• milky_way域：上下文锚定，包括相关人物、地点、事件
• gravity域：显著性、权重和检索关键词
• impulse域：动机状态、驱动力和应对机制
• governance域：管辖权、保留策略和数据主体权利
• telemetry域：提取置信度、模型ID等技术遥测
• system域：嵌入向量、索引等下游系统字段
• crosswalks域：与Plutchik情感轮、HMD等外部分类法的映射

这种结构化的设计使得情感数据可以被精确检索和关联。例如，系统可以查询"所有与'家庭'相关且情感权重大于0.8的记忆"，或者"找出触发'怀旧'情感的所有内容"。

EDM工件采用JSON格式，可以在不同平台和系统之间自由传输。SDK还提供了与deepadata-ddna-tools的集成，支持将工件封装为签名的.ddna信封格式，确保数据的完整性和来源可验证性。

更重要的是，EDM SDK支持"无状态模式"（stateless mode），在这种模式下，所有可能识别个人身份的信息（如用户ID、关联人物、位置上下文）都被置空，只保留情感结构本身。这使得EDM工件可以在隐私敏感的场景中使用，例如临时会话或共享分析。

EDM v0.7.0引入了"配置感知"的提取概念，提供三个级别的字段集：

适用于记忆平台、智能体框架和AI助手。这个精简配置包含了最核心的情感字段，足以支持基本的情感检索和关联功能，同时最小化数据收集和存储成本。