拓十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

基于RAG的制造业设备维修问答系统设计毕业设计(源码+lw+部署文档+讲解等)

基于RAG的制造业设备维修问答系统设计毕业设计(源码+lw+部署文档+讲解等)

博主介绍:✌ 专注于VUE,小程序,安卓,Java,python,物联网专业,有18年开发经验,长年从事毕业指导,项目实战✌选取一个适合的毕业设计题目很重要。✌关注✌私信我✌具体的问题,我会尽力帮助你。

一、研究目的

本研究旨在构建一套基于检索增强生成(Retrieval-Augmented Generation,RAG)技术的制造业设备维修问答系统,以提升设备维护效率与决策质量。制造业设备的运行状态复杂多变,传统的维护知识库往往缺乏实时性与可扩展性,导致维修人员在故障诊断与处理过程中耗时过长、错误率偏高。通过将RAG模型与工业现场数据相结合,本研究计划实现对海量设备日志、维修手册、技术文档的高效检索,并在此基础上生成符合实际场景的答案,从而为维修人员提供即时、准确且可解释的技术支持。

研究目标包括:首先,设计并实现一种针对制造业设备维护语料的知识库构建方法,能够自动抽取、归类并标注设备故障描述、维修步骤及其依赖关系;其次,构建一种适配工业文本特点的检索模型,使得在海量非结构化文本中快速定位与查询相关信息;再次,研发一种基于Transformer的生成模型,能够在检索结果基础上生成符合技术规范且易于理解的维修建议;最后,完成系统集成与性能评估,通过真实工况数据验证系统在准确率、响应速度、可解释性等方面的优势。通过上述目标的实现,本研究期望为制造业设备维护提供一种高效、智能且可持续发展的技术方案,从而降低停机成本、提升设备利用率,并为工业人工智能应用提供新的研究思路与实践路径。

二、研究意义

本研究的意义主要体现在技术创新、产业升级与社会价值三方面。首先,技术创新层面,本研究通过将检索增强生成(RAG)模型与制造业设备维护知识库相结合,突破了传统单一检索或单一生成系统的局限性,实现了信息检索与文本生成的深度融合,从而在保持高检索精度的同时提升答案生成的语义连贯性与专业准确性。其次,产业升级层面,该问答系统能够显著降低设备停机时间与维护成本,提升维修人员对复杂故障的诊断效率与决策质量,为制造企业实现数字化、智能化转型提供了关键技术支撑。再次,社会价值层面,通过提升设备可靠性与维护效率,可减少能源浪费与环境污染,促进绿色制造的发展,同时为工业人才培养提供了新的学习与实践平台。综上所述,本研究不仅在人工智能领域提出了一种创新的模型架构,也在制造业实际应用中展现出显著的经济与社会效益,具有重要的理论价值与广泛的推广前景。

三、国内外研究现状

国内外研究现状显示,制造业设备维护领域正经历从传统经验型维护向智能化、数据驱动维护的深刻转变。国际上,学术界与工业界已聚焦于构建基于知识图谱、深度检索与生成模型的问答系统,以实现对海量技术文档和现场日志的实时查询与智能推理。早期研究主要采用基于关键字检索的BM25模型,随后出现了语义检索方法如Dense Passage Retrieval(DPR)和ColBERT,显著提升了检索召回率与相关性。与此同时,自然语言生成领域的发展推动了Transformer系列模型的广泛应用,GPT、T5、BART等大规模预训练模型在技术问答任务中表现出色,但其缺乏对专业领域知识的精准引用,导致生成答案在专业性与可解释性方面存在不足。为此,检索增强生成(RAG)框架被提出,将检索模块与生成模块有机结合,使模型能够在检索到的文档片段基础上生成更符合事实的答案。RAG在通用问答数据集如Natural Questions、TriviaQA等上取得了显著提升,并被工业界用于客服、技术支持等场景。

