DeepSeek不直接提供开箱即用的ERE API，需通过JSON Schema约束、system prompt定义和response_format强制结构化输出；推荐分层协作：OCR预处理→规则初筛→deepseek-reasoner推理→pydantic校验。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
DeepSeek 本身不直接提供开箱即用的实体关系抽取（ERE）API，它是一个通用大语言模型，必须配合提示工程或下游微调/工具链才能稳定提取实体和关系。直接喂一段文本问“抽人名和公司”，结果常漏、错、格式混乱——这不是模型能力问题，而是调用方式没对齐任务本质。
为什么不能直接用 client.chat.completions.create 调 DeepSeek 抽关系？
因为标准 chat 接口是生成式交互，默认不保证结构化输出，常见问题包括：
- 同一段文本多次请求，
entity字段名可能变成person或name，字段顺序不固定 - 关系描述口语化：“张三在阿里工作” → 输出 “就职于”，但有时又写成 “任职公司是”、“属于”
- 嵌套关系丢失：如“李四投资了王五创办的公司”，模型可能只抽到“李四-投资-王五”，漏掉“王五-创办-公司”
- 无空值处理：当某类实体不存在时，不返回空数组，而是直接跳过该字段，导致解析失败
这些问题在构建知识图谱或接入数据库时会直接引发 KeyError 或数据断裂。
用 deepseek-chat 做 ERE 的可靠做法：强制 JSON Schema + system prompt
核心思路：不让模型“自由发挥”，而是用 system 角色定义输出契约，再用 response_format={"type": "json_object"}（需 v3.2+ 支持）约束格式。示例 prompt：
system: 你是一个严格的实体关系抽取器。请从用户输入中提取以下三类实体：person、organization、location；以及它们之间的关系，关系类型仅限：works_at、founded、located_in。输出必须为合法 JSON，包含两个键："entities"（数组，每个元素含 type 和 name）、"relations"（数组，每个元素含 head、tail、relation）。不要任何额外说明或 markdown 包裹。
关键点：
-
response_format={"type": "json_object"}必须显式传入，否则即使 prompt 写了 JSON，模型仍可能输出带解释的文本 - 实体类型名（如
person）要和后续代码解析逻辑完全一致，大小写、复数、下划线都不能错 - 关系类型必须枚举穷尽，不能写“其他关系”，否则下游无法映射到图谱 schema
- 对长文本，建议先用
DeepSeek-OCR-2预处理——它输出的带层级标记文本（如## 公司简介）比纯 OCR 文本能显著提升抽取准确率
真正要上生产，别只靠 deepseek-chat 单打独斗
纯 LLM 提示工程适合快速验证，但上线后会暴露稳定性短板。更健壮的路径是分层协作：
- 前端用
DeepSeek-OCR-2处理 PDF/扫描件 → 输出带标题、表格、列表结构的 Markdown，保留原文空间语义 - 中端用规则或轻量 NER 模型（如
spacy中文模型）做初筛，过滤出疑似person/organization的 span 及位置 - 后端把原文 + 结构化上下文（如“该段落标题为‘高管团队’”）拼成 prompt，交由
deepseek-reasoner（v3.2 新增）做关系判定，它对逻辑链推理更强 - 最后用
pydantic校验输出 JSON 是否符合预定义 model，失败则降级为重试或人工审核队列
容易被忽略的一点：DeepSeek 的 token 限制是 128K，但实体关系抽取不是越长越好——超过 8K token 的上下文会让关系判断失焦。实际应按语义块切分（如每页 PDF → 一个段落组），而非整份文档硬塞。
