03_神经符号集成与多智能体本体系统：SOLAR框架与可解释公文AI架构实战
·
神经-符号集成与多智能体本体系统：SOLAR框架与可解释公文AI架构实战
核心关键词： 神经-符号集成、Multi-Agent、SOLAR框架、可解释AI、符号推理、公文大模型、知识获取、知识应用、本体增强
标签： 本体论、人工智能、大语言模型、知识图谱、神经符号AI、多智能体系统、公文智能化
2023年，我接手了一个国企集团的公文智能化项目。项目需求看起来不算复杂：让AI辅助办公室处理海量公文的分类、审核和归档。但真正做起来才发现，公文处理的难度远超预期——公文的语义判断常常依赖隐含的行政层级关系，同一份文件在不同业务场景下可能有完全不同的解读，更关键的是，任何一个错误都可能造成严重的行政事故。
这个项目促使我系统性地研究了神经-符号集成在公文领域的应用，最终形成的方案参考了SOLAR框架的设计思想。这篇文章就来详细聊聊这个框架的核心原理、工程实现，以及在实际公文AI系统中的落地经验。
一、为什么公文AI需要两条腿走路
1.1 大语言模型处理公文的优势与局限
大语言模型在公文处理上确实展现了惊人的能力——自动生成公文摘要、提取关键信息、辅助撰写回复意见，LLM的输出流畅度和专业感让很多办公室人员惊叹。但这份流畅背后有一个根本性问题：LLM不保证推理的正确性和一致性。
┌────────────────────────────────────────────────────────────────────┐
│ LLM在公文推理中的典型失败案例 │
├────────────────────────────────────────────────────────────────────┤
│ │
│ 案例1: 公文类型误判 │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ 输入: "关于申请采购办公设备的函" │ │
│ │ LLM输出: "请示" │ │
│ │ 正确分类: "函" │ │
│ │ 问题: "函"和"请示"的办理流程、回复要求完全不同，误判会导致流程错误│ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
│ 案例2: 格式要素提取遗漏 │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ 输入: 一份格式不规范的内部通知 │ │
│ │ LLM输出: 提取了标题和正文，遗漏了发文字号和签发日期 │ │
│ │ 问题: 这些遗漏的要素在后续流程中至关重要 │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
│ 案例3: 政策依据张冠李戴 │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ 输入: "根据总公司关于差旅费管理办法..." │ │
│ │ LLM输出: 引用了《总公司差旅费管理办法》2023版 │ │
│ │ 实际情况: 2024年已发布新版本，规定内容有重大调整 │ │
│ │ 问题: 引用的依据已过期 │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────┘
这类错误在LLM的公文处理输出中极为普遍。原因是LLM的"推理"本质上是语言模式匹配，而不是符号逻辑推演。它学会了"关于XXX的请示"通常对应"请示"这类统计规律，但没有真正理解公文类型的定义边界和办理流程的逻辑要求。
1.2 传统本体和规则引擎的优势与局限
传统本体论和规则引擎的推理能力是可靠的——给定正确的公理和事实，推理机总能给出逻辑上一致的结论，而且推理过程可以逐条解释。这正是公文处理领域最需要的特性。
┌────────────────────────────────────────────────────────────────────┐
│ 手工编码公文规则需要多少人月？ │
├────────────────────────────────────────────────────────────────────┤
│ │
│ 场景: 某央企集团公文处理系统 │
│ │
│ 预估规则数量: │
│ ├─ 公文类型判断规则: ~200条 │
│ ├─ 格式审核规则: ~500条 │
│ ├─ 办理流程规则: ~300条 │
│ ├─ 权限判断规则: ~150条 │
│ └─ 归档分类规则: ~100条 │
│ │
│ 预估工作量: │
│ └─ 约1250人月 (含规则梳理、编码、测试) │
│ │
│ 现实约束: │
│ ├─ 实际可用资源: 约20人月 │
│ └─ 缺口: 约1050人月 │
│ │
│ 结论: 纯手工编码方案不可行 │
│ │
└────────────────────────────────────────────────────────────────────┘
符号系统的局限也很明显：
- 规则获取成本高：手工编写上千条公文处理规则需要大量人力
- 边界模糊处理困难：符号系统无法优雅地处理"情节较重"、"明显不合理"这类模糊公文概念
- 覆盖度有限：规则只能覆盖预设的场景，对新型公文格式无法自动适应
1.3 神经-符号集成：两条腿走路
┌────────────────────────────────────────────────────────────────────┐
│ 神经-符号集成的互补优势 │
├────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ 神经网络 (LLM) │ │ 符号系统 (本体) │ │
│ ├─────────────────────┤ ├─────────────────────┤ │
│ │ ✓ 自然语言理解强 │ │ ✓ 推理正确性保证 │ │
│ │ ✓ 模糊概念处理好 │ │ ✓ 过程可解释 │ │
│ │ ✓ 知识获取自动化 │ │ ✓ 一致性可验证 │ │
│ │ ✓ 上下文学习能力 │ │ ✓ 规则可复用 │ │
│ │ ✗ 推理正确性不保证 │ │ ✗ 获取成本高 │ │
│ │ ✗ 可解释性差 │ │ ✗ 边界模糊处理难 │ │
│ │ ✗ 一致性无保证 │ │ ✗ 覆盖度有限 │ │
│ └─────────────────────┘ └─────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────┐ │
│ │ 神经-符号集成系统 │ │
│ ├─────────────────────────┤ │
│ │ ✓ LLM做知识获取和理解 │ │
│ │ ✓ 本体做推理和验证 │ │
│ │ ✓ 接口层确保可追溯性 │ │
│ └─────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────┘
神经-符号集成的核心思想是让LLM和符号系统各司其职：用LLM处理自然语言理解、知识获取、模糊概念处理这些它擅长的任务，用符号系统处理推理验证、一致性检查、规则应用这些需要严格保证的任务。
二、SOLAR框架：公文本体系统的参考架构
2.1 框架概述
SOLAR（Semantic Ontology with Logical Reasoning）是近年来在公文AI领域受到较多关注的神经-符号集成框架。它的核心设计思想是用LLM做知识获取，用符号系统做知识应用，中间用可验证的接口连接。
┌────────────────────────────────────────────────────────────────────┐
│ SOLAR框架双阶段架构 │
├────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 阶段I: 知识获取 │ │
│ │ ┌──────────────────────────────────────────────────────┐ │ │
│ │ │ 公文文本语料库 │ │ │
│ │ │ [标准公文库] [历史公文档案] [公文格式规范] │ │ │
│ │ └──────────────────────────────────────────────────────┘ │ │
│ │ ↓ │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ 概念提取 │ │ 规则制定 │ │ 本体验证 │ │ │
│ │ │ Agent │ │ Agent │ │ Agent │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ │ ↓ │ │
│ │ ┌──────────────────────────────────────────────────────┐ │ │
│ │ │ 公文本体 + 形式化规则库 │ │ │
│ │ │ TBox (概念结构) + RBox (规则集) │ │ │
│ │ └──────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 阶段II: 知识应用 │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ 查询分析 │ │ 符号推理 │ │ 答案生成 │ │ │
│ │ │ Agent │ │ Agent │ │ Agent │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ │ ↓ │ │
│ │ ┌──────────────────────────────────────────────────────┐ │ │
│ │ │ 可解释的公文处理结果 │ │ │
│ │ │ [分类结果] [审核意见] [归档建议] + 推理依据 │ │ │
│ │ └──────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────┘
2.2 阶段I：知识获取
2.2.1 概念提取Agent
class ConceptExtractionAgent:
"""
概念提取Agent: 从公文文本中自动提取概念
"""
def __init__(self, llm, ontology):
self.llm = llm
self.ontology = ontology
def extract(self, text: str) -> List[Concept]:
"""
提取公文中的核心概念
"""
# 构建提示
prompt = f"""
输入: 公文文本片段
```{text}```
你是一个公文本体工程师。请从以下公文文本中提取概念定义。
对于每个识别的概念，请提供:
1. concept_name: 概念名称
2. definition: 精确的定义（引用文本原句或摘要）
3. attributes: 概念的关键属性列表
4. relationships: 与其他概念的关系
5. confidence: 置信度 (0.0-1.0)
请以结构化格式输出。
"""
# 调用LLM提取
response = self.llm.generate(prompt)
# 解析结果
concepts = self._parse_response(response)
# 验证与本体一致性
validated = self._validate_with_ontology(concepts)
return validated
def _parse_response(self, response: str) -> List[Concept]:
"""解析LLM输出"""
# 实际实现中使用结构化输出
# 这里简化为文本解析
import json
return json.loads(response)
2.2.2 规则制定Agent
class RuleFormulationAgent:
"""
规则制定Agent: 将公文条例转化为形式化规则
"""
def __init__(self, llm, ontology):
self.llm = llm
self.ontology = ontology
def formulate_rules(self, regulation_text: str) -> List[HornClause]:
"""
将公文条例转化为Horn子句规则
"""
prompt = f"""
将以下公文条例转化为Horn子句规则。
公文条例:
```{regulation_text}```
要求:
1. 使用 Horn子句格式: head :- body1, body2, ...
2. 变量用大写字母表示
3. 每个条件对应文本中的一个要件
4. 包含规则的前提条件(antecedent)和结论(consequent)
输出格式:
- 规则编号
- 原始条例引用
- Horn子句表示
- 前提条件解释
- 置信度评估
"""
response = self.llm.generate(prompt)
rules = self._parse_rules(response)
# 验证规则一致性
consistent = self._check_consistency(rules)
if not consistent:
raise ValueError("规则冲突检测")
return rules
def formulate_from_template(self, template: str, context: Dict) -> List[Rule]:
"""
基于模板生成规则
"""
# 处理类公文常用模板
if template == "request_document":
# 请示类公文的处理规则
rules = [
Rule(
head="requires_approval(X)",
body="is_request_document(X), has_subject(Y,X), urgent_level(Y,high)"
),
Rule(
head="processing_department(X,Y)",
body="is_request_document(X), determines_subject(Y,X)"
)
]
return rules
elif template == "notification":
# 通知类公文的分发规则
rules = [
Rule(
head="distribution_list(X,L)",
body="is_notification(X), scope(X,S), lookup_departments(S,L)"
)
]
return rules
return []
2.3 阶段II：知识应用
┌────────────────────────────────────────────────────────────────────┐
│ 阶段II: 公文处理查询流程 │
├────────────────────────────────────────────────────────────────────┤
│ │
│ 用户查询 │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 1. 查询分析Agent │ │
│ │ 输入: 用户查询 │ │
│ │ 输出: 查询意图 + 查询参数 │ │
│ │ ┌───────────────────────────────────────────────────────┐ │ │
│ │ │ QueryIntent: "公文类型分类" │ │ │
│ │ │ QueryParams: {document_text: "..."} │ │ │
│ │ └───────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 2. 事实提取Agent │ │
│ │ 输入: 查询参数 │ │
│ │ 输出: 提取的事实元组 │ │
│ │ ┌───────────────────────────────────────────────────────┐ │ │
│ │ │ Facts: {hasTitle: "...", hasDocumentType: ?, ...} │ │ │
│ │ └───────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 3. 符号推理Agent (SMT求解器) │ │
│ │ 输入: 公文本体(TBox) + 提取事实(ABox) + 推理规则 │ │
│ │ 输出: 推理结论 + 推理路径 │ │
│ │ ┌───────────────────────────────────────────────────────┐ │ │
│ │ │ Conclusion: document_type(request, high_priority) │ │ │
│ │ │ ReasoningPath: [step1, step2, step3] │ │ │
│ │ └───────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 4. 答案生成Agent │ │
│ │ 输入: 推理结论 + 推理路径 │ │
│ │ 输出: 自然语言回答 + 可解释性元数据 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ 可解释的公文处理结果 │
│ │
└────────────────────────────────────────────────────────────────────┘
三、多智能体协作机制
3.1 专业化分工架构
SOLAR框架最巧妙的设计是把一个复杂的公文AI任务，分解成多个专业化智能体，每个智能体只做一件事：
┌────────────────────────────────────────────────────────────────────┐
│ 公文AI任务分解与专业化分工 │
├────────────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────┐ │
│ │ 协调Agent │ ← 任务分解、结果整合、质量控制 │
│ └───────┬───────┘ │
│ │ │
│ ┌───────┴───────────────────────────────────────────────┐ │
│ │ 专业Agent池 │ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 分类Agent │ │ 审核Agent │ │ 提取Agent │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ • 类型判断 │ │ • 格式检查 │ │ • 要素提取 │ │ │
│ │ │ • 优先级评估 │ │ • 规范性验证 │ │ • 关键信息 │ │ │
│ │ │ • 紧急程度 │ │ • 完整性检查 │ │ • 关联追溯 │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 摘要Agent │ │ 推荐Agent │ │ 归档Agent │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ • 内容摘要 │ │ • 办理建议 │ │ • 分类建议 │ │ │
│ │ │ • 要点提取 │ │ • 流程推荐 │ │ • 存储位置 │ │ │
│ │ │ • 关键词生成 │ │ • 责任部门 │ │ • 版本管理 │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────┘
3.2 心智理论集成
class TheoryOfMindAgent:
"""
心智理论Agent: 实现Agent间的认知协同
"""
def __init__(self):
self.beliefs = {} # Agent信念
self.intentions = {} # Agent意图
self.context = {} # 共享上下文
def update_belief(self, agent_id: str, key: str, value: any):
"""更新Agent信念"""
if agent_id not in self.beliefs:
self.beliefs[agent_id] = {}
self.beliefs[agent_id][key] = value
self.context[f"{agent_id}_{key}"] = value
def get_other_beliefs(self, agent_id: str, key: str) -> List[Dict]:
"""获取其他Agent的信念"""
results = []
for other_id, beliefs in self.beliefs.items():
if other_id != agent_id and key in beliefs:
results.append({
"agent_id": other_id,
"belief": beliefs[key]
})
return results
def infer_intention(self, agent_id: str) -> str:
"""推断Agent意图"""
beliefs = self.beliefs.get(agent_id, {})
# 基于信念推断意图
if beliefs.get("task") == "classification":
if beliefs.get("uncertainty") > 0.3:
return "request_verification"
else:
return "proceed_with_classification"
return "unknown"
3.3 显式检查点机制
class InspectionPoint:
"""
显式检查点: 确保每步推理可追溯
"""
def __init__(self, step_id: str, step_type: str):
self.step_id = step_id
self.step_type = step_type
self.input = None
self.output = None
self.evidence = []
self.verified = False
def checkpoint(self, input_data, output_data, evidence: List):
"""记录检查点"""
self.input = input_data
self.output = output_data
self.evidence.extend(evidence)
# 自动验证
self.verified = self._verify()
return self.verified
class VerificationAgent:
"""
评判Agent: 对处理结果进行评估
"""
def evaluate(self, checkpoints: List[InspectionPoint]) -> VerificationReport:
"""
评估推理过程
"""
report = VerificationReport()
# 评估1: 概念可验证性
report.concept_verified = self._check_concept_verification(checkpoints)
# 评估2: 规则可审查性
report.rules_reviewable = self._check_rules_review(checkpoints)
# 评估3: 推理可追溯性
report.reasoning_traceable = self._check_traceability(checkpoints)
# 评估4: 政策依据充分性检查
report.policy_justified = self._check_policy_justification(checkpoints)
return report
def _check_policy_justification(self, checkpoints: List[InspectionPoint]) -> bool:
"""
检查政策依据是否充分
公文AI必须回答: 这个结论是哪条规定?
"""
for cp in checkpoints:
if cp.step_type == "conclusion":
if not cp.evidence or len(cp.evidence) == 0:
return False # 无政策依据
# 检查依据是否与结论相关
relevant = self._check_relevance(cp.output, cp.evidence)
if not relevant:
return False # 依据不相关
# 检查依据是否仍然有效
valid = self._check_validity(cp.evidence)
if not valid:
return False # 依据已失效
return True
这套评估机制确保了每个推理步骤的政策依据都是显式且可验证的。当最终答案需要接受上级审查时，检查点机制让审查者可以精确地定位到需要重点审核的步骤，而不是面对一整段黑盒推理过程。
四、三层可追溯性
SOLAR框架对公文AI最重要的贡献之一，是建立了推理过程的三层可追溯性：
┌────────────────────────────────────────────────────────────────────┐
│ 推理过程三层可追溯性 │
├────────────────────────────────────────────────────────────────────┤
│ │
│ 第一层: 概念追溯 │
│ ├─ 每一步使用的概念都有来源 │
│ ├─ 概念定义可查看 │
│ └─ "请示" → 来源于《党政机关公文格式》GB/T 9704-2012 │
│ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ Example: │ │
│ │ Step 1: 判断公文类型为"请示" │ │
│ │ └── 依据: 公文标题包含"关于申请" │ │
│ │ └── 来源: 历史公文标注数据 │ │
│ │ │ │
│ │ Step 2: 识别主送机关为"集团总部" │ │
│ │ └── 依据: 正文首行"集团总公司：" │ │
│ │ └── 来源: 公文格式规范解析 │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
│ 第二层: 规则追溯 │
│ ├─ 每一步应用的规则都有明确标识 │
│ ├─ 规则的前提条件可验证 │
│ └─ Rule_001: requires_approval(X) ← is_request(X) │
│ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ Example: │ │
│ │ Step 3: 得出结论"需要上级审批" │ │
│ │ └── 应用规则: requires_approval(X) ← is_request(X) │ │
│ │ └── 前提验证: is_request(本公文) = true │ │
│ │ └── 规则来源: 公文处理规范v2.3 │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
│ 第三层: 责任追溯 │
│ ├─ 推理过程的每一步都关联到具体的Agent │
│ ├─ Agent的置信度可评估 │
│ └─ 最终决策的责任人可确定 │
│ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ Example: │ │
│ │ Step 4: 生成办理意见 │ │
│ │ └── Agent: RecommendationAgent_v2 │ │
│ │ └── 置信度: 0.85 │ │
│ │ └── 需要人工确认: true │ │
│ │ └── 确认人: 办公室专员 │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────┘
三层可追溯性对公文AI的意义怎么强调都不为过。办公室领导、审计人员、合规专员都需要能够检查和质疑AI的处理过程。一个黑盒系统哪怕准确率再高，也无法在正式场合作为辅助工具使用——因为上级检查时会问："你的AI是怎么得出这个结论的？"三层可追溯性让这个问题有了答案。
五、工程实践：构建公文多智能体系统
5.1 技术栈选择
┌────────────────────────────────────────────────────────────────────┐
│ 公文多智能体系统的参考技术栈 │
├────────────────────────────────────────────────────────────────────┤
│ │
│ 基础模型层 │
│ ├─ GPT-4o: 通用推理强，但成本高、专业性一般 │
│ ├─ Claude-3.5: 长上下文强、幻觉率低，中文公文处理能力强 │
│ └─ DeepSeek-V3: 推理能力强，中文理解优秀 │
│ │
│ 本体与推理层 │
│ ├─ OWL本体: Protégé编辑 + RDF存储 │
│ ├─ 规则引擎: Drools / Jess │
│ └─ 求解器: Z3 / CVC4 (SMT求解) │
│ │
│ Multi-Agent编排 │
│ ├─ LangGraph: 状态流编排 │
│ ├─ AutoGen: 对话式协作 │
│ └─ CrewAI: 角色扮演式协作 │
│ │
│ 部署与监控 │
│ ├─ 推理服务: vLLM / TensorRT-LLM │
│ └─ 可观测性: LangSmith / Phoenix │
│ │
└────────────────────────────────────────────────────────────────────┘
5.2 Token成本控制
多智能体系统的最大工程挑战是token成本控制。每个智能体之间的通信都会产生token消耗，如果设计不当，完整处理一份复杂公文可能消耗几万token，成本不可接受。
class TokenBudgetController:
"""
Token预算控制器
"""
def __init__(self, max_tokens_per_request: int = 8000):
self.max_tokens = max_tokens_per_request
self.usage_history = []
def allocate(self, agent_id: str, task_complexity: str) -> int:
"""
分配Token预算
"""
base_allocations = {
"simple": 2000, # 简单任务
"medium": 4000, # 中等任务
"complex": 6000, # 复杂任务
}
return base_allocations.get(task_complexity, 2000)
def optimize_prompt(self, prompt: str, max_length: int) -> str:
"""
优化Prompt长度
"""
# 估算当前长度
current_length = len(prompt.split())
if current_length <= max_length:
return prompt
# 压缩策略
# 1. 移除冗余说明
# 2. 使用缩写
# 3. 精简示例
return self._compress(prompt, max_length)
def monitor_and_alert(self, usage: int):
"""
监控并告警
"""
self.usage_history.append(usage)
avg_usage = sum(self.usage_history[-10:]) / min(10, len(self.usage_history))
if usage > self.max_tokens * 0.8:
# 发送告警
return {"alert": True, "usage_ratio": usage / self.max_tokens}
return {"alert": False, "usage_ratio": usage / self.max_tokens}
5.3 实战经验总结
回顾过去几年构建的几个公文AI系统，有几个架构决策我认为是正确的：
决策1: 始终保持人在回路。即使LLM辅助推理的准确率达到95%，剩下的5%在公文场景里依然不可接受。系统在关键决策点（比如公文分类、归档建议）必须有人工确认机制。
决策2: 优先构建公文本体。在动手写代码之前，先花足够的时间梳理公文本体。我见过太多项目急着上AI，结果因为本体定义不清晰，输出的结果时对时错。公文本体的质量直接决定了系统效果的上限。
决策3: 优先保证可解释性。在准确率和可解释性之间发生冲突时，优先保证可解释性。一个能解释自己错误的系统，在公文场景里比一个"碰巧对"的系统更有价值——因为后者在审计时拿不出任何依据。
决策4: 用版本化的本体设计支持动态更新。公文规范每隔几个月就会更新，我们的本体设计支持版本管理，每个公文条例都关联版本号和生效日期。这样当规范更新时，只需要添加新版本，历史版本的查询结果仍然可以追溯。
本文整理自作者在公文智能化项目中的实战经验。如有问题或讨论，欢迎在评论区交流。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
7
0- 0
已为社区贡献29条内容
所有评论(0)