在制造业设备维护方面,国外研究聚焦于基于深度学习的故障诊断与预测模型,如使用卷积神经网络对振动信号进行特征提取,或利用循环神经网络对时间序列日志进行异常检测。与此同时,一些实验室与企业合作开发了基于知识图谱的维护决策支持系统,能够将设备状态、维修历史与技术规范关联,提供可视化的诊断路径。然而,这些系统往往采用静态知识库或手工构建的规则,缺乏对新出现故障模式的自适应学习能力。近年,一些研究尝试将检索增强生成技术引入工业问答场景,例如在德国西门子公司内部部署的“Digital Twin”平台中使用RAG模型对设备运行日志进行检索,并生成维护建议;在美国GE Digital的Predix平台上,研究人员结合知识图谱与RAG实现了对复杂设备故障的自动诊断与维修方案生成。

国内研究起步相对较晚,但发展迅速。中国学术界在智能制造与工业互联网领域投入大量资源,涌现出多项基于深度学习的设备状态监测与故障诊断技术。国内高校与科研院所多采用卷积神经网络、长短时记忆网络以及图卷积网络对振动、温度、电流等传感器数据进行特征提取与异常检测,取得了较高的准确率。与此同时,一些企业如华为、阿里巴巴、腾讯及海尔集团等,在工业大数据平台上构建了技术文档与维修日志的知识库,并尝试将自然语言处理技术应用于故障问答。值得关注的是,阿里云在2022年发布的“智修云”平台,采用了基于BERT的检索模型结合微调后的生成模型,为制造企业提供了在线设备维修问答服务。该系统通过对海量维修手册、工艺规范与现场日志进行语义匹配,能够在数秒内给出多条可行的维修方案,并支持多语言交互。

总体而言,国内外研究主要集中于三大方向:一是知识库构建与管理,强调对设备维护文档、维修记录及技术规范的结构化与标准化;二是检索技术的提升,涵盖基于向量检索的语义匹配方法,以提高信息召回率和相关性;三是生成模型的专业化,聚焦在如何在检索结果基础上生成符合技术规范、可解释且可操作的答案。尽管已有多项成果,但仍存在知识库更新滞后、检索召回与生成质量难以同步提升、以及缺乏对多模态数据(如视频、图像)的有效融合等挑战。未来研究需要进一步探索知识图谱与检索增强生成的深度耦合机制,提升系统的自适应学习能力与可解释性,以满足制造业设备维护对实时性、准确性与可操作性的高要求。

四、预期达到目标及解决的关键问题

预期目标主要包括构建一套可在制造业现场环境下稳定运行的问答系统、实现知识库的自动化更新与维护、提升检索与生成模块的协同效能,并最终验证系统在实际维修场景中的经济与技术价值。具体而言,首先通过对设备日志、维修手册、技术规范等多源文本进行结构化抽取与语义标注,构建覆盖常见故障类型、诊断流程与维修方案的知识图谱;其次,在检索层面采用基于向量检索的混合模型,结合BM25与Dense Retrieval技术,以提升召回率与精确度;再次,在生成层面利用Transformer架构,并在检索结果上进行微调,使生成文本在专业性、可解释性与可操作性方面达到工业标准;第四,通过多轮对话机制和用户反馈循环,持续优化模型参数,实现自适应学习;最后,通过与制造企业合作的真实工况实验,评估系统在故障诊断准确率、响应时间、维修成本降低等指标上的表现,并形成可复制的部署方案。

关键问题主要集中在知识库构建与更新、检索召回与生成质量耦合、以及系统可解释性与安全性三方面。知识库构建方面,如何高效地从非结构化文本中抽取设备故障模式与维修步骤,并对新出现的技术文档进行及时补充,是实现系统持续可靠运行的前提;检索召回与生成质量耦合问题则涉及到检索模块返回结果的相关性与生成模块对检索上下文的利用程度,如何在保证召回率的同时避免冗余信息干扰生成,是提升答案准确性的关键;系统可解释性与安全性问题包括在生成答案时提供出处说明、风险评估与决策依据,并确保模型不输出误导性或未经验证的维修建议,以满足制造业对安全与合规性的严格要求。解决上述关键问题,将为制造业设备维修问答系统的实际落地奠定坚实基础。

