简介这份资源围绕智慧政策系统的整体架构与落地实现展开面向政府信息化从业者、政策研究人员、企业决策者及NLP与知识图谱方向的技术开发者帮助解决政策文本处理繁琐、信息孤岛严重、政企政策匹配效率低等实际问题。内容涵盖文件智能解析、政策垂直知识库、知识图谱构建、智能问答与咨询、政府端管理五大模块具体涉及paddleOCR、Layoutreader等文档解析技术NER与依存句法分析、TF-IDF与BERTopic关键词提取以及政策实体、主题实体、惠企项目实体和发布、实施、受益等关系的图谱设计并延伸至政策匹配、企业补贴分析、节税计算与区域政策对比等应用场景。资源包共1个docx文件约23KB以方案文档形式系统梳理了产品目标、功能模块与技术选型。目前已有84人学习适合希望理解AI技术如何赋能公共信息服务、并需要完整方案参考的读者研读。1. 智慧政策系统落地文件解析、知识图谱与智能问答怎么串成一条线政策文件一多最先崩掉的不是服务器是检索体验。某地政务信息化团队做过一次内部统计一个处室一年要处理的政策类文件超过 4000 份格式横跨 PDF 扫描件、红头 Word、Excel 附件、甚至图片版通知。企业来问「我这个项目能不能申报技改补贴」窗口人员得先翻文件、再对条款、最后找申报入口平均耗时 20 分钟以上。智慧政策系统要解决的就是这条链路——把文件解析、知识图谱和智能问答三件事串起来让「问一句」直接命中「哪份文件、哪一条、什么条件、怎么报」。这套方案适合两类人一类是正在做政务/园区/企业服务平台的工程师手里有政策文本但不知道怎么结构化另一类是已经上了问答机器人、但回答总是「答非所问」的团队问题多半出在知识图谱没建好、解析层丢字段。下面按「解析→建图→问答→避坑→进阶」的顺序讲每一步都给可复现的做法和参数。2. 文件解析层把 PDF、Word、扫描件统一成结构化条款2.1 为什么不能直接上大模型读全文很多人第一反应是「把政策文件丢给大模型直接问就行」。我试过翻车点很集中一份 30 页的政策 PDF模型能读但条款之间的层级关系章→节→条→款会被压平导致「第十七条第二款」这种精确引用对不上扫描件 OCR 出来的错字会污染后续建图最要命的是政策文件里大量「本通知自发布之日起施行」「详见附件」这类跨文件引用全文塞进上下文根本装不下。所以解析层的目标不是「让模型读懂」而是「产出带层级、带来源、带条款编号的结构化块」。常见做法是先做版面分析再做文本抽取最后做条款切分和字段归一。2.2 用 Python 做版面分析与条款切分的最小实现下面这段代码用 pdfplumber 抽文本、用正则切条款扫描件走 OCR 分支。它不是生产级但能让你在本地半天内跑通一条政策文件的解析链路。import pdfplumber import re from typing import List, Dict # 条款标题正则匹配「第X条」「第X章」「一、」「一」等常见政策编号 CLAUSE_PATTERN re.compile( r(第[一二三四五六七八九十百零\d][章节条款])| r([一二三四五六七八九十]、)| r([一二三四五六七八九十]) ) def extract_text(pdf_path: str) - str: 抽取 PDF 文本扫描件需先走 OCR 再传入 full_text [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: # layoutTrue 保留版面缩进对条款层级判断很关键 text page.extract_text(layoutTrue) if text: full_text.append(text) return \n.join(full_text) def split_clauses(raw_text: str) - List[Dict]: 按条款编号切分保留层级和原文位置 lines raw_text.split(\n) clauses, current [], {title: 前言, content: [], level: 0} for line in lines: line line.strip() if not line: continue match CLAUSE_PATTERN.match(line) if match: # 遇到新条款先把上一条落库 if current[content]: clauses.append(current) current {title: line[:30], content: [line], level: len(match.group(0))} else: current[content].append(line) if current[content]: clauses.append(current) return clauses if __name__ __main__: text extract_text(policy_sample.pdf) for c in split_clauses(text)[:5]: print(c[title], |, .join(c[content])[:60])逻辑说明extract_text里layoutTrue是血泪经验不加这个参数PDF 里的缩进层级全丢后面判断「第X条」属于哪一章就无从谈起。split_clauses用正则匹配条款编号作为切分点level字段记录编号长度用来粗略区分章、节、条。参数上CLAUSE_PATTERN需要按你手里的政策文种调整——有些地方用「第X条」有些用「一、」建议先抽样 20 份文件统计编号样式再定正则。2.3 扫描件 OCR 与字段归一的关键参数扫描件走 OCR 时别直接上通用模型。政策文件多是宋体、红头、表格混排我一般用 PaddleOCR 的ch_PP-OCRv4模型det_db_thresh调到 0.3默认 0.3 左右太低会漏检表格线rec_batch_num设 8 平衡速度和显存。OCR 完必须做后处理把「O」和「0」、「l」和「1」这类混淆字符按上下文替换否则建图时「第十七条」可能变成「第十七奈」。字段归一要做三件事日期统一成YYYY-MM-DD金额统一成「万元」并保留原始表述发文机关、文号、生效日期抽成独立字段。这些字段是后面知识图谱的实体来源解析层丢一个问答层就少一条路。3. 知识图谱构建政策条款怎么变成可查询的实体关系3.1 政策图谱的 schema 设计别照搬通用本体通用知识图谱那套「人-地-事-物」本体放到政策场景里不好用。政策问答的核心关系其实很固定政策文件 → 条款 → 适用条件 → 申报材料 → 办理入口。我一般会定一个最小 schema实体类型关键属性示例虚构政策文件文号、发文机关、生效日期某政发〔2024〕12号条款条款编号、原文、层级第十七条第二款适用条件条件类型、阈值、单位营收≥2000万元申报材料材料名称、份数、格式审计报告1份PDF办理入口系统名称、链接标识某政务服务平台关系上政策文件-包含-条款、条款-要求-适用条件、条款-需要-申报材料、条款-办理-办理入口。这个 schema 的好处是问答时用户问「营收 3000 万能不能报」可以直接在「适用条件」实体上做数值过滤不用让模型去猜。3.2 用规则模型混合抽取三元组纯规则抽三元组在政策文本上召回率不错但遇到「原则上」「一般不低于」这类模糊表述就抓瞎。我的做法是规则打底、模型补漏先用正则和词典抽确定性的文号、日期、金额、材料名再用一个微调过的小模型抽条件类三元组。import re from typing import List, Tuple # 规则抽取金额、比例、日期、材料 MONEY_PATTERN re.compile(r(\d(?:\.\d)?)\s*(万元|亿元|元)) RATIO_PATTERN re.compile(r(\d(?:\.\d)?)\s*%) DATE_PATTERN re.compile(r(\d{4})年(\d{1,2})月(\d{1,2})日) def rule_extract(clause_text: str) - List[Tuple[str, str, str]]: 返回 (头实体, 关系, 尾实体) 三元组列表 triples [] for m in MONEY_PATTERN.finditer(clause_text): # 金额统一转成万元保留原始单位做溯源 value float(m.group(1)) unit m.group(2) if unit 亿元: value * 10000 elif unit 元: value / 10000 triples.append((本条款, 金额阈值, f{value}万元)) for m in RATIO_PATTERN.finditer(clause_text): triples.append((本条款, 比例阈值, f{m.group(1)}%)) for m in DATE_PATTERN.finditer(clause_text): triples.append((本条款, 生效日期, f{m.group(1)}-{m.group(2):02}-{m.group(3):02})) return triples # 模型补漏用少量标注数据微调一个序列标注模型抽「条件-阈值-单位」 # 这里只示意调用接口实际用你团队惯用的 NER 框架 def model_extract(clause_text: str) - List[Tuple[str, str, str]]: # 伪代码加载微调后的 NER 模型识别 CONDITION / THRESHOLD / UNIT # entities ner_model.predict(clause_text) # 组装成三元组返回 return []逻辑说明rule_extract里金额统一转万元是为了后续数值比较DATE_PATTERN的:02保证月份日期补零。模型补漏部分不展开具体框架因为各团队用的 NER 工具不同重点是「规则先跑一遍模型只处理规则没覆盖的句子」这样标注量能压到几百条级别。参数上金额阈值建议保留原始表述字段问答时用户看到「2000万元」比看到「2000」更可信。3.3 图数据库选型与写入Neo4j 还是轻量方案政策图谱的规模通常不大——一个地市的政策文件几千份条款几万条三元组几十万级别。这个量级用 Neo4j 社区版完全够但如果你的系统要嵌入到已有平台里不想多维护一个数据库用 PostgreSQL 邻接表也能扛。我一般这样选需要多跳查询比如「找所有要求审计报告且营收门槛低于 5000 万的政策」就用 Neo4j只是单跳查询和过滤PostgreSQL 足够。写入时注意两点一是条款节点要带source_file和clause_no属性方便溯源二是条件实体上的数值字段要存成数值类型别存字符串否则范围查询会退化成全表扫描。4. 智能问答层从用户提问到条款级答案的完整链路4.1 意图识别与槽位填充先分类再检索用户问「技改补贴怎么申请」和「营收 3000 万能不能报技改补贴」走的是两条路。前者是流程类问题需要返回申报材料、办理入口后者是条件判定类问题需要拿数值去图谱里过滤。所以问答层第一步是意图分类我一般分四类政策查询、条件判定、材料清单、办理流程。意图分类不用上大模型用 FastText 或一个小 BERT 就够训练数据从历史工单里捞几百条标注。槽位填充抽三类政策领域技改、人才、税收、数值条件营收、人数、年限、地区。抽槽位时把数值和单位一起抽出来后面做单位换算。4.2 图谱检索 向量召回的双路融合单靠图谱检索遇到用户表述和政策原文不一致时会漏单靠向量召回又容易召回语义相近但条款不匹配的结果。我的做法是双路并行再融合排序。def hybrid_retrieve(query: str, top_k: int 5): 图谱检索 向量召回融合返回条款列表 # 路 1图谱检索先抽槽位再查 slots extract_slots(query) # 返回 {domain, value, region} graph_results query_graph(slots) # 按 domain 和数值条件过滤条款 # 路 2向量召回用条款原文的 embedding 做相似度 query_vec embed_model.encode(query) vector_results vector_index.search(query_vec, top_k * 2) # 融合图谱结果加权 0.7向量结果加权 0.3按条款 ID 去重 merged {} for r in graph_results: merged[r[clause_id]] merged.get(r[clause_id], 0) 0.7 for r in vector_results: merged[r[clause_id]] merged.get(r[clause_id], 0) 0.3 ranked sorted(merged.items(), keylambda x: -x[1])[:top_k] return [get_clause(cid) for cid, _ in ranked]逻辑说明权重 0.7/0.3 是经验值图谱命中说明槽位匹配可信度高向量召回做兜底。extract_slots里数值条件要转成统一单位再进图谱查询否则「3000万」和「0.3亿」会被当成两个值。参数上top_k建议设 5返回太多条款用户反而不知道看哪条向量召回取top_k * 2是为了给融合留余量。4.3 答案生成让模型只做「翻译」不做「推理」最后一步是把检索到的条款组织成自然语言答案。这里有个原则数值判定和条款匹配由图谱完成模型只负责把结构化结果转成通顺的话。如果让模型自己判断「3000 万够不够」它可能编出一个阈值。我一般用模板 模型润色的方式模板保证关键信息条款编号、原文、条件、材料不丢模型只做语气调整。比如条件判定类问题模板输出「根据《某政策》第十七条第二款申报技改补贴要求营收不低于 2000 万元。您提供的营收为 3000 万元符合该条件。需提交材料审计报告、项目备案表。」模型润色时禁止改动数字和条款编号用后处理校验一遍。5. 避坑与排查政策系统上线后最容易翻车的 5 个点5.1 现象问答结果引用条款编号对不上原文原因解析层切分时把「第十七条」和「第十七条第二款」混成一条或者 OCR 把编号识别错。解决切分后加一步校验用条款编号在原文里反查位置对不上就标记人工复核OCR 结果里编号类字符单独做一次纠错。5.2 现象条件判定类问题回答「符合」但实际不符合原因单位没统一。用户说「营收 3 亿」图谱里存的是「30000 万元」如果槽位抽取没做换算数值比较就错了。解决槽位抽取后强制走单位归一函数所有金额转万元、所有比例转小数再进图谱查询。5.3 现象新政策入库后问答搜不到原因向量索引没更新或者图谱写入事务没提交。解决把「解析→建图→更新索引」做成一个流水线任务每次新文件入库触发全链路索引更新用增量方式别全量重建。5.4 现象用户问「最新政策」返回三年前的原因图谱里生效日期字段缺失或格式不统一排序时把空值排前面了。解决解析层强制抽生效日期抽不到就标「未知」并排最后问答层加时间过滤槽位默认按生效日期倒序。5.5 现象扫描件解析出来的条款全是乱码原因OCR 模型没适配红头文件或者 PDF 本身是图片但没走 OCR 分支。解决解析入口先判断 PDF 是否含文本层不含就走 OCROCR 后做一次字符混淆替换再进切分。6. 进阶技巧用条款级评测集把问答准确率从 70% 拉到 90%这套系统做完怎么知道它好不好别只看「回答得像不像」要建一个条款级评测集。我的做法是从历史工单里抽 200 个真实问题人工标注每个问题的「正确条款 ID」然后跑问答链路看 Top1 和 Top3 命中率。这个评测集建一次后面每次改解析规则、调融合权重、换 embedding 模型都能量化对比。具体操作上我一般分三步。第一步标注 200 条评测数据格式是{query, correct_clause_ids, intent}其中correct_clause_ids可以多个因为有些问题确实对应多条条款。第二步写一个评测脚本跑完输出混淆矩阵和错误案例。第三步针对错误案例分类处理如果是槽位抽取错补标注数据如果是图谱缺关系补抽取规则如果是向量召回错换模型或调权重。这里有个容易被忽略的点评测集要覆盖「否定类」问题。比如「营收 1000 万能不能报」正确答案是「不符合因为门槛是 2000 万」而不是「没找到相关政策」。很多系统在这类问题上翻车因为检索层只做了正向匹配没做条件判定。我的做法是在意图分类里单独加一类「条件否定」走图谱数值比较返回明确的「不符合」加原因。另一个技巧是条款级答案的引用格式统一。不管走哪条检索路径最终答案里必须带「文件名 条款编号 原文摘录」三要素。这样用户能自己核对也方便你排查错误。我见过太多系统回答得挺流畅但用户一问「哪条写的」就露馅。最后说个习惯每次政策文件更新别只跑一遍解析就完事要拿评测集回归一次。政策文本的表述变化很快上个月能抽对的条款这个月可能因为换了个说法就抽错了。把评测集当成回归测试比事后救火省事得多。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源围绕智慧政策系统的整体架构与落地实现展开面向政府信息化从业者、政策研究人员、企业决策者及NLP与知识图谱方向的技术开发者帮助解决政策文本处理繁琐、信息孤岛严重、政企政策匹配效率低等实际问题。内容涵盖文件智能解析、政策垂直知识库、知识图谱构建、智能问答与咨询、政府端管理五大模块具体涉及paddleOCR、Layoutreader等文档解析技术NER与依存句法分析、TF-IDF与BERTopic关键词提取以及政策实体、主题实体、惠企项目实体和发布、实施、受益等关系的图谱设计并延伸至政策匹配、企业补贴分析、节税计算与区域政策对比等应用场景。资源包共1个docx文件约23KB以方案文档形式系统梳理了产品目标、功能模块与技术选型。目前已有84人学习适合希望理解AI技术如何赋能公共信息服务、并需要完整方案参考的读者研读。1. 智慧政策系统落地文件解析、知识图谱与智能问答怎么串成一条线政策文件一多最先崩掉的不是服务器是检索体验。某地政务信息化团队做过一次内部统计一个处室一年要处理的政策类文件超过 4000 份格式横跨 PDF 扫描件、红头 Word、Excel 附件、甚至图片版通知。企业来问「我这个项目能不能申报技改补贴」窗口人员得先翻文件、再对条款、最后找申报入口平均耗时 20 分钟以上。智慧政策系统要解决的就是这条链路——把文件解析、知识图谱和智能问答三件事串起来让「问一句」直接命中「哪份文件、哪一条、什么条件、怎么报」。这套方案适合两类人一类是正在做政务/园区/企业服务平台的工程师手里有政策文本但不知道怎么结构化另一类是已经上了问答机器人、但回答总是「答非所问」的团队问题多半出在知识图谱没建好、解析层丢字段。下面按「解析→建图→问答→避坑→进阶」的顺序讲每一步都给可复现的做法和参数。2. 文件解析层把 PDF、Word、扫描件统一成结构化条款2.1 为什么不能直接上大模型读全文很多人第一反应是「把政策文件丢给大模型直接问就行」。我试过翻车点很集中一份 30 页的政策 PDF模型能读但条款之间的层级关系章→节→条→款会被压平导致「第十七条第二款」这种精确引用对不上扫描件 OCR 出来的错字会污染后续建图最要命的是政策文件里大量「本通知自发布之日起施行」「详见附件」这类跨文件引用全文塞进上下文根本装不下。所以解析层的目标不是「让模型读懂」而是「产出带层级、带来源、带条款编号的结构化块」。常见做法是先做版面分析再做文本抽取最后做条款切分和字段归一。2.2 用 Python 做版面分析与条款切分的最小实现下面这段代码用 pdfplumber 抽文本、用正则切条款扫描件走 OCR 分支。它不是生产级但能让你在本地半天内跑通一条政策文件的解析链路。import pdfplumber import re from typing import List, Dict # 条款标题正则匹配「第X条」「第X章」「一、」「一」等常见政策编号 CLAUSE_PATTERN re.compile( r(第[一二三四五六七八九十百零\d][章节条款])| r([一二三四五六七八九十]、)| r([一二三四五六七八九十]) ) def extract_text(pdf_path: str) - str: 抽取 PDF 文本扫描件需先走 OCR 再传入 full_text [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: # layoutTrue 保留版面缩进对条款层级判断很关键 text page.extract_text(layoutTrue) if text: full_text.append(text) return \n.join(full_text) def split_clauses(raw_text: str) - List[Dict]: 按条款编号切分保留层级和原文位置 lines raw_text.split(\n) clauses, current [], {title: 前言, content: [], level: 0} for line in lines: line line.strip() if not line: continue match CLAUSE_PATTERN.match(line) if match: # 遇到新条款先把上一条落库 if current[content]: clauses.append(current) current {title: line[:30], content: [line], level: len(match.group(0))} else: current[content].append(line) if current[content]: clauses.append(current) return clauses if __name__ __main__: text extract_text(policy_sample.pdf) for c in split_clauses(text)[:5]: print(c[title], |, .join(c[content])[:60])逻辑说明extract_text里layoutTrue是血泪经验不加这个参数PDF 里的缩进层级全丢后面判断「第X条」属于哪一章就无从谈起。split_clauses用正则匹配条款编号作为切分点level字段记录编号长度用来粗略区分章、节、条。参数上CLAUSE_PATTERN需要按你手里的政策文种调整——有些地方用「第X条」有些用「一、」建议先抽样 20 份文件统计编号样式再定正则。2.3 扫描件 OCR 与字段归一的关键参数扫描件走 OCR 时别直接上通用模型。政策文件多是宋体、红头、表格混排我一般用 PaddleOCR 的ch_PP-OCRv4模型det_db_thresh调到 0.3默认 0.3 左右太低会漏检表格线rec_batch_num设 8 平衡速度和显存。OCR 完必须做后处理把「O」和「0」、「l」和「1」这类混淆字符按上下文替换否则建图时「第十七条」可能变成「第十七奈」。字段归一要做三件事日期统一成YYYY-MM-DD金额统一成「万元」并保留原始表述发文机关、文号、生效日期抽成独立字段。这些字段是后面知识图谱的实体来源解析层丢一个问答层就少一条路。3. 知识图谱构建政策条款怎么变成可查询的实体关系3.1 政策图谱的 schema 设计别照搬通用本体通用知识图谱那套「人-地-事-物」本体放到政策场景里不好用。政策问答的核心关系其实很固定政策文件 → 条款 → 适用条件 → 申报材料 → 办理入口。我一般会定一个最小 schema实体类型关键属性示例虚构政策文件文号、发文机关、生效日期某政发〔2024〕12号条款条款编号、原文、层级第十七条第二款适用条件条件类型、阈值、单位营收≥2000万元申报材料材料名称、份数、格式审计报告1份PDF办理入口系统名称、链接标识某政务服务平台关系上政策文件-包含-条款、条款-要求-适用条件、条款-需要-申报材料、条款-办理-办理入口。这个 schema 的好处是问答时用户问「营收 3000 万能不能报」可以直接在「适用条件」实体上做数值过滤不用让模型去猜。3.2 用规则模型混合抽取三元组纯规则抽三元组在政策文本上召回率不错但遇到「原则上」「一般不低于」这类模糊表述就抓瞎。我的做法是规则打底、模型补漏先用正则和词典抽确定性的文号、日期、金额、材料名再用一个微调过的小模型抽条件类三元组。import re from typing import List, Tuple # 规则抽取金额、比例、日期、材料 MONEY_PATTERN re.compile(r(\d(?:\.\d)?)\s*(万元|亿元|元)) RATIO_PATTERN re.compile(r(\d(?:\.\d)?)\s*%) DATE_PATTERN re.compile(r(\d{4})年(\d{1,2})月(\d{1,2})日) def rule_extract(clause_text: str) - List[Tuple[str, str, str]]: 返回 (头实体, 关系, 尾实体) 三元组列表 triples [] for m in MONEY_PATTERN.finditer(clause_text): # 金额统一转成万元保留原始单位做溯源 value float(m.group(1)) unit m.group(2) if unit 亿元: value * 10000 elif unit 元: value / 10000 triples.append((本条款, 金额阈值, f{value}万元)) for m in RATIO_PATTERN.finditer(clause_text): triples.append((本条款, 比例阈值, f{m.group(1)}%)) for m in DATE_PATTERN.finditer(clause_text): triples.append((本条款, 生效日期, f{m.group(1)}-{m.group(2):02}-{m.group(3):02})) return triples # 模型补漏用少量标注数据微调一个序列标注模型抽「条件-阈值-单位」 # 这里只示意调用接口实际用你团队惯用的 NER 框架 def model_extract(clause_text: str) - List[Tuple[str, str, str]]: # 伪代码加载微调后的 NER 模型识别 CONDITION / THRESHOLD / UNIT # entities ner_model.predict(clause_text) # 组装成三元组返回 return []逻辑说明rule_extract里金额统一转万元是为了后续数值比较DATE_PATTERN的:02保证月份日期补零。模型补漏部分不展开具体框架因为各团队用的 NER 工具不同重点是「规则先跑一遍模型只处理规则没覆盖的句子」这样标注量能压到几百条级别。参数上金额阈值建议保留原始表述字段问答时用户看到「2000万元」比看到「2000」更可信。3.3 图数据库选型与写入Neo4j 还是轻量方案政策图谱的规模通常不大——一个地市的政策文件几千份条款几万条三元组几十万级别。这个量级用 Neo4j 社区版完全够但如果你的系统要嵌入到已有平台里不想多维护一个数据库用 PostgreSQL 邻接表也能扛。我一般这样选需要多跳查询比如「找所有要求审计报告且营收门槛低于 5000 万的政策」就用 Neo4j只是单跳查询和过滤PostgreSQL 足够。写入时注意两点一是条款节点要带source_file和clause_no属性方便溯源二是条件实体上的数值字段要存成数值类型别存字符串否则范围查询会退化成全表扫描。4. 智能问答层从用户提问到条款级答案的完整链路4.1 意图识别与槽位填充先分类再检索用户问「技改补贴怎么申请」和「营收 3000 万能不能报技改补贴」走的是两条路。前者是流程类问题需要返回申报材料、办理入口后者是条件判定类问题需要拿数值去图谱里过滤。所以问答层第一步是意图分类我一般分四类政策查询、条件判定、材料清单、办理流程。意图分类不用上大模型用 FastText 或一个小 BERT 就够训练数据从历史工单里捞几百条标注。槽位填充抽三类政策领域技改、人才、税收、数值条件营收、人数、年限、地区。抽槽位时把数值和单位一起抽出来后面做单位换算。4.2 图谱检索 向量召回的双路融合单靠图谱检索遇到用户表述和政策原文不一致时会漏单靠向量召回又容易召回语义相近但条款不匹配的结果。我的做法是双路并行再融合排序。def hybrid_retrieve(query: str, top_k: int 5): 图谱检索 向量召回融合返回条款列表 # 路 1图谱检索先抽槽位再查 slots extract_slots(query) # 返回 {domain, value, region} graph_results query_graph(slots) # 按 domain 和数值条件过滤条款 # 路 2向量召回用条款原文的 embedding 做相似度 query_vec embed_model.encode(query) vector_results vector_index.search(query_vec, top_k * 2) # 融合图谱结果加权 0.7向量结果加权 0.3按条款 ID 去重 merged {} for r in graph_results: merged[r[clause_id]] merged.get(r[clause_id], 0) 0.7 for r in vector_results: merged[r[clause_id]] merged.get(r[clause_id], 0) 0.3 ranked sorted(merged.items(), keylambda x: -x[1])[:top_k] return [get_clause(cid) for cid, _ in ranked]逻辑说明权重 0.7/0.3 是经验值图谱命中说明槽位匹配可信度高向量召回做兜底。extract_slots里数值条件要转成统一单位再进图谱查询否则「3000万」和「0.3亿」会被当成两个值。参数上top_k建议设 5返回太多条款用户反而不知道看哪条向量召回取top_k * 2是为了给融合留余量。4.3 答案生成让模型只做「翻译」不做「推理」最后一步是把检索到的条款组织成自然语言答案。这里有个原则数值判定和条款匹配由图谱完成模型只负责把结构化结果转成通顺的话。如果让模型自己判断「3000 万够不够」它可能编出一个阈值。我一般用模板 模型润色的方式模板保证关键信息条款编号、原文、条件、材料不丢模型只做语气调整。比如条件判定类问题模板输出「根据《某政策》第十七条第二款申报技改补贴要求营收不低于 2000 万元。您提供的营收为 3000 万元符合该条件。需提交材料审计报告、项目备案表。」模型润色时禁止改动数字和条款编号用后处理校验一遍。5. 避坑与排查政策系统上线后最容易翻车的 5 个点5.1 现象问答结果引用条款编号对不上原文原因解析层切分时把「第十七条」和「第十七条第二款」混成一条或者 OCR 把编号识别错。解决切分后加一步校验用条款编号在原文里反查位置对不上就标记人工复核OCR 结果里编号类字符单独做一次纠错。5.2 现象条件判定类问题回答「符合」但实际不符合原因单位没统一。用户说「营收 3 亿」图谱里存的是「30000 万元」如果槽位抽取没做换算数值比较就错了。解决槽位抽取后强制走单位归一函数所有金额转万元、所有比例转小数再进图谱查询。5.3 现象新政策入库后问答搜不到原因向量索引没更新或者图谱写入事务没提交。解决把「解析→建图→更新索引」做成一个流水线任务每次新文件入库触发全链路索引更新用增量方式别全量重建。5.4 现象用户问「最新政策」返回三年前的原因图谱里生效日期字段缺失或格式不统一排序时把空值排前面了。解决解析层强制抽生效日期抽不到就标「未知」并排最后问答层加时间过滤槽位默认按生效日期倒序。5.5 现象扫描件解析出来的条款全是乱码原因OCR 模型没适配红头文件或者 PDF 本身是图片但没走 OCR 分支。解决解析入口先判断 PDF 是否含文本层不含就走 OCROCR 后做一次字符混淆替换再进切分。6. 进阶技巧用条款级评测集把问答准确率从 70% 拉到 90%这套系统做完怎么知道它好不好别只看「回答得像不像」要建一个条款级评测集。我的做法是从历史工单里抽 200 个真实问题人工标注每个问题的「正确条款 ID」然后跑问答链路看 Top1 和 Top3 命中率。这个评测集建一次后面每次改解析规则、调融合权重、换 embedding 模型都能量化对比。具体操作上我一般分三步。第一步标注 200 条评测数据格式是{query, correct_clause_ids, intent}其中correct_clause_ids可以多个因为有些问题确实对应多条条款。第二步写一个评测脚本跑完输出混淆矩阵和错误案例。第三步针对错误案例分类处理如果是槽位抽取错补标注数据如果是图谱缺关系补抽取规则如果是向量召回错换模型或调权重。这里有个容易被忽略的点评测集要覆盖「否定类」问题。比如「营收 1000 万能不能报」正确答案是「不符合因为门槛是 2000 万」而不是「没找到相关政策」。很多系统在这类问题上翻车因为检索层只做了正向匹配没做条件判定。我的做法是在意图分类里单独加一类「条件否定」走图谱数值比较返回明确的「不符合」加原因。另一个技巧是条款级答案的引用格式统一。不管走哪条检索路径最终答案里必须带「文件名 条款编号 原文摘录」三要素。这样用户能自己核对也方便你排查错误。我见过太多系统回答得挺流畅但用户一问「哪条写的」就露馅。最后说个习惯每次政策文件更新别只跑一遍解析就完事要拿评测集回归一次。政策文本的表述变化很快上个月能抽对的条款这个月可能因为换了个说法就抽错了。把评测集当成回归测试比事后救火省事得多。希望帮到你。本文还有配套的精品资源点击获取
