# OCR_Project

**Repository Path**: diligentxiaozhe/OCR_Project

## Basic Information

- **Project Name**: OCR_Project
- **Description**: 基于OCR实现的图片识别及自动生成信息录入，及知识图谱构建与智能问答
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2025-08-21
- **Last Updated**: 2026-06-15

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

非遗工艺品 OCR 与知识图谱系统
本项目实现了一个面向非物质文化遗产 / 传统工艺品的端到端系统，完整打通：
图片表单 → OCR → 结构化表单 → 文本摘要 → 三元组抽取 → Neo4j 知识图谱 → 图谱可视化 → 基于图谱的 AI 问答。
该系统既可作为实际业务工具，也可以作为论文 / 毕业设计中的实验平台，用于验证“非遗信息数字化 + 知识图谱 + 大模型”的一体化方案。
1. 项目背景与目标
1.1 背景
传统非物质文化遗产（如手工艺、民俗技艺）的大量信息仍以纸质表格、档案资料形式存在，信息分散、难以检索和挖掘。与此同时：
OCR 技术可以较好地识别表格类图片；
图数据库（Neo4j）适合表达复杂关系网络；
大语言模型（LLM）在文本理解与结构化抽取方面具有明显优势。
将这三者结合，可以构建面向非遗工艺品的知识图谱系统，为后续的分析、展示与问答提供统一的语义底座。
1.2 项目目标
信息采集自动化：从上传的工艺品说明表单图片中，自动识别并生成可编辑的电子表单。
知识统一表示：将表单信息转为自然语言描述，再抽取出三元组写入 Neo4j，构建以工艺品为中心的知识图谱。
可视化与交互：通过 Web 前端直观展示图谱结构，支持拖拽、缩放、居中、下载等交互。
语义问答能力：基于知识图谱实现限定域内的 QA，回答如“主要材料是什么”“产地在哪”等问题，并在图上高亮相关节点和边。
论文支撑：为“非遗数字化”“知识图谱+大模型”“多源异构数据融合”等研究方向提供可复现的系统原型。
2. 系统架构概览
2.1 总体架构
系统采用典型的 前后端一体 Flask Web 应用，底层依赖三个外部服务：
MongoDB：存储表单原始 JSON 与 LLM 生成的文本描述；
Neo4j：存储知识图谱（节点与关系）；
Ollama + deepseek-r1:7b：本地大语言模型推理服务。
主要模块：
前端 UI
templates/index.html + static/css/index_style.css + static/js/index.js
templates/results.html
templates/kg_visualization.html + static/css/kg_style.css + static/js/kg_visualization.js
后端 Flask
app.py：路由与业务编排
数据访问层（DAO）
dao/mdb_json.py、dao/mdb_text.py：MongoDB 访问
dao/neo4j_dao.py：Neo4j 访问
智能处理模块
utils/Generate_text.py：表单 JSON → 描述性文本
utils/Triple_Extractor.py：文本 → 三元组抽取
2.2 数据流（高层流程）
图片上传
用户在首页上传工艺品信息表图片 → 后端 /upload 保存图片并调用 PaddleX 进行表格识别 → 生成 Excel。
表单生成与编辑
Excel 转为结构化 JSON → 存入 session → 渲染 results.html 表单 → 用户编辑 / 修正。
表单保存与知识图谱构建
前端提交表单 JSON 至 /saveData：
保存 JSON 至 MongoDB；
使用 LLM 将 JSON 转写为说明文本；
再用 LLM 从文本中抽取三元组；
调用 Neo4j DAO 将三元组写入图数据库。
图谱查询与可视化
用户在 /kg_visualization 页面选择或输入工艺品名（来自 MongoDB Description_Text.id）；
前端调用 /generate_kg，从 Neo4j 读取图数据；
前端 vis-network 渲染知识图谱。
基于图谱的 AI 问答
用户在图谱下方输入问题；
前端调用 /kg_qa，后端基于图谱上下文调用 LLM 生成回答，同时生成需要高亮的节点/边；
前端展示回答气泡，并在图上高亮相关部分。
3. 关键模块与算法设计
3.1 表格 OCR 与表单生成
使用 PaddleX 的 table_recognition pipeline：
输入：上传图片路径；
输出：带有表格结构的 Excel 文件。
在 app.py 的 handle(save_path) 中调用：
对每张图片生成对应的 *_table_1.xlsx；
再通过 get_data() 读取 Excel，并按“一级分类 / 二级字段 / 值”的方式解析为嵌套字典。
最终得到的 JSON 结构被送到前端 results.html，生成动态表单，便于用户校对和补充。
3.2 文本生成（JSON → 描述性文本）
文件：utils/Generate_text.py
输入：
结构化表单 JSON json_data。
处理：
使用 json.dumps(..., ensure_ascii=False, indent=2) 将其序列化为可读的 JSON 字符串；
调用 Ollama：
    response = chat(        model="deepseek-r1:7b",        messages=[            {"role": "system", "content": "...文化工艺品描述助手..."},            {"role": "user", "content": "...请将以下JSON转换为描述性文本..."},        ],    )