五、研究内容

本研究围绕制造业设备维修问答系统的端到端实现展开,整体研究内容可分为数据采集与预处理、知识图谱构建、检索增强生成模型设计、系统集成与优化以及实验评估五大模块。首先,在数据采集与预处理阶段,将从企业内部维护数据库、设备日志系统、技术手册以及公开的行业标准文档中获取多源文本资料;随后对原始文本进行清洗、分词、命名实体识别与关系抽取,并利用领域专家标注的语料库对关键术语进行统一规范,以构建高质量的语义表示。其次,知识图谱构建模块将基于抽取的实体与关系,采用RDF或Neo4j等图数据库技术,将设备类型、故障特征、诊断步骤、维修方案等多维度信息映射为节点与边;通过引入本体化约束与版本控制机制,实现知识图谱的可扩展性与可维护性。随后,检索增强生成模型设计阶段将首先搭建混合检索框架,融合BM25词频检索与Dense Passage Retrieval向量检索,以兼顾召回率与语义匹配精度;在生成层面,将采用预训练的Transformer模型(如T5或BART)进行微调,并在检索结果上实施上下文聚合策略,使生成模块能够充分利用检索到的技术文档片段,输出专业、可执行的维修建议。系统集成与优化模块将把上述组件通过RESTful API或gRPC接口进行耦合,构建多轮对话框架,并嵌入用户反馈回路,以实现模型的持续学习与性能提升;同时,将在系统中加入可解释性模块,输出答案来源与推理路径,以满足制造业对安全性与可追溯性的要求。最后,实验评估阶段将通过与合作企业现场部署的方式,收集真实维修任务数据,对系统在准确率、召回率、响应时间、维修成本降低等指标进行量化评估,并与传统检索或基于规则的问答系统进行对比,以验证本研究方法的有效性与实用价值。整个研究过程将遵循严谨的实验设计与统计分析方法,确保结果的可靠性与可重复性。

六、需求分析

用户需求方面,制造业设备维修人员在日常工作中面临设备故障频发、技术文档繁杂、现场信息获取受限等挑战。首先,他们需要一种能够快速检索到与当前故障相关的技术文档、维修手册以及历史维修记录的工具,以缩短诊断时间并降低误诊率;其次,鉴于设备环境多样且工作节奏快,用户期望系统能够在有限的操作界面内提供清晰、可执行的维修步骤,并对每一步骤给出必要的安全提示与风险评估;再次,现场工况往往缺乏网络覆盖或电源不稳,用户需要系统支持离线缓存与本地推理,以保证在断网环境下仍能正常使用;此外,制造业设备多为多语言或跨国合作项目,用户期望系统能够支持中英文双语交互,并能根据不同地区的标准与规范自动调整答案的技术细节;最后,维修人员对系统输出结果的可解释性有较高要求,他们希望能够追溯答案来源、查看相关文档片段,并对生成内容进行人工审核或修改,以确保维修决策的可靠性与合规性。

功能需求方面,系统必须实现多模态知识库管理模块,支持文本、图像以及视频资料的统一存储与检索,并通过实体识别与关系抽取技术构建设备故障知识图谱;检索增强生成模块需集成混合检索引擎,在BM25词频检索与Dense Passage Retrieval向量检索之间实现动态权重调节,以兼顾召回率与语义匹配精度;生成模块基于Transformer架构,能够在检索结果上下文中生成专业、可执行的维修建议,并附带出处说明与风险评估,满足可解释性需求;对话管理层面需支持多轮交互与用户反馈收集机制,以实现模型的持续学习与性能优化;系统接口设计应提供RESTful API或gRPC服务,方便与MES、SCADA等企业信息系统无缝集成,同时在前端提供简洁的聊天式界面,支持文本输入、语音识别与离线缓存功能;安全与合规模块需实现用户身份认证、权限控制、数据加密存储,并符合ISO/IEC 27001等信息安全标准;性能指标方面,检索模块的召回率需达到95%以上,生成模块的准确率与可执行性评估分数需超过90%,系统整体响应时间不超过两秒,以满足现场工况下的实时性要求。

