逐步演示 Entity Enricher 如何处理单个实体——从输入，经过分类、并行模型执行，到结构化输出。
打开工作流编辑器页面并设置你的增强。工作流步骤条会引导你完成流水线各阶段：示例数据、Schema、增强和结果——当 Schema 关联到 Database Sync 时，还会有一个“数据库就绪”步骤，用于确认本次运行的更改已排入你的数据库队列（或解释为何保存被拒绝）。
粘贴 JSON 样本以自动生成 schema，然后浏览交互式属性树。编辑属性、添加专长领域，并将字段标记为搜索键或保留字段。
配置扩充选项（策略、模型、语言、分类，以及响应 schema 和严格结构化输出开关），并填写实体搜索键（名称、网站、国家/地区等）以识别该实体。
实时显示每个模型的进度和结果。使用多个模型时，会出现用于融合的“合并结果”按钮。
有些请求根本不可能产出可用结果，而发现这一点成本最低的时机是在第一次 LLM 调用之前。系统会预先强制执行两项契约。
架构会声明其输入必须包含的内容：标明是哪一个实体的键字段、你提供的数组中每一项的键，以及每个标记为 preserve 的字段的值（从未提供过的内容无法保留）。缺少其中任何一项的请求都会被拒绝，并返回一条一次性列出全部违规项的错误——同时附上架构的完整契约，让你一次改完，而不必被逐次拒绝才逐条发现要求。每个已保存的架构都会公布该契约，客户端可在发送前自行校验。
由你提供条目的数组会被精确扩充：模型补全它对每个条目的已知信息，既不能增加也不能删除条目。你发送五个明细项，就会拿回五个。模型未能认领的条目会被原样放回而不会丢失，它凭空捏造的条目则被丢弃。你留空的数组仍是开放的 — 那正是模型在发现事实，也正是其意义所在。
如果您选择了分类模型，系统会先执行一次快速、低成本的 LLM 调用，以验证实体是否与 schema 类型匹配。这可以避免在实体不匹配时将 token 浪费在增强上。详见分类文档。
每个所选模型都会按您指定的策略处理实体——若未指定，则默认采用根据模式结构自动选择的策略，运行开始时会予以说明。选择多个模型时，它们会跨提供商并行运行（Claude 与 GPT-4 同时执行），而同一提供商的模型则依次运行，以遵守速率限制。
每个 LLM 响应都会实时根据你的 schema 进行校验。当输出与预期类型或约束不符时，系统会自动将错误发回给 LLM 进行修正。
每次 LLM 调用最多自动重试 5 次。每次重试都会附上具体的校验错误，让 LLM 明确知道该修什么——而且修复是精准的：只重新询问出错的叶子节点，而不是整个回答。
请注意此列表中没有的内容：模型无法确定的值并不是需要重试的错误。任何字段都可能返回缺失，而模型会声明它找不到的内容，因此“未知”是一种答案，而非失败。缺失值是否可接受将在稍后决定，即实体被接纳进入你的数据库时——而不是靠让模型猜测。
两个可选开关会要求提供商在输出返回之前就对其加以约束，从而从一开始就减少需要纠正的响应。二者仅适用于支持它们的模型；其余一切仍会回退到上面的验证并重试流程。
Entity Enricher 使用服务器发送事件（SSE）实时流式传输进度。您无需等待所有模型完成——结果会随着每个专业领域或模型的完成而逐步显示。
每个模型都有其专属结果面板，展示结构化 JSON 输出、各专业领域的进度标记、token 用量、成本和处理时间。使用多专业领域策略时，专业领域标记会在各领域完成时实时更新。
使用多专业领域策略时，部分专业领域可能失败，而其他专业领域成功。Entity Enricher 不会丢弃全部结果，而是返回成功专业领域合并后的输出，并标记为“部分完成”状态。随后你只需重试失败的专业领域，而无需重新运行整个富集。
增强完成后，结果会保存到历史记录页面，以供日后查阅。如果您使用了多个模型，可以通过多模型融合合并结果。