输出：
一段紧凑、结构清晰的中文文本，为三元组抽取提供更自然的输入。
研究角度：此模块可以对比不同提示词、不同 LLM，评估对后续三元组质量的影响。
3.3 三元组抽取（文本 → 结构化知识）
文件：utils/Triple_Extractor.py
核心思路：
使用 同一个 LLM，但换一套提示词，直接让模型生成多条三元组的 JSON 列表；
提示中强调：
尽可能覆盖文本中的所有事实；
若事实与目标工艺品有关，优先使用工艺品名作为主体；
输出为纯 JSON 数组，前 3 个字段依次为（主体、关系、客体），字段名可自定义。
解析策略：
将模型输出清洗掉可能出现的
  - `json.loads(content)` 转为 Python 列表；  - 对每个 dict：    - 取前三个 `(key, value)` 作为 `(subject, predicate, object)`；    - 统一包装为：      {          "subject": subj,          "subject_type": "Concept",          "predicate": pred,          "relation_type": "RELATED_TO",          "object": obj,          "object_type": "Concept",      }     
在当前版本中，实体类型与关系类型统一先设为 Concept / RELATED_TO，便于后续扩展。
研究角度：可在此处增加多分类器或规则自动识别实体类型/关系类型，或引入 schema-guided prompt。
3.4 知识图谱模式设计（Neo4j）
文件：dao/neo4j_dao.py
实体标签（节点 Label）：
Craft：工艺品本体；
Material：材料；
Technique：制作工艺/技法；
Place：地点、产地；
Category：类别；
Concept：其他概念或默认归类。
关系类型（Relationship Type）：
USES_MATERIAL：使用某种材料；
USES_TECHNIQUE：使用某种技法；
ORIGINATES_FROM：起源/产地；
BELONGS_TO_CATEGORY：属于某一类别；
HAS_USAGE：用途相关；
RELATED_TO：泛化关系。
写入逻辑（save_triples()）：
对每条三元组：
使用 _normalize_entity_label() 与 _normalize_relation_type() 限制 Label 与关系类型在白名单内；
使用 MERGE 保证节点去重：
      MERGE (s:SubjectLabel {name: $subject})      MERGE (o:ObjectLabel {name: $object})      MERGE (s)-[r:RELATION_TYPE {craft: $craft, predicate: $predicate}]->(o)
在写入前，先清理该工艺品所有旧关系，防止重复与“脏图谱”。
读取逻辑（get_graph_data()）：
MATCH (s)-[r {craft: $craft}]->(o) 查询指定工艺的所有边；
为每个不同的 s.name / o.name 分配一个 node id（如 n1、n2）；
输出统一结构：
    {      "nodes": [        {"id": "n1", "label": "...", "group": "Craft", "importance": 1.0},        ...      ],      "edges": [        {"id": "e1", "from": "n1", "to": "n2", "label": "关系文本", "type": "USES_MATERIAL"},        ...      ]    }