七、可行性分析

经济可行性方面,本系统的开发与部署成本主要集中在数据采集与预处理、模型训练与微调、以及后期维护与升级。通过利用已有的企业内部日志和公开技术文档,可大幅降低数据获取费用;而采用开源Transformer模型并在企业服务器上进行微调,能够显著减少对昂贵GPU资源的依赖,从而降低硬件投入。系统上线后,维修人员因故障诊断时间缩短、错误率下降,能够提升设备可用率并减少停机成本;根据行业报告显示,智能问答系统在制造业中的平均投资回报期通常为12至18个月,且长期维护费用相对较低。综上所述,从成本投入与收益预期来看,本项目具备良好的经济可行性。

社会可行性方面,制造业设备维修问答系统的推广将提升行业整体技术水平与人才素质。通过提供标准化、可追溯的维修建议,能够降低因技术不熟练导致的安全事故风险,从而符合国家对工业安全的监管要求;同时,该系统能够支持多语言交互,为跨国制造企业提供便利,促进全球技术协同与知识共享。社会责任层面,系统实现了对维修过程的可解释性与可追溯性,满足工伤事故调查与合规审计需求,有助于提升行业透明度与公众信任。因而,从社会效益和监管合规的角度,本项目具备较高的社会可行性。

技术可行性方面,系统所依赖的检索增强生成技术已在自然语言处理领域得到充分验证,相关模型如BERT、T5、BART等在工业问答任务中表现出色。知识图谱构建与维护可借助现有的RDF或Neo4j技术栈完成,且已有成熟的实体识别与关系抽取工具可直接迁移。混合检索框架将BM25与Dense Retrieval相结合,可通过调参实现召回率与精确度的平衡;生成模块在检索上下文中进行微调后,能够生成符合技术规范的答案。系统整体架构采用微服务化设计,便于与MES、SCADA等现有工业信息系统集成,并可在本地部署以满足离线使用需求。鉴于上述技术路径均基于成熟开源框架与行业标准,本项目在技术实现上具备充分的可行性。

八、功能分析

系统功能模块可分为七大层面,分别为数据采集与预处理层、知识图谱构建层、检索增强生成层、对话管理与交互层、离线与多模态支持层、安全与合规管理层以及系统集成与运维层。每一层都承担特定的功能职责,并通过清晰的接口实现模块间的协同工作。

数据采集与预处理层负责从企业内部维护数据库、设备日志系统、技术手册以及公开标准文档中获取原始文本资料;随后对文本进行清洗、分词、命名实体识别与关系抽取,并利用领域专家标注的语料库对关键术语进行统一规范;该层还需实现多语言文本的编码转换与存储,保证后续模块能够无缝读取。知识图谱构建层以预处理层输出的实体与关系为输入,使用RDF或Neo4j等图数据库技术构建设备类型、故障特征、诊断步骤与维修方案等多维节点与边;通过本体化约束与版本控制机制,实现知识的可扩展性与可维护性。检索增强生成层由两子模块组成:混合检索子模块融合BM25词频检索与Dense Passage Retrieval向量检索,动态调节权重以兼顾召回率与语义匹配精度;生成子模块基于Transformer架构(如T5或BART)进行微调,并在检索结果上下文中聚合信息,输出专业、可执行的维修建议,同时附带出处说明与风险评估。对话管理与交互层实现多轮对话机制与用户反馈收集功能,支持文本输入、语音识别与即时回复;该层还提供聊天式界面,并通过RESTful API或gRPC向前端和后端系统提供服务。离线与多模态支持层为现场工况提供本地缓存与离线推理能力,并支持图像、视频等多模态资料的检索与解析;该层通过轻量化模型部署与边缘计算技术,确保在无网络环境下仍能正常运行。安全与合规管理层负责用户身份认证、权限控制、数据加密存储以及符合ISO/IEC 27001等信息安全标准的实施;同时,该层提供答案来源追溯、日志审计与合规报告生成功能,以满足行业监管与事故调查需求。系统集成与运维层则实现与MES、SCADA等企业信息系统的无缝对接,提供监控仪表盘、性能指标收集与自动化运维脚本;该层还支持模型的在线/离线更新、版本回滚与灾备恢复,确保系统长期稳定运行。

