纠错与删除

本页操作都使用原先写入时的 API Key。地址、认证和字段约束见接口说明；首次接入先运行快速开始。下列 JSON 是对应接口的请求体。

保存自己的记录编号

写入时加入 client_record_id，并保存响应的 record_ids 与事实的对应表：

POST /v1/relations

{
  "relations": [{
    "source": "demo-order-101",
    "relation": "status",
    "target": "pending",
    "client_record_id": "demo-status-101"
  }]
}

record_ids[0] 对应第一条输入，依此类推。凭证只用于定位，不能还原原文。自己的编号在同一 Key 下不能重复分配给不同事实。

修改错误记录

使用上一节写入响应的记录凭证，向 PATCH /v1/relations/{record_id} 发送待修改字段。例如把订单状态从 pending 更正为 paid：

{"target": "paid"}

成功仅返回：

{"ok": true}

随后调用 /v1/evaluate，分别核验新值和旧值，确认与业务依据相符。旧值失去支持时可能变成 UNKNOWN，不必然变成 FALSE。同时更新自己保存的原始记录。

自定义属性也使用同一编辑接口。修改保留原记录凭证和 client_record_id，不需要先删除再写入；其他记录和 Key 不受影响。修改结果若与其他有效事实冲突，后续核验会保留冲突提示。

一次至少提供一个待修改字段。可改 source、relation、target、polarity、confidence、context、validity、provenance、evidence_refs；不能修改 client_record_id。编辑响应不会回传修改前后的记录内容。

如果这是“状态随时间变化”，而非原记录写错，应给前后状态分别设置有效时间，避免把历史状态当成同时生效的冲突。不要未经核对就删除另一份证据。

删除指定测试数据

向 POST /v1/relations/delete 提交以下四种方式之一。一次只能选一种，不能混用。

按自己的编号删除

{"client_record_ids": ["demo-status-101"]}

适合日常清理。多个编号放在同一数组中，每次最多 10,000 个，不能重复。

按记录凭证删除

将下方占位值替换成写入响应里的实际凭证：

{"record_ids": ["mr_替换为保存的完整凭证"]}

单条也可用 DELETE /v1/relations/{record_id}。

记录修改后，仍可用原凭证或原 client_record_id 删除；如果按完整事实删除，则应填写修改后的内容。

没有保存编号时，按完整事实删除

例如清理以前写入的探测记录：

{
  "relations": [{
    "source": "probe-001",
    "relation": "supports",
    "target": "probe-target-001"
  }]
}

必须填写完整的 source、relation、target。原记录有 polarity、context 或 validity 时，一并提供对应值。省略这些字段只匹配肯定、无范围、无时间限制的事实，不表示“所有范围和时间”。

不支持 probe-*、前缀或通配符删除。请从自己的测试脚本或记录中找出实际提交的完整事实，组成数组删除，不要为了几条测试数据清空整个 Key。

按已完成的导入批次删除

{"batch_id": "demo-import-101"}

只清理该批次新建、且未被后续写入复用或修改的记录。导入前已有的记录、后来复用或改过的记录会保留。确实要删这些记录时，用凭证或完整事实指定。

批次删除后，原批次不能再次上传恢复，重新导入需要新 batch_id。尚未完成或不支持按批次清理的导入会返回 409。

确认删除结果

成功只返回状态和本次删除数量，例如：

{"ok": true, "deleted_count": 1}

用同一 Key 再核验对应事实。没有其他支持时通常变成 UNKNOWN；仍有独立证据或其他支持路径时可能为 TRUE，不能据此断定删除失败。

按编号删除时，列表里任何编号不存在都会返回 404，本次不做部分删除。按完整事实删除，无匹配时返回 deleted_count: 0。重复删除已清理的批次也返回 0。

只有 Key，没有保存凭证怎么办

GET /v1/relations?limit=100&cursor=0 可分页取得凭证。响应示意如下，编号以实际返回为准：

{
  "ok": true,
  "relations": [{"record_id": "mr_示例凭证"}],
  "next_cursor": null,
  "request_id": "示例请求编号"
}

列表不回传事实内容，不能用它重新下载原始资料。定位某条事实时，优先用自己保存的编号、凭证对应表或完整事实。

需要遍历时，按 next_cursor 继续，直到 null。先完成分页，再删除；遍历期间避免同时写入或删除，以免位置变化造成遗漏。不要把全部凭证当作某个前缀的匹配结果直接删除。

大量记录分批导入

1. 为本次导入生成唯一 batch_id，确定 total，第一块 offset 为 0。
2. 每次调用 POST /v1/relations，携带同一 batch_id、total 和当前块的 offset。
3. 按响应 next_offset 继续；status: complete 才表示整批提交完成。

两条记录拆成两次提交：

{
  "batch_id": "demo-import-101",
  "total": 2,
  "offset": 0,
  "relations": [{"source": "demo-app-101", "relation": "depends_on", "target": "demo-cache-101"}]
}

第一块返回 status: partial、next_offset: 1。接着提交：

{
  "batch_id": "demo-import-101",
  "total": 2,
  "offset": 1,
  "relations": [{"source": "demo-cache-101", "relation": "depends_on", "target": "demo-db-101"}]
}

最后返回 status: complete。完成前新导入记录不能用于查询；最后一块完成后，record_ids 按整批输入顺序返回，包含复用记录的凭证。保存这份对应表。

每块最多 10,000 条，不必凑满，可从较小块开始。完整批次接收上限以服务实际响应为准。

超时与重试

先查询 GET /v1/relations/batches/{batch_id}：

• complete：不要新建批次；需要补取凭证时，可原样重放已提交的块。
• partial：按 next_offset 继续；重放旧块必须保持批次号、总量、偏移和内容完全一致。
• deleted：已清理，不要重传；新的导入用新批次号。
• 404：确认 Key 和批次号；确认未接收后，再从第一块提交。

重试不是免费承诺，请在客户中心核对用量。批次进度不是永久备份，保留原始输入，及时完成上传。

全部清空：仅在不再需要这个 Key 时使用

这会销毁当前 Key 的全部记忆，并注销 Key。完成后需创建新 Key，不能通过本接口撤销。

POST /v1/relations/clear

{"confirm": "clear_project"}

clear_project 是接口要求的固定确认值，不是要填写项目名称。清理少量测试数据请使用前面的指定删除。

常见问题

返回快速开始 · 大模型接入