3.5 图谱可视化与交互（vis-network）
文件：static/js/kg_visualization.js + templates/kg_visualization.html
使用 vis-network 绘制节点-边图：
通过 nodes = new vis.DataSet([]) / edges = new vis.DataSet([]) 维护数据；
每次查询新工艺品时重置数据集并添加新元素；
配置 physics 使节点以力导向方式自动排布；
在 displayGraph() 中等待网络稳定后执行一次 fit + moveTo，让初次显示即居中、带合理边距。
交互功能：
「查看图谱」搜索框支持：
从 /kg_crafts 拉取所有历史工艺名称（MongoDB Description_Text.id）；
下拉列表展示所有工艺名称；
输入关键字做前端模糊过滤，点击即填充搜索框。
视图控制按钮：
重置视图：network.fit()；
下载图谱：将画布 toDataURL 后保存为 PNG；
全屏：切换容器的 fullscreen 模式。
3.6 基于图谱的 QA 与高亮机制
文件：app.py 中的 /kg_qa 与 generate_kg_based_answer()，以及前端 static/js/kg_visualization.js 内的 AI QA 逻辑。
后端：
根据工艺名从 Neo4j 读取完整图数据；
使用 extract_kg_context(nodes, edges, craft_name)：
将节点以「名称（类型）」列表形式串联为【实体和概念】段；
将边以「主体 -[关系]-> 客体」形式串联为【关系信息】段；
构造 system + user prompt，将上述上下文作为唯一本体知识；
调用 deepseek-r1:7b 生成不超过 50 字的回答；
使用 find_highlight_elements(question, answer, nodes, edges)：
基于字符串匹配或简单启发式，从问题与回答中找出涉及的实体名和关系词；
映射到 node_ids 与 edge_ids；
返回 {"node_ids": [...], "edge_ids": [...]}。
前端：
在问答成功回调中：
添加问答气泡；
调用 highlightGraph(highlights)：
恢复上一次高亮（clearHighlights()）；
对指定节点/边修改 color、borderWidth、size 等属性，形成明显高亮；
调用 network.fit({ nodes: highlightedNodeIds, animation: ... }) 自动聚焦到相关子图。
4. 数据库与存储设计
4.1 MongoDB
数据库：Cultural_Heritage
主要集合：
Description_Text
字段：
id：工艺品名称（作为统一关键字，与 Neo4j 中 craft 字段一致）；
text：LLM 生成的描述性文本；
metadata：语言、来源等辅助信息。
其他集合（如用于保存原始 JSON）的结构可在 dao/mdb_json.py 中查看。
4.2 Neo4j
节点属性：
:Craft {name}
:Material {name}
:Technique {name}
:Place {name}
:Category {name}
:Concept {name}
关系属性：
:REL {craft, predicate}，其中 REL 为 USES_MATERIAL 等；
craft 用于区分属于哪一张工艺品图谱；
predicate 保存原始关系描述文本。
5. 运行与部署
5.1 环境要求
操作系统：Windows / Linux / macOS
Python：3.9+
数据库：
MongoDB（本地或远程）
Neo4j（建议 5.x）
LLM 推理服务：Ollama，已拉取 deepseek-r1:7b 模型
5.2 安装依赖
cd OCR_Project_2python -m venv venv# Windowsvenv\Scripts\activate# Linux / macOS# source venv/bin/activatepip install -r requirements.txt
5.3 服务启动顺序
启动 MongoDB 服务；
启动 Neo4j 服务，并确认账号密码与 dao/neo4j_dao.py 一致；
启动 Ollama，并确保 deepseek-r1:7b 已下载；
启动 Flask 应用：
python app.py# 默认监听 http://localhost:5000/
6. 论文撰写建议与可扩展实验
这一节是专门为后续论文准备的，你可以直接引用或进一步扩展。
6.1 可选研究问题（RQ）
RQ1：表单 OCR + LLM 转写的组合，能否显著降低非遗工艺品信息录入成本？
RQ2：在特定提示词约束下，LLM 抽取的三元组在完整性与准确率上表现如何？
RQ3：以工艺品为中心的知识图谱结构，是否有利于发现材料、技法、空间分布等多维关系？
RQ4：基于知识图谱的 QA（严格限定只用图谱事实）在可解释性和控 hallucination方面有哪些优势？
6.2 论文章节结构（建议）
第 1 章 绪论
非遗数字化现状与痛点；
知识图谱与大模型结合的研究进展；
本文工作与贡献概述（对应本系统）。
第 2 章 相关技术与基础
OCR 与表格识别技术（PaddleX 简要原理）；
知识图谱与图数据库（Neo4j）；
大语言模型与提示工程；
相关工作综述。
第 3 章 系统整体设计
系统架构图（可根据本 README 制作）；
数据流与模块划分；
数据库与知识图谱 schema 设计。
第 4 章 关键算法与实现
JSON → 文本转换策略与 prompt 设计；
文本 → 三元组抽取算法与解析策略；
图谱可视化与高亮联动机制；
基于图谱的 QA pipeline。
第 5 章 实验与评估
实验数据说明（若有真实非遗档案可描述来源与规模）；
OCR 识别准确率与表单结构还原情况；
三元组抽取实验（与人工标注对比）；
QA 准确率与用户体验调研；
案例分析：以某一具体工艺（如“工艺装饰画（原木拼贴画）”）为例展示完整流程。
第 6 章 总结与展望
总结系统实现与实验结果；
展望扩展方向：更多实体类型、时空关系建模、跨工艺品对比分析等。
6.3 可扩展的改进方向
知识增强：在三元组抽取阶段引入规则库或命名实体识别（NER），提高实体类型标注质量。
跨模态扩展：将工艺品图片本身的视觉特征纳入知识图谱（如风格、图案特征）。
图分析与推荐：利用图算法（PageRank、社区发现）做“相似工艺推荐”“关键材料/技法挖掘”。
多语言支持：在 LLM 提示中支持多语言输出，为跨语种非遗传播提供支撑。
7. 结语
本项目从实际业务需求出发，贯通了OCR → 结构化 → LLM 文本生成 → 三元组抽取 → 图数据库 → 图谱可视化与问答的一整套 pipeline。
它既是一个可以“跑起来”的工程系统，也为论文工作提供了可复现、可扩展的实验平台。
如果你后续在某一部分（如三元组抽取、QA 策略、图谱 schema）上做了改进，可以在 README 的对应章节补充“改进点说明”和“实验结果摘要”，使工程与论文形成良好闭环。