九、数据库设计

字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
---|---|---|---|---|---
device_id | 设备编号 | 36 | CHAR(36) | PK | 主键,UUID
name | 设备名称 | 100 | VARCHAR(100) | - |
type_id | 设备类型编号 | 36 | CHAR(36) | FK (DeviceTypes.type_id) | 外键,关联设备类型表
serial_number | 序列号 | 50 | VARCHAR(50) | - |
location | 安装位置 | 200 | VARCHAR(200) | - |
status | 当前状态(在线/离线/维护中) | 20 | VARCHAR(20) | - |

device_type_id | 设备类型编号 (PK) | 36 | CHAR(36) | PK |
type_name | 类型名称(如泵、阀门) | 50 | VARCHAR(50) | - |

fault_id | 故障编号 (PK) | 36 | CHAR(36) | PK |
fault_name | 故障名称(如过热、泄漏) | 100 | VARCHAR(100) | - |
description | 故障描述 | 5000 | TEXT | - |

procedure_id | 维修步骤编号 (PK) | 36 | CHAR(36) | PK |
fault_id_fk | 所属故障编号 (FK) | 36 | CHAR(36) | FK (FaultCategories.fault_id) |
step_number | 步骤顺序号 | INT | - |
description | 步骤描述(技术细节) | 5000 | TEXT | - |

node_id | 节点编号 (PK) | 36 | CHAR(36) | PK |
node_type | 节点类型(设备/故障/步骤) | 20 | VARCHAR(20) |
name | 节点名称(可显示) | 200 | VARCHAR(200) |

edge_id | 边编号 (PK) | 36 | CHAR(36) | PK |
source_node_id_fk | 源节点编号 (FK) | 36 | CHAR(36) | FK (KnowledgeGraphNodes.node_id) |
target_node_id_fk | 目标节点编号 (FK) | 36 | CHAR(36) | FK (KnowledgeGraphNodes.node_id) |
relation_type | 关系类型(如“属于”“引起”) | 50 | VARCHAR(50) |

doc_id | 文档编号 (PK) | 36 | CHAR(36) | PK |
title | 文档标题 | 200 | VARCHAR(200) |
doc_type | 文档类型(手册/指南/记录) | 20 | VARCHAR(20) |
content_path | 内容存储路径(文件系统或对象存储) | 500 | VARCHAR(500) |

annotation_id | 注释编号 (PK) | 36 | CHAR(36) | PK |
doc_id_fk | 所属文档编号 (FK) | 36 | CHAR(36) | FK (Documents.doc_id) |
node_id_fk | 关联节点编号 (FK) | 36 | CHAR(36) | FK (KnowledgeGraphNodes.node_id) |

user_id | 用户编号 (PK) | 36 | CHAR(36) | PK |
username | 登录名(唯一) | 50 | VARCHAR(50) |
password_hash | 密码哈希值 | 128 | CHAR(128) |
role | 用户角色(维护员/管理员) | 20 | VARCHAR(20) |

