Entity Enricher 将两类知识转化为结构化、经过验证的数据：大型语言模型已经掌握的知识，以及静静躺在您自己档案中未被读取的内容——PDF 文档、图像、音频录音、办公文件。每个提取出的对象都会获得一个稳定的语义标识，因此增强结果会累积成一个连贯的信息系统，而非一堆一次性的结果。
可以把 LLM 视为提炼后的人类知识——数十亿份文档、数据库和网页被压缩进可查询的神经网络。Entity Enricher 提供了以结构化、可靠且契合你数据模型的格式提取这些知识的接口。而且由于现代 model 还能读取 PDF、看图和听音频，同一套接口也能从你自己的内容中提取结构：那些你公司多年积累的合同、报告、扫描件和录音。
每次扩充都会借助其中一种或两种来源。它们互为补充：模型提供世界知识和推理能力；你的文档提供仅存在于组织内部的事实。
关于公司、药品、地点、产品、法规的公开事实——凡是模型在训练期间学到的内容皆可。只需给它一个标识符（名称、网址）和一个 schema，它就会补全其余信息：所属行业、成立年份、总部所在地、作用机制。无需任何文档。
那些从未进入数据库的知识：合同、发票、检查报告、扫描表单、产品照片、通话录音。将它们作为附件加入增强，模型便会直接从其内容中提取你 schema 的字段——无需手动 OCR、转录或复制粘贴。
有关支持的格式和传递模式，请参阅文档 attachment。
架构不仅仅是一种数据结构——它是你向人类的集体知识、或向某个特定文档提出的一个形式化问题。当你定义一个带有 companyName、industry 和 headquarters 等属性的架构时，你本质上是在问：“给定一个公司标识符，告诉我它的名称、它所处的行业以及总部所在地。”
| Schema 概念 | 用途 |
|---|---|
| 属性 | 你想要提取的具体事实 |
| 类型 | 你期望的格式（字符串、数字、对象、数组） |
| 专业领域 | 应由哪位专家作答（制药、财务、地理） |
| 搜索键 | 有助于在知识库中定位 entity 的标识符 |
| 语义 ID | 一个稳定的、以组织为范围的标识，使同一现实世界对象在各次富集及你的其他系统中都能被识别 |
| 保留 | 从你的输入中原样传递的字段 |
| 多语言 | 字段以你所使用的每种语言交付——这是一流的原生功能，而非附加的翻译步骤 |
大语言模型代表了一种全新的知识库。与仅返回存储记录精确匹配结果的传统数据库不同，LLM 能够理解上下文、对不完整的数据进行推理，并从模式中归纳总结。而且它们不再局限于纯文本：具备视觉能力的模型可读取图像和扫描页面，支持 PDF 的模型可摄入整份文档，具备音频能力的模型则可聆听录音。
Entity Enricher 将多个 LLM 视为不同的知识视角。每个提供商都带来自身的优势——Claude 擅长细致的推理，GPT-4 拥有广博的知识，Gemini 提供多语言深度，而本地的 Ollama 模型则让您的数据保持私密。
在多个 provider 上运行相同的充实，可让你对比答案以判断置信度、汇聚多位专家的共识，并在成本与质量之间取得平衡。在 多模型充实 中了解更多。
丰富化是这样一个过程：使用搜索键识别实体，从 LLM 和任何附加文档中检索相关知识，根据你的模式结构化响应，验证输出匹配预期类型，在指定处保留你的原始数据，最后解析身份——为每个对象分配其稳定的语义 ID。
{ "name": "Novartis", "website": "novartis.com" }{ "name": "Novartis", "industry": "Pharmaceutical", "foundedYear": 1996, "semantic_id": "cpt_abc123" }每次扩充都是独立的。同样的问题问两次，同一个现实事物可能返回不同的描述——今天是“Acme Inc.”，明天是“Acme Incorporated”；某种药物的副作用可能因语言或模型不同而写成“Headache”“Céphalée”或“Cephalalgia”。要真正基于扩充数据进行构建，你需要为同一实体提供一个稳定的标识。
语义 ID 是 Entity Enricher 根据对象的关键字段为其分配的组织范围内标识符，按含义而非精确拼写进行匹配。同一实体在不同的扩充、模型、语言和时间下都会解析为相同的 ID。它在模型运行后自动分配——绝不由 LLM 臆造——并且可以存在于任何对象上：整个实体、嵌套对象，或列表中的每一项。
cpt_abc123正是这一点将一连串 enrichment 转变为可供你扩展和查询的信息系统：
| 使用 | 它能实现什么 |
|---|---|
| 连接键 | 一个稳定的键，用于将富集后的记录与你的数据仓库、CRM 或主数据系统进行匹配 |
| 去重 | 将跨 batch、model 或多年文档产生的近似重复项合并为同一标识 |
| 协调 | 传入一个已知的语义 ID，新的事实就会附加到你已经跟踪的实体上，而不是新建一个实体 |
| 知识图谱 | 被多条 record 引用的对象会汇聚到同一个节点——关系变得可查询 |
解析的工作原理（精确匹配缓存、嵌入、相似度阈值）详见 Semantic IDs。
大多数公司都坐拥从未结构化的档案：存放合同和报告的共享驱动器、扫描的纸质文件、邮件附件、会议录音。那个档案就是一个数据库——只是从未被赋予行和列。将附件（作为知识来源的文档）、批量增强（并行处理）和语义 ID（在整个语料库中去重）结合起来，就能把它变成数据库。
有关工作流程的详细信息，请参阅批量 enrichment。
结构化知识不只存在于文本之中。Entity Enricher 接受你的档案库中实际包含的各种格式，并将每种格式路由至能够读取它的 model。
两种传输模式让这一切成为可能。在二进制模式下，原始字节会发送给模型，因此转换过程中不会丢失任何内容——表格的布局、照片的细节、说话者的话语。在内联文本模式下，文本在上传时提取一次并内联到每个提示词中，这适用于任何模型，无论其能力如何。
感知能力的路由意味着文件只会发送到真正能够处理它的模型——你会在数据丰富化开始前收到警告，而不是在失败之后。格式和模式详见 文档附件。
并非所有知识都是等同的。关于药物机制的问题所需的 expertise domain 与关于公司架构的问题不同。expertise domain 将 schema 属性路由到 LLM 内部合适的专家，为每个领域激活相关的知识模式。
使用多专业领域策略时，每个领域都会获得只包含相关架构属性的专注 LLM 调用，从而显著提升输出质量。
LLM 也会出错。Entity Enricher 实施了多层质量控制，以自动发现并修正错误：
搜索键可防止 LLM 对错误的实体产生幻觉。它们有两个作用：
丰富化提示词强调：“你正在丰富由这些搜索键标识的这个特定实体。”
搜索键和语义 ID 是身份的两个方面：搜索键帮助 LLM 在 enrichment 期间找到正确的实体；语义 ID 则在 enrichment 之后为其赋予系统所依赖的持久身份。
在丰富化开始前，可选的预检分类步骤可以验证实体是否确实匹配模式类型。这可防止实体不匹配时产生幻觉——例如，当 Titan 实际上是一颗卫星时，却用“Planet”模式对其进行丰富化。
LLM 调用会产生费用。Entity Enricher 会跟踪 token 用量、各提供商的费用、每次富集的费用以及组织范围内的支出。由此可以进行预算监控、提供商对比（费用与质量），以及诸如对简单字段使用更廉价模型之类的优化决策——在处理数千份文档的归档时，这一点尤为重要。
| 组件 | 概念角色 |
|---|---|
| Schema | 你要询问的问题 |
| LLM 提供商 | 不同的知识视角 |
| 附件 | 将您的档案作为知识来源（PDF、图片、音频、办公文档） |
| 搜索键 | 丰富过程中的实体身份锚点 |
| 语义 ID | 扩充后稳定的身份标识——你信息系统的支柱 |
| 专业领域 | 专家路由 |
| 策略 | 如何编排 LLM 调用 |
| 批处理 | 归档规模的并行 enrichment |
| 多语言 | 在你运营的每种语言中都保持一致的同一事实 |
| 验证 | 质量保证 |
| 保留 | 数据完整性保护 |