session_id | 会话编号 (PK) | 36 | CHAR(36) | PK |
user_id_fk | 用户编号 (FK) | 36 | CHAR(36) | FK (Users.user_id) |
start_time | 会话开始时间 | 19 | DATETIME |
end_time | 会话结束时间(可为空) | 19 | DATETIME |

conv_id | 对话编号 (PK) | 36 | CHAR(36) | PK |
session_id_fk | 所属会话编号 (FK) | 36 | CHAR(36) | FK (Sessions.session_id) |
timestamp | 消息时间戳 | 19 | DATETIME |
user_input | 用户输入文本(问题) | 5000 | TEXT |

response_id | 响应编号 (PK) | 36 | CHAR(36) | PK |
conv_id_fk | 所属对话编号 (FK) | 36 | CHAR(36) | FK (Conversations.conv_id) |
response_text | 系统生成答案文本(技术细节) | 5000 | TEXT |

cache_id | 缓存编号 (PK) | 36 | CHAR(36) | PK |
query_text | 查询文本(原始问题) | 5000 | TEXT |
retrieved_doc_ids | 检索到的文档编号列表(JSON) | 2000 | TEXT |
timestamp | 缓存时间戳 | 19 | DATETIME |

log_id | 日志编号 (PK) | 36 | CHAR(36) | PK |
log_level | 日志级别(INFO/ERROR/DEBUG) | 10 | VARCHAR(10) |
message | 日志信息内容(可变长度) | 2000 | TEXT |
timestamp | 记录时间戳 | 19 | DATETIME |

以上表结构均采用单主键设计,外键通过字符型UUID实现跨表关联,满足第一范式与第二范式;所有重复信息被拆分至专门表中,避免冗余,符合第三范式。

十、建表语句

CREATE DATABASE IF NOT EXISTS maintenance_qna CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
USE maintenance_qna;

-- 设备类型表
CREATE TABLE DeviceTypes (
type_id CHAR(36) NOT NULL,
type_name VARCHAR(50) NOT NULL,
PRIMARY KEY (type_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 设备表
CREATE TABLE Devices (
device_id CHAR(36) NOT NULL,
name VARCHAR(100) NOT NULL,
type_id CHAR(36) NOT NULL,
serial_number VARCHAR(50),
location VARCHAR(200),
status VARCHAR(20),
PRIMARY KEY (device_id),
KEY idx_devices_type_id (type_id),
CONSTRAINT fk_devices_type_id FOREIGN KEY (type_id) REFERENCES DeviceTypes(type_id) ON UPDATE CASCADE ON DELETE RESTRICT
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 故障类别表
CREATE TABLE FaultCategories (
fault_id CHAR(36) NOT NULL,
fault_name VARCHAR(100) NOT NULL,
description TEXT,
PRIMARY KEY (fault_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 维修步骤表
CREATE TABLE RepairProcedures (
procedure_id CHAR(36) NOT NULL,
fault_id_fk CHAR(36) NOT NULL,
step_number INT NOT NULL,
description TEXT,
PRIMARY KEY (procedure_id),
KEY idx_procedures_fault_id_fk (fault_id_fk),
CONSTRAINT fk_procedures_fault_id_fk FOREIGN KEY (fault_id_fk) REFERENCES FaultCategories(fault_id) ON UPDATE CASCADE ON DELETE RESTRICT
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 知识图谱节点表
CREATE TABLE KnowledgeGraphNodes (
node_id CHAR(36) NOT NULL,
node_type VARCHAR(20) NOT NULL,
name VARCHAR(200),
PRIMARY KEY (node_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 知识图谱边表
CREATE TABLE KnowledgeGraphEdges (
edge_id CHAR(36) NOT NULL,
source_node_id_fk CHAR(36) NOT NULL,
target_node_id_fk CHAR(36) NOT NULL,
relation_type VARCHAR(50),
PRIMARY KEY (edge_id),
KEY idx_edges_source_node_id_fk (source_node_id_fk),
KEY idx_edges_target_node_id_fk (target_node_id_fk),
CONSTRAINT fk_edges_source_node_id_fk FOREIGN KEY (source_node_id_fk) REFERENCES KnowledgeGraphNodes(node_id) ON UPDATE CASCADE ON DELETE CASCADE,
CONSTRAINT fk_edges_target_node_id_fk FOREIGN KEY (target_node_id_fk) REFERENCES KnowledgeGraphNodes(node_id) ON UPDATE CASCADE ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 文档表
CREATE TABLE Documents (
doc_id CHAR(36) NOT NULL,
title VARCHAR(200) NOT NULL,
doc_type VARCHAR(20),
content_path VARCHAR(500),
PRIMARY KEY (doc_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 注释表
CREATE TABLE Annotations (
annotation_id CHAR(36) NOT NULL,
doc_id_fk CHAR(36) NOT NULL,
node_id_fk CHAR(36) NOT NULL,
PRIMARY KEY (annotation_id),
KEY idx_annotations_doc_id_fk (doc_id_fk),
KEY idx_annotations_node_id_fk (node_id_fk),
CONSTRAINT fk_annotations_doc_id_fk FOREIGN KEY (doc_id_fk) REFERENCES Documents(doc_id) ON UPDATE CASCADE ON DELETE CASCADE,
CONSTRAINT fk_annotations_node_id_fk FOREIGN KEY (node_id_fk) REFERENCES KnowledgeGraphNodes(node_id) ON UPDATE CASCADE ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 用户表
CREATE TABLE Users (
user_id CHAR(36) NOT NULL,
username VARCHAR(50) NOT NULL UNIQUE,
password_hash CHAR(128) NOT NULL,
role VARCHAR(20),
PRIMARY KEY (user_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 会话表
CREATE TABLE Sessions (
session_id CHAR(36) NOT NULL,
user_id_fk CHAR(36) NOT NULL,
start_time DATETIME NOT NULL,
end_time DATETIME,
PRIMARY KEY (session_id),
KEY idx_sessions_user_id_fk (user_id_fk),
CONSTRAINT fk_sessions_user_id_fk FOREIGN KEY (user_id_fk) REFERENCES Users(user_id) ON UPDATE CASCADE ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 对话表
CREATE TABLE Conversations (
conv_id CHAR(36) NOT NULL,
session_id_fk CHAR(36) NOT NULL,
timestamp DATETIME NOT NULL,
user_input TEXT,
PRIMARY KEY (conv_id),
KEY idx_conversations_session_id_fk (session_id_fk),
CONSTRAINT fk_conversations_session_id_fk FOREIGN KEY (session_id_fk) REFERENCES Sessions(session_id) ON UPDATE CASCADE ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 响应表
CREATE TABLE Responses (
response_id CHAR(36) NOT NULL,
conv_id_fk CHAR(36) NOT NULL,
response_text TEXT,
PRIMARY KEY (response_id),
KEY idx_responses_conv_id_fk (conv_id_fk),
CONSTRAINT fk_responses_conv_id_fk FOREIGN KEY (conv_id_fk) REFERENCES Conversations(conv_id) ON UPDATE CASCADE ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 缓存表
CREATE TABLE CacheEntries (
cache_id CHAR(36) NOT NULL,
query_text TEXT,
retrieved_doc_ids TEXT,
timestamp DATETIME NOT NULL,
PRIMARY KEY (cache_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 日志表
CREATE TABLE Logs (
log_id CHAR(36) NOT NULL,
log_level VARCHAR(10),
message TEXT,
timestamp DATETIME NOT NULL,
PRIMARY KEY (log_id),
KEY idx_logs_log_level (log_level)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

文章下方名片联系我即可~大家点赞、收藏、关注、评论啦 、查看下方👇🏻获取联系方式👇🏻

返回列表