【毕设分享】79593基于知识图谱和大语言型的图检索增强的旅游智能推荐系统

摘 要

　　目前在线旅游信息过载现象比较严重，游客很难从众多的景点、美食、行程这些非结构化数据中找到自己想要的信息。创建出一个包含多种旅游信息的智能推荐系统，可以提高用户的体验以及旅游决策的速度。本系统使用Spring Boot做后端框架，Vue做前端技术，MySQL做数据库，采用知识图谱和大语言模型结合的图检索增强生成(RAG)技术来解决传统推荐系统语义理解不够、冷启动等难题。系统面向普通用户和管理员两种角色，主要解决思路有如下几点，构建景点、美食、标签等实体关系的旅游知识图谱，用大语言模型对用户的查询意图进行解析并加强检索能力，进而实现个性化的推荐以及智能的交互。

　　系统有知识图谱构建模块、RAG推荐引擎、地图可视化模块和多角色操作流程这四个模块。普通用户可以进行景点地图查看、景点和美食查询、门票及景点预订、在线聊天、评论管理、旅游行程管理；管理员对景点分类和信息管理、地图标注、预订和标签管理、美食信息管理、系统配置、新闻发布有权限。系统运行之后明显改善了推荐结果的语义相关性以及覆盖率，用户交互过程可以对自然语言查询作出高质量的回应，其实际价值体现在减少旅游信息筛选的成本，提高行程安排的效率和满意程度上。

关键词：旅游推荐；知识图谱；大语言模型；图检索增强；Spring Boot

Based on Knowledge Graph and Large Language Model Graph Retrieval-Augmented for Tourism Intelligent Recommendation System

ABSTRACT

　　At present, there is too much information online for tourists to obtain their own personalised recommendations quickly, as it is in a large volume and unstructured form. A new intelligent recommendation system based on various sources of tourist information will help enhance the experience and travel decisions of tourists. Spring Boot is used for the backend, Vue is employed on the front end, and MySQL will be taken as the database. Knowledge graphs and Large Language Model-based Graph Retrieval-Augmented Generation (RAG) technology have been used to solve the problems of semantic understanding and cold-start in traditional recommendation systems. The two sections of the system are the general-use functions and the administrator functions. The idea of the solution is to construct a tourism knowledge graph with nodes such as attractions, food and beverages, tags, etc., and then use intention parsing and retrieval-augmented generation (RAG) of large language models to provide personalised recommendations and intelligent answers to users' questions.

　　The modules for the implementation of the system are the knowledge graph construction module, the RAG recommendation engine, the map visualisation module and other operating workflows for different roles. Ordinary users can browse the attraction map, query attractions and cuisines, book tickets and attractions, use online chat, manage comments, manage travel itineraries, etc. Administrators are in charge of attraction classification and information management, map annotation, booking and tag management, cuisine information management, system configuration and news publication. After the system is put into operation, there has been an increase in the relevance and coverage of recommended items. User interaction can provide a good answer to the question in natural language and help reduce the cost of filtering tourism information and improve the efficiency and satisfaction of itinerary planning.

KEY WORDS:Tourism Recommendation;Knowledge Graph;Large Language Model;Graph Retrieval-Augmented;Spring Boot

目　录

第1章 开发工具与相关技术

1.1 开发工具

1.1.1 IntelliJ IDEA

1.1.2 MySQL数据库

1.1.3 Redis数据库

1.2 开发技术

1.2.1 Spring Boot

1.2.2 Vue

1.2.3 协同过滤算法

第2章 系统分析

2.1 国内外研究现状分析

2.1.1 国内研究现状

2.1.2 国外研究现状

2.2 可行性分析

2.2.1 技术可行性

2.2.2 经济可行性

2.2.3 操作可行性

2.3 需求分析

2.3.1 功能需求

2.3.2 数据需求

2.3.3 其他需求

第3章 系统总体设计

3.1 数据库设计

3.1.1 MySQL数据库设计

3.1.2 Redis数据库设计

3.2 数据交互与数据存储

3.2.1 数据交互

3.2.2 数据存储

3.3 系统功能结构

3.4 协同过滤算法设计

3.5 知识图谱设计

第4章 系统详细设计与实现

4.1 普通用户的设计与实现

4.1.1 登录注册功能实现

4.1.2 景点地图查看功能实现

4.1.3 景点推荐查询功能实现

4.1.4 美食信息查询功能实现

4.1.5 门票预订功能实现

4.1.6 在线聊天功能实现

4.1.7 评论管理功能实现

4.1.8 景点预订功能实现

4.1.9 旅游行程管理功能实现

4.2 管理员的设计与实现

4.2.1 景点分类管理功能实现

4.2.2 景点信息管理功能实现

4.2.3 景点信息地图功能实现

4.2.4 景点预订管理功能实现

4.2.5 标签信息管理功能实现

4.2.6 美食信息管理功能实现

4.2.7 系统管理功能实现

4.2.8 新闻管理功能实现

结　论

谢　辞

参考文献

第1章 开发工具与相关技术

1.1 开发工具

1.1.1 IntelliJ IDEA

　　IntelliJ IDEA是Java领域最流行的集成开发环境，给旅游智能推荐系统开发提供完善了的代码编辑、调试、版本控制的支持。该IDE自带的静态代码分析工具可以对编码过程中的潜在问题进行即时检测，从而减少运行时出现异常的可能性[1]。IntelliJ IDEA 的智能补全、重构功能大大提高了Spring Boot项目中项目构建的速度，使开发者可以把更多的精力放在推荐逻辑的实现上。对于前端Vue框架的代码提示和插件集成，该IDE也具有很好的兼容性，保证了全栈开发过程的一致性。旅游行程管理功能在使用IntelliJ IDEA的数据库工具时可以直接连接到MySQL上进行表结构的设计以及查询的优化，不会因为工具切换而造成效率的降低。IntelliJ IDEA的Maven集成可以简化项目的依赖管理和构建过程，保证开发环境的可重复使用和团队合作的一致性[2]。

1.1.2 MySQL数据库

　　MySQL数据库用客户端-服务器结构来实现数据的定义、操作和控制，用结构化查询语言来完成。该数据库具有事务处理以及ACID特性，给旅游智能推荐系统中门票预订、景点预订等操作提供数据一致性的保证。MySQL的InnoDB存储引擎实现了行级锁和外键约束，可以保证在处理用户评论管理以及订单并发写入的时候，数据是完整的、隔离的[3]。对景点信息、美食信息、标签信息等主要业务表使用B+树索引结构可以大大加快根据分类或者名称进行查询的速度。MySQL主从复制机制给系统提供读写分离的扩展性，把景点地图查看和推荐查询这些读取密集型的操作分担给从库，降低主库的负担。利用MySQL事件调度器对新闻管理及定时任务实行自动维护，缩减了对人工操作的需求[4]。

1.1.3 Redis数据库

　　Redis数据库采用的是内存存储模型，使用单线程事件驱动的架构来处理请求，它的数据读写延迟可以达到亚毫秒级。在旅游智能推荐系统当中，Redis被用作热点景点信息以及推荐查询结果的缓存手段，从而减轻了后端MySQL数据库的查询负担[16]。该数据库可以存储字符串、哈希、列表、集合等不同的数据结构，有序集合可以快速实现景点浏览热度的实时排序和排行统计[5]。Redis的键过期策略可以给临时数据，例如用户登录令牌和验证码等设置有效期，从而完成登录注册模块的会话管理。在线聊天功能用到的是Redis的发布订阅模式来实现即时消息的转发和通知推送。持久化方式有RDB快照和AOF日志两种，根据场景的不同可以选择恢复速度或者数据安全性的组合，保证系统重启之后缓存数据可以很快地重建起来。

1.2 开发技术

1.2.1 Spring Boot

　　Spring Boot框架按照约定优于配置的原则，用自动配置来大大减少传统Spring应用中样板化配置的代码。框架内部集成的Tomcat服务器使得旅游智能推荐系统可以以独立的Java应用的形式运行，简化了部署的过程。Spring Boot的Starter依赖管理机制把常用技术所用到的库集中起来，简化了项目的初始化以及集成过程[6]。就景点分类管理、美食信息管理这些业务逻辑层而言，Spring Boot同Spring MVC联合起来创建RESTful API接口，从而给前端Vue赋予了标准化的数据交互途径。该框架的拦截器和过滤器机制对用户的权限进行了鉴定，普通用户只能查看景点推荐，管理员可以进行后台管理。Spring Boot Actuator模块提供了一系列的监控端点，可以实时地暴露系统内存占用和请求处理时间等指标，从而帮助开发者发现性能瓶颈并优化推荐引擎的响应速度。

1.2.2 Vue

　　Vue使用渐进式的前端架构，核心库只处理视图层，利用组件化开发模式把用户界面的复用封装起来。Vue渲染景点地图查看页面，利用第三方地图API实现地理坐标可视化[7]。响应式数据绑定机制使模型层的数据发生变化时，就会立刻反映到视图上，从而降低开发人员使用DOM节点手动进行修改的操作，把更多的精力放在了旅游行程管理功能交互逻辑的实现上。Vue Router是官方路由管理器，可以实现单页应用下多视图之间的切换，给用户从景点推荐查询跳转到门票预订页面提供了一条流畅的导航路径。Vuex状态管理模式可以对全局数据进行统一管理，即用户的登录状态、购物车的信息等等，减少了跨组件通信的复杂程度。由于美食信息查询及评论管理模块使用的是Vue框架的表单双向绑定特性，从而使得前端开发变得更加简便，提高了工作效率[8]。

1.2.3 协同过滤算法

　　协同过滤算法以用户行为矩阵为基础，对用户之间或者物品之间的相似性进行分析，从而得到个性化的推荐结果。该算法的主要作用就是利用计算余弦相似度或者皮尔逊相关系数的方式，从历史交互数据当中找出隐藏的兴趣偏好模式[19]。旅游智能推荐系统中，用普通用户的景点预订记录和评论行为来建立用户-景点评分矩阵，根据目标用户的景点预订记录和评论行为来寻找相似偏好的邻居集合，从而得到推荐列表。协同过滤算法并不依靠物品的内容特征来做出判断，可以找到跨越种类的隐性联系，即给喜欢自然景观的人推荐类似景点的旅游线路。为了应对冷启动问题，系统采用热门景点统计和标签信息管理这两种回退策略，在新的用户或者新的景点没有交互数据的时候也可以提供基础的推荐服务。该算法同知识图谱技术互相补充，使推荐结果更加具有可解释性，通过显示相似用户的过去行为来提高用户对于推荐结果的信任度。

第2章 系统分析

2.1 国内外研究现状分析

2.1.1 国内研究现状

　　国内旅游推荐系统研究历经从传统信息管理到智能化服务的演进过程。早期系统主要实现景点信息的电子化存储与简单分类检索，功能集中于基础数据展示与人工筛选。近年来随着知识图谱与大语言模型技术的成熟，旅游推荐领域开始探索语义理解与关联推理能力的融合应用。研究热点逐步从单一景点推荐转向涵盖行程规划、美食查询、预订管理的一体化服务模式，系统设计更加注重用户交互体验与个性化响应效率。这一技术演变为本系统整合知识图谱与大语言模型实现图检索增强推荐提供了现实基础。

　　魏薇在2025年研究了扬州旅游知识图谱的构建方法并将其应用于旅游规划生成[9]，探索了实体关系抽取与路径遍历技术在行程组织中的实现路径。该研究为本系统知识图谱模块中景点与美食的语义关联构建提供了理论支撑。张庆在2025年提出了基于多模态大语言模型数据增强的旅游景点推荐方法[10]，通过扩充训练样本改善了推荐结果的覆盖率。该研究所采用的数据增强策略有助于本系统景点推荐查询功能在冷启动阶段获得更稳定的初始效果。石璇在2025年构建了基于知识图谱的陶瓷文化乡村特色旅游推荐系统[11]，验证了知识图谱在小众旅游场景中的有效性。该成果为本系统美食信息查询与评论管理模块中用户偏好挖掘提供了方法借鉴。滕斯琦在2024年开展了基于知识图谱嵌入的古都旅游景点推荐研究[12]，利用图嵌入技术提升了景点相似度计算的准确性。该研究对知识表示学习的探索为本系统推荐算法模块的相似性度量设计提供了技术参考。许洋在2022年设计了基于知识图谱的旅游路线推荐系统[13]，通过图遍历算法实现了多景点串联的行程规划方案。该系统的路线生成逻辑直接启发本系统旅游行程管理模块的功能设计，有助于用户便捷地完成出行计划编排。邵嘉进等人在2021年实现了基于用户画像的旅游推荐服务[14]，通过标签化建模提升了推荐结果与个体需求的匹配程度。该用户画像构建方法应用于本系统登录注册与个人化管理模块，为区分普通用户与管理员权限提供了基础数据支撑。吴杰在2021年研究了以事件为中心的旅游知识图谱构建方法[15]，提出了事件时序关联与空间位置融合的建模策略。该事件驱动思想对本系统景点地图查看与景点信息地图模块中路线展示与位置标注具有重要启发意义。

　　综合分析国内现有研究成果可以发现，知识图谱与大语言模型在旅游推荐领域的应用仍处于探索阶段。多数研究聚焦于单一技术方向的性能优化，缺少将两种技术深度融合的图检索增强系统实现。针对门票预订、在线聊天等交互密集型功能模块的智能化改造相对薄弱，系统整体性设计不足。本系统在吸收上述研究成果的基础上，面向普通用户与管理员的实际使用场景，将知识图谱的语义关联能力与大语言模型的生成能力协同应用于景点推荐查询与美食信息检索，试图填补当前研究在功能集成与交互体验层面的空白。

2.1.2 国外研究现状

　　国外旅游推荐系统研究起步较早，在个性化算法与上下文感知技术方面积累了丰富成果。近年来随着大语言模型能力的快速提升，国外学者开始探索将检索增强生成框架引入旅游决策支持场景。研究趋势表现为从静态评分预测向动态对话式推荐转变，系统设计更加关注用户在实时交互过程中的需求表达与意图理解。国外研究在模型可解释性与推荐多样性方面保持了领先优势，同时逐步将知识图谱作为辅助信息源融入大语言模型的推理过程。这些先进思想为本系统结合知识图谱与大语言模型实现图检索增强推荐指明了技术路径。

　　Zhao等人在2026年研究了人工智能驱动的个性化旅游推荐系统优化策略[16]，通过深度学习模型提升了用户行为序列的建模精度。该研究在序列预测方面的成果为本系统景点推荐查询模块的实时响应机制提供了优化方向。Payandenick等人在2025年提出了面向个性化旅游体验的多标准推荐系统[17]，结合用户查询分析实现了动态偏好捕捉。该研究的查询解析方法应用于本系统美食信息查询功能，有助于提高自然语言输入的检索准确率。Karlović等人在2025年利用检索增强大语言模型与语义重排序技术实现了上下文感知的旅游推荐[18]，显著改善了推荐结果与用户情境的匹配程度。该研究提出的检索增强架构直接启发了本系统知识图谱与大语言模型融合的设计思路，为图检索增强模块的实现提供了技术参照。Zheng等人在2025年探索了将小型模型嵌入大语言模型用于智慧旅游中的兴趣点推荐[19]，在保持生成能力的同时降低了计算成本。该研究的模型轻量化策略对本系统在本地开发环境中的部署效率提升具有参考价值。Hui等人在2022年提出了融合知识图谱的深度旅行对话推荐系统[20]，通过对话交互与图结构信息的协同增强了推荐的自然性与可靠性。该研究在对话式推荐与知识推理结合方面的探索为本系统在线聊天模块中嵌入推荐功能的后续扩展提供了前瞻性思路。

　　综合国外研究动向可以发现，大语言模型与知识图谱的联合应用已成为旅游推荐领域的前沿方向。国外学者在检索增强生成框架下的探索更为深入，但相关研究大多依赖大规模云计算资源与分布式存储环境。本系统结合国内旅游服务的实际运行条件，在吸收国外先进算法思想的基础上，面向单机部署环境与本地化数据管理需求进行针对性简化与适配，重点保障门票预订、景点预订等核心交易功能的稳定性与响应速度。

2.2 可行性分析

2.2.1 技术可行性

　　系统采用前后端分离架构，前端处理用户交互与视图渲染，后端负责业务逻辑与数据存取，模块间通过接口通信降低耦合度。知识图谱的图结构存储与大语言模型的检索增强生成技术已有成熟开源实现，核心算法与数据库方案均经过大量生产环境验证。各功能模块独立开发与测试，整体运行稳定性可得到保障。

2.2.2 经济可行性

　　系统开发基于开源技术栈与社区版开发工具，软件授权成本为零。硬件方面仅需一台普通服务器用于部署后端服务与数据库，内存与磁盘需求在标准配置范围内。日常运行阶段的人力维护成本较低，一名技术人员可同时承担系统监控、数据备份与异常处理工作。整体投入低于同类商业系统开发预算。

2.2.3 操作可行性

　　普通用户通过浏览器访问系统，注册登录后即可使用景点查询、预订与行程规划功能，页面布局遵循主流旅游平台交互习惯。管理员界面按照业务分类组织菜单，每个管理模块的操作流程保持统一。界面提示信息清晰完整，新用户无需专门培训即可完成主要操作流程。

2.3 需求分析

2.3.1 功能需求

　　系统分成普通用户端和管理端两个子系统。普通用户进入系统可以完成登录注册、景点地图查看、景点推荐查询、美食信息查询、门票预订、景点预订、旅游行程管理、在线聊天、评论管理等操作。管理员登录管理端后执行景点分类管理、景点信息管理、景点信息地图标注、景点预订管理、标签信息管理、美食信息管理、系统管理、新闻管理等操作。系统根据用户身份分配不同的操作权限，普通用户只能对与自己旅游规划有关的查询、预订进行操作，管理员有全部的数据管理权限。系统自动保存管理员的增删改操作记录，可以查阅。按照功能需求分析，设计普通用户端使用流程图如图2-1所示，管理端使用流程图如图2-2所示。

图2-1普通用户端使用流程图 图2-2管理端使用流程图

2.3.2 数据需求

　　系统应用涉及用户、景点、美食、预订、行程、评论、公告等多种实体对象，经过调研分析，确定各对象需存储的相关数据信息如下。

　　用户账户：包含用户名、密码、手机号、邮箱、头像、用户状态等信息，普通用户与管理员的权限通过用户组字段区分。

　　景点信息：包含景点名称、景点分类、开放时间、门票价格、景点位置、详细地址及经纬度、景点图片、景点介绍、点击数、点赞数、收藏数、评论数、智能推荐标识等信息。

　　美食信息：包含美食名称、美食标签、美食口味、美食食材、人均消费、美食图片、推荐店铺、美食介绍等信息。

　　景点预订：包含景点名称、景点分类、预订日期、预订数量、门票价格、预订总价、联系电话、预订备注、用户姓名、审核状态、支付状态等信息。

　　旅游行程：包含出行日期、出行天数、出行地点、出行预算、行程规划等信息。

　　收藏与评论：包含收藏人、收藏标题、封面图、评论内容、评论人、回复关系等信息。

　　公告：包含标题、正文、创建时间、更新时间等信息。

　　轮播图：包含标题、内容、链接、图片、点击量等信息。

　　系统自动生成操作日志供管理员查询。

2.3.3 其他需求

　　系统需按照软件工程方法开发，程序架构合理，界面友好，操作简便。性能方面应适当优化，前端能够处理的数据尽量由浏览器完成计算以减少服务器压力。MySQL数据库操作属于硬盘文件IO操作较为耗时，对于景点分类、标签信息等不常变更但频繁访问的数据应使用Redis进行缓存以提升系统运行效率。

　　并发操作较多的门票预订与景点预订功能需使用线程安全机制防止数据竞争，创建旅游行程等耗时操作需开启子线程执行避免主线程阻塞。系统运行过程中涉及数据安全问题，生成预订订单编号时需采用线程锁技术保证编号的唯一性与有序性。

第3章 系统总体设计

3.1 数据库设计

3.1.1 MySQL数据库设计

　　在需求分析的基础上，利用MySQL设计了10张数据表存储系统中需要处理的各类数据，数据库表结构如表3-1至表3-10所示。

　　1. 用户账户表

　　用来存储系统所有登录账户的认证信息，如表3-1所示：

表3-1 用户账户表

　　2. 普通用户表

　　用来存储普通用户的详细信息，如表3-2所示：

表3-2 普通用户表

　　3. 景点信息表

　　用来存储景区的基础数据，如表3-3所示：

表3-3 景点信息表

　　4. 美食信息表

　　用来存储美食推荐的相关数据，如表3-4所示：

表3-4 美食信息表

　　5. 景点预订表

　　用来存储用户提交的景点预订订单，如表3-5所示：

表3-5 景点预订表

　　6. 旅游行程表

　　用来存储用户规划的个人行程，如表3-6所示：

表3-6 旅游行程表

　　7. 评论表

　　用来存储用户对景点或美食的评论内容，如表3-7所示：

表3-7 评论表

　　8. 聊天用户好友表

　　用来存储用户之间的好友关系，如表3-8所示：

表3-8 聊天用户好友表

　　9. 聊天用户消息表

　　用来存储用户之间的聊天记录，如表3-9所示：

表3-9 聊天用户消息表

　　10. 文章表

　　用来存储系统发布的新闻资讯内容，如表3-10所示：

表3-10 文章表

3.1.2 Redis数据库设计

　　为了提升系统运行效率，本系统使用Redis数据库技术。通过分析系统所需数据，发现景点分类、美食标签等数据极少发生变化且访问频率极高，适合使用Redis进行存储。

　　Redis是一个存储键值对的存储系统，键的数据类型为string，值的数据类型包括string、hash、list、set及zset五种。本系统存储的景点分类数据使用string:zset类型，该类型在存储分类信息集合时可通过设置score决定各分类的排列顺序。集合的特点保证元素不会重复，避免了多次插入相同分类信息的问题。对于美食标签数据采用set类型存储，利用集合的无重复特性维护标签的唯一性。热门景点信息使用hash类型存储，以景点id为字段名，景点详情对象为字段值，实现单个景点信息的快速存取。系统采用缓存旁路策略，普通用户查询分类与标签时直接从Redis读取，管理员执行新增、修改、删除操作后同步更新MySQL与Redis中的数据，确保缓存与数据库的一致性。

3.2 数据交互与数据存储

3.2.1 数据交互

　　在数据交互方面，Spring Boot框架提供了完善的数据接收与封装方法，无论是简单数据类型还是复杂对象与集合类型，均可通过设置参数名直接接收和封装。

　　GET和POST是提交数据最常用的两种方式。比较常用的提交数据方法是在URL后直接添加问号及参数键值对，以“&”符号分割多个参数，这是典型的GET方式提交。另一种常用方法是通过表单提交，在input、textarea、select等标签中设置name和value即可提交数据，表单可指定使用GET或POST方式提交。本系统还多次使用第三种数据提交方法即发送Ajax请求。该方法可对用户填写的数据进行处理后再提交，相较于表单提交更具灵活性。Ajax默认提交的数据类型为application/x-www-form-urlencoded; charset=UTF-8，通过该方式提交时，无论定义为“key1=value1&key2=value2…”字符串还是{key1:value1,key2:value2,…}的JSON数据，均会转换为前者形式提交至后台。若将contentType设置为“application/json;charset=UTF-8”，则需将JSON数据手动转换为字符串再发送。Spring Boot框架在接收数据时，只需在参数前添加@RequestBody注解即可快速解析JSON并完成对应数据类型的封装。

　　JSON数据格式具有较多优点。JSON存储数据功能强大，键统一使用字符串类型，值可使用多种数据类型，不仅包括Java中的基本数据类型，还可使用string、对象、集合等类型。系统前端页面在解析JSON数据时同样方便，后端通过@ResponseBody注解可将数据转换为JSON类型返回前端，前端读取JSON数据值时仅需使用“数据名.键名”的方式即可取出。

3.2.2 数据存储

　　本系统的数据存储采用MySQL存储、Redis存储与文件存储相结合的方式。用户账户信息、景点信息、美食信息、预订订单等绝大部分系统数据使用MySQL进行存储。为提高性能，景点分类与美食标签信息采用MySQL与Redis双存储策略，普通用户读取分类和标签时直接从Redis读取，管理员执行增加、删除、修改操作后同步更新MySQL与Redis中的数据。

　　对于景点图片、美食图片、文章封面等文件类型数据，直接使用MySQL存储会严重影响系统性能。本系统将图片文件存储至项目外部的独立目录中，通过在配置文件中添加静态资源映射，将硬盘目录映射至项目虚拟路径下。真实目录前添加“file:///”前缀表示使用file通信协议，该协议可访问本机存储的文件，从而实现图片文件的上传与读取访问。

3.3 系统功能结构

　　该系统以三类用户角色为依托来构建功能体系。普通用户完成登录注册之后就进入到个性化服务模块，景点地图查看功能用可视化的方式表现出来。景点推荐查询根据用户的喜好给出候选列表，美食信息查询给出目的地的餐饮信息。门票预订和景点预订分别对应景区入园和住宿两类订单，线上聊天模块支持实时交流。评论管理收集游客游玩后留下的反馈意见，旅游行程管理可以将多日的路线串联起来。管理员对后台数据进行维护，即景点分类层次的设置、景点信息的增删改查以及景点信息地图的坐标标注。景点预订管理处理异常订单，标签信息管理维护推荐算法所需要的特征词库。美食信息管理审核商家提交的餐饮数据，系统管理控制用户权限分配，新闻管理发布旅游资讯文章。系统功能结构图如下图3-1所示。

图3-1 系统功能结构图

　　其中普通用户端处理各类旅游业务操作，管理端负责全部基础数据的维护与系统配置。系统根据登录账号的角色字段分配不同操作权限，普通用户无法访问管理端任何功能模块。

　　1. 普通用户端

　　登录注册模块：支持用户完成账号注册与登录认证操作，注册时采集基础个人信息。已登录用户可修改密码与个人资料。

　　景点地图模块：以地图形式展示各景点地理坐标位置，用户可缩放拖拽地图查看不同区域的景点分布。

　　景点推荐查询模块：系统根据用户历史浏览记录与预订行为生成个性化推荐列表，推荐结果附带解释性文本。

　　美食信息查询模块：提供目的地周边餐饮店铺的详细信息查询，包含菜系种类与人均消费区间。

　　门票预订模块：用户选择游玩日期与门票种类后生成订单，支付成功后系统下发电子凭证。

　　在线聊天模块：搭建用户与客服之间的实时文字沟通通道，聊天记录持久化保存。

　　评论管理模块：用户对游览过的景点发表文字评价与星级评分，已发表的评论支持编辑修改。

　　景点预订模块：处理景区周边住宿类订单的预订操作，用户可查看订单状态与入住凭证。

　　旅游行程管理模块：用户将多个景点组合为多日行程计划，系统自动计算每日路线地理距离。

　　2. 管理端

　　景点分类管理模块：维护景点所属类别的层级结构与名称，支持分类的新增、修改、删除操作。

　　景点信息管理模块：负责景点名称、介绍文本、开放时间、门票价格等核心字段的录入与更新。

　　景点信息地图模块：在地图界面上标注景点坐标位置，管理员可拖拽调整标注点以修正位置偏差。

　　景点预订管理模块：查看所有用户的住宿订单记录，处理退款申请与房态冲突等异常情况。

　　标签信息管理模块：维护景点标签词库，标签用于个性化推荐算法中的用户偏好匹配。

　　美食信息管理模块：审核商家提交的餐饮数据，审核通过的店铺出现在普通用户的美食查询结果中。

　　系统管理模块：控制用户账号的启用禁用状态，配置系统运行参数与数据备份策略。

　　新闻管理模块：发布旅游资讯类文章至普通用户端的资讯板块，支持已发布文章的修改与下架。

3.4 协同过滤算法设计

　　协同过滤算法就是本系统个性化推荐功能的主要计算部分。该算法用用户历史行为数据来计算用户之间或者物品之间的相似度，给目标用户推荐列表。算法会从数据库里获取用户的景点预订记录，收藏情况以及评论评分等信息，进而创建出用户到物品的评分矩阵。用余弦相似度公式计算目标用户和其它用户之间的相似程度，取相似度最高的K个用户为最近邻集合。通过对最近邻用户的评分情况分析，预测目标用户对某个景点的喜好分数，最后将评分最高的几个景点以列表的形式呈现在用户面前。算法在运行时会不断对用户的交互数据进行更新，从而得到最新的用户行为矩阵，进而给出最符合用户当前兴趣点的推荐。就新用户的冷启动问题而言，用热门景点统计来作为初始推荐的方法，等用户行为数据收集起来之后再转为协同过滤模式。协同过滤算法的推荐流程图如下图3-3所示。

图3-3 协同过滤算法推荐流程图

　　图中展示了从用户行为数据采集到最终推荐列表生成的全过程。系统首先收集用户的预订、收藏及评论数据，经过数据预处理后构建用户-物品评分矩阵。以目标用户为基准计算与其他用户的相似度，筛选出K个最近邻用户。从最近邻用户的历史行为中提取目标用户未访问的景点，计算各景点的预测评分后按分值降序排列。最终将预测评分最高的N个景点作为推荐结果返回给用户。算法每隔固定时间窗口重新计算用户相似度矩阵，以适应新数据的加入与用户偏好的迁移。

3.5 知识图谱设计

　　知识图谱就是建立景点、美食、标签、位置这些实体之间的语义联系网络。图谱用自顶向下构建的方式，先确定实体类型和关系类型。实体类型有景点实体、美食实体、标签实体、区域实体，关系类型有“位于区域”“拥有标签”“提供美食”“相似景点”等分类。从景点信息表、美食信息表和标签信息表中提取实体数据，按照实体间业务关联建立关系边。景点实体和分类标签实体之间存在“属于分类”的关系，景点实体和美食实体之间存在“周边美食”的关系。知识图谱用图数据库的形式来存储，可以对图进行遍历查询以及路径检索。系统在进行景点推荐的时候，用知识图谱挖掘出用户感兴趣实体周边的关联实体，扩大推荐结果的多样性以及覆盖面。图谱数据定时增量更新，新增景点或者美食入库的时候会自动把实体以及关系添加进去。旅游知识图谱实体关系结构如图3-4所示。

图3-4 旅游知识图谱实体关系图

　　图中展示了系统中定义的核心实体类型及其相互之间的关联关系。用户实体通过“产生”行为连接预订、收藏及评论实体，这些行为实体再与景点实体或美食实体关联。景点实体与区域实体之间建立“位于”关系，与标签实体之间建立“属于”关系，与美食实体之间建立“周边”关系。景点实体之间通过“相似”关系形成关联网络，用于扩展推荐路径。美食实体与标签实体之间同样建立“属于”关系，与推荐店铺实体建立“提供”关系。知识图谱中的实体与关系共同构成一个多层次的语义网络，系统在进行图检索增强生成时通过遍历该网络获取与用户查询意图相关的上下文信息，辅助大语言模型生成更加精准的推荐结果。

第4章 系统详细设计与实现

4.1 普通用户的设计与实现

4.1.1 登录注册功能实现

　　用户访问系统时在登录页面输入用户名与密码，系统收到请求后查询数据库验证凭证匹配性。验证通过后生成包含用户身份信息的会话令牌返回至客户端，令牌用于后续请求的权限校验。新用户需进入注册页面填写用户名、手机号码及密码信息，系统逐一校验各字段格式合法性并检测用户名是否已被占用。所有校验通过后创建新账户记录，账户初始状态为未激活，用户需通过手机验证码完成激活操作。激活成功后自动跳转至登录页面，用户凭注册凭证即可登录系统。登录注册界面如图4-1所示。

图4-1 登录注册界面

4.1.2 景点地图查看功能实现

　　系统集成高德地图应用程序接口，在页面容器中渲染可交互的地图组件。后台数据库存储各景点的名称、简介、经度坐标及纬度坐标等地理信息，页面加载时通过异步请求获取所有景点坐标数据。地图组件根据坐标数据生成自定义标记点，每个标记点采用景点分类对应的图标样式进行差异化展示。用户拖动地图或执行缩放操作时，系统监听视图范围变化事件并重新计算当前视野内的标记点集合，仅渲染视野范围内的景点避免性能开销。点击标记点触发信息窗口弹层，该窗口展示景点名称、简要描述及缩略图，同时提供跳转至详情页的链接按钮。景点地图查看界面如图4-2所示。

图4-2 景点地图查看界面

4.1.3 景点推荐查询功能实现

　　系统结合知识图谱与大语言模型构建推荐计算管道。用户在推荐页面输入自然语言描述的查询意图，例如适合亲子游的景点或三天两夜行程推荐。前端将查询文本封装后发送至后端接口，接口接收到请求后启动图检索增强生成流程。该流程首先对查询文本进行实体识别与意图解析，从知识图谱中检索与查询关键词相关联的景点实体。检索得到的候选景点集合连同用户历史行为数据一同组装为提示词，提交给大语言模型进行偏好匹配与排序。模型输出排序后的推荐列表，每条推荐结果附带推荐理由说明。列表按预测评分从高到低排列呈现在前端页面。景点推荐查询界面如图4-3所示。

图4-3 景点推荐查询界面

4.1.4 美食信息查询功能实现

　　用户通过美食查询入口进入检索页面，页面提供关键词搜索框与分类筛选组件两种检索方式。关键词搜索模式下系统对美食名称、店铺名称及口味标签进行模糊匹配，分类筛选模式下用户可从菜系类型、人均价格区间或评分等级等维度缩小查询范围。后台执行查询后返回匹配的美食记录集合，每条记录包含美食名称、特色口味概述、参考人均消费金额及推荐店铺名称。查询结果采用卡片式列表布局，每张卡片展示美食缩略图与核心信息摘要。用户点击卡片进入详情页面，详情页展示完整的图文介绍、用户评价汇总以及店铺地理位置导航链接。美食信息查询界面如图4-4所示。

图4-4 美食信息查询界面

4.1.5 门票预订功能实现

　　用户在景点详情页可查看不同票种的价格及适用规则介绍页面，票种通常包含成人票、学生票及老人票等类型。用户选择游玩日期后系统调用库存接口查询该日期剩余票量，库存充足时允许用户输入购票数量。系统根据用户选择的票种组合与购票数量实时计算订单总金额，金额计算过程完整应用门票价格与学生折扣等定价规则。用户确认预订信息无误后点击提交订单按钮，系统生成待支付状态的订单记录并分配唯一订单编号。订单生成后页面自动跳转至支付引导页，用户可选择余额支付或模拟支付完成付款操作。门票预订界面如图4-5所示。

图4-5 门票预订界面

4.1.6 在线聊天功能实现

　　系统构建基于WebSocket协议的双向通信通道实现消息实时推送。用户进入聊天模块后可查看好友列表，好友列表展示已建立联系关系的其他用户账号。聊天界面左侧区域展示历史会话记录列表，按最近消息时间倒序排列。用户选择某一聊天对象后右侧区域加载该会话的完整历史消息，消息按发送时间顺序从上到下排列展示。用户在输入框中填写文字内容后点击发送按钮，前端将消息内容与接收方标识封装为数据帧通过WebSocket连接发送至服务器。服务器接收到消息后查询接收方当前的连接状态，在线状态下立即推送消息，离线状态则将消息暂存至数据库待对方上线后补推。在线聊天界面如图4-6所示。

图4-6 在线聊天界面

4.1.7 评论管理功能实现

　　用户在完成景点游览或美食体验后可在订单详情页或景点详情页发表评论。评论表单包含星级评分组件与多行文本输入框两个核心控件，星级评分采用五颗星样式供用户点选，文本输入框用于撰写具体评价内容。用户提交评论后系统将评分值、评论文本、用户标识及关联目标标识组装为评论记录存入数据库。系统同时更新目标景点的综合评分统计值，统计值通过对所有用户评分取算术平均数计算得到。用户可在个人中心的评论管理标签页查看自己发表过的所有评论记录，每条评论旁边提供编辑按钮与删除按钮。编辑操作允许用户修改评分或评论文本内容，删除操作将彻底移除该条评论并重新计算目标景点的综合评分。评论管理界面如图4-7所示。

图4-7 评论管理界面

4.1.8 景点预订功能实现

　　景点预订模块主要处理景区周边住宿类订单。用户进入预订页面后选择目标住宿设施，系统展示该设施的房间类型列表及各类型对应的价格、可预订数量与设施说明。用户选择入住日期与离店日期后系统自动计算入住天数，实时展示预订总金额。用户需填写入住人姓名、联系电话及特殊需求备注等信息，信息填写完整后提交预订申请。系统校验所选日期范围内的房间余量满足预订数量时生成预订订单，订单初始状态为待审核。用户可在个人中心的预订记录页面查看所有预订订单，待审核状态的订单支持用户主动取消，审核通过的订单展示入住凭证二维码。景点预订界面如图4-8所示。

图4-8 景点预订界面

4.1.9 旅游行程管理功能实现

　　用户进入行程规划页面后可创建新的旅游行程计划。创建流程要求用户填写行程名称、出发日期、返回日期及同行人数等基础信息，系统根据出发与返回日期自动计算行程天数。行程创建完成后用户可在时间轴视图下为每一天添加游玩景点，添加时从景点列表中选择目标景点并设定预计游玩时长。系统后台调用地图距离计算接口获取每日所涉及景点之间的地理通行耗时，在前端界面以提示条形式展示各景点间的移动时间建议。用户可通过拖拽操作调整同一日期内景点的访问顺序，系统自动重新计算路线总耗时。行程编辑完成后用户点击保存按钮将行程数据存储至数据库，已保存的行程支持复制操作用作新行程的模板。旅游行程管理界面如图4-9所示。

图4-9 旅游行程管理界面

4.2 管理员的设计与实现

4.2.1 景点分类管理功能实现

　　管理员登录后台系统后进入景点分类管理模块，页面以树形结构展示当前所有景点分类层级。顶级分类对应景区大类的划分，子级分类进一步细化具体景点所属的区域或主题类型。管理员可执行新增分类操作，新增时需填写分类名称并选择父级分类，系统检测同层级下是否存在重名分类避免重复。编辑分类功能支持修改分类名称或调整分类的父级归属，修改后系统自动更新该分类下所有景点的分类关联路径。删除分类操作前系统执行前置检测逻辑，检查该分类下是否仍关联任何景点记录，存在关联时弹出提示框并禁止删除操作，管理员需先将关联景点转移至其他分类后方可继续执行删除。景点分类管理界面如图4-10所示。

图4-10 景点分类管理界面

4.2.2 景点信息管理功能实现

　　管理员在景点信息管理页面以表格形式查看系统内所有景点记录，表格列展示景点名称、所属分类、门票价格及上架状态等关键字段。页面顶部提供搜索筛选工具栏，管理员可按分类下拉筛选或输入关键词模糊匹配景点名称快速定位目标记录。新增景点操作打开信息填写表单，表单字段涵盖景点名称详细描述、开放时段、具体地址、门票价格体系、交通指南及注意事项等完整信息项。图片上传组件支持管理员上传景点宣传图片，上传后自动生成缩略图用于前端列表展示。编辑操作允许管理员修改已有景点的任意字段内容，下架操作将景点状态标记为已下架，下架后该景点不再出现在普通用户的查询结果中。景点信息管理界面如图4-11所示。

图4-11 景点信息管理界面

4.2.3 景点信息地图功能实现

　　管理员进入景点信息地图模块后页面呈现全幅地图组件，地图上以标记点形式展示所有已标注的景点位置。每个标记点可响应点击事件，点击后弹出信息卡片展示景点名称与当前坐标值。管理员执行新增景点标注操作时需在地图上选择目标位置，系统读取鼠标点击位置的经度纬度坐标并自动填充至标注表单。标注表单同时要求管理员填写景点名称及关联分类信息，提交后系统在数据库中创建该景点的地理位置记录并在地图上生成对应标记点。修正已标注景点坐标时管理员可拖拽地图上现有标记点至新位置，释放拖拽后系统自动捕获新的坐标值并更新数据库记录，同时记录坐标变更日志供日后审计。景点信息地图界面如图4-12所示。

图4-12 景点信息地图界面

4.2.4 景点预订管理功能实现

　　管理员在预订管理模块查看系统中全部住宿类预订订单，订单列表按提交时间倒序排列。列表每条记录展示预订用户账号、住宿设施名称、入住日期区间及当前订单状态。订单状态包括待审核、已通过、已拒绝及已取消四种类型，待审核状态的订单需要管理员人工处理。管理员点击订单进入详情页面，详情页展示完整的预订信息包括入住人姓名、联系电话、特殊需求备注及预订数量。详情页底部提供批准按钮与驳回按钮，批准操作将订单状态变更为已通过并触发短信通知发送给用户，驳回操作要求管理员填写驳回理由，用户端可查看驳回原因并根据建议调整预订方案。已通过的订单若发生用户退订申请，管理员可执行退款审核流程核对入住日期是否已过再决定是否退款。景点预订管理界面如图4-13所示。

图4-13 景点预订管理界面

4.2.5 标签信息管理功能实现

　　管理员维护系统的标签体系，标签用于标注景点的特色属性及美食的口味特征。标签管理页面以列表形式展示所有已定义标签，每条标签记录包含标签名称、标签类型及使用次数统计三个字段。标签类型分为景点标签与美食标签两类，景点标签如历史文化自然风光亲子乐园等，美食标签如麻辣清淡烧烤甜品等。管理员可新增标签，新增时需选择标签类型并填写唯一的标签名称。编辑功能允许管理员修改已有标签的名称，修改后系统自动同步更新所有关联该标签的景点或美食记录。删除标签时系统执行关联检测，存在关联记录时禁止删除操作并提示管理员先解除关联关系后再执行删除。标签信息管理界面如图4-14所示。

图4-14 标签信息管理界面

4.2.6 美食信息管理功能实现

　　管理员在美食信息管理模块对餐饮数据进行全生命周期维护。美食列表页面以卡片或表格形式展示所有已录入的美食记录，每条记录包含美食名称、所属菜系、推荐店铺及审核状态等信息。新增美食操作打开信息编辑表单，表单包含美食名称、口味描述、主要食材、人均消费金额、推荐店铺名称及店铺地址等字段。图片上传组件支持上传美食成品图片及店铺环境图片，上传后图片存储至文件服务器并记录访问路径。管理员可为一个美食条目关联多个标签，从标签选择器中勾选适用的口味标签或菜系标签。已录入的美食信息支持编辑修改与删除操作，删除操作会同时移除该美食与标签之间的所有关联关系。美食信息管理界面如图4-15所示。

图4-15 美食信息管理界面

4.2.7 系统管理功能实现

　　系统管理模块提供平台运行参数的集中配置界面。管理员可配置首页轮播图内容，每张轮播图包含图片文件上传与跳转链接设定两个配置项，轮播图按配置的排序顺序在前端首页展示。用户权限分配功能允许管理员查看普通用户列表，修改用户的账号状态，禁用状态用户无法登录系统。管理员账户管理功能支持新增或移除管理员账号，新增管理员时需分配操作权限范围，移除管理员操作需二次确认防止误删。操作日志功能记录管理员在后台执行的所有增加修改删除操作，日志条目包含操作时间、操作人账号、操作类型及操作对象标识，管理员可查看日志但无权删除或修改日志内容。系统管理界面如图4-16所示。

图4-16 系统管理界面

4.2.8 新闻管理功能实现

　　管理员通过新闻管理模块发布旅游资讯类内容。新闻列表页面展示所有已发布及待发布的新闻条目，列表按创建时间倒序排列便于查看最新内容。新增新闻操作打开富文本编辑器，编辑器工具栏支持文字格式调整、图片插入及段落样式设置等功能。新闻表单包含标题字段、正文字段及封面图片字段，标题限制不超过三十个汉字确保列表展示完整。新闻正文支持图文混排格式，管理员可在正文中嵌入多张图片及外部链接。已发布的新闻展示在前端资讯板块，支持按时间归档浏览。编辑操作允许管理员修改已发布新闻的标题或正文内容，下架操作将新闻状态变更为已下架，下架后新闻不再显示在前端资讯列表同时保留数据库记录供日后查阅。新闻管理界面如图4-17所示。

图4-17 新闻管理界面

结　论

　　目前旅游信息过载问题导致用户很难得到个性化的出行建议，因此本文以该问题为出发点，对基于知识图谱和大语言模型图检索增强的旅游智能推荐系统进行整体研发。研究工作从需求分析开始，确定普通用户与管理员的职责范围，完成系统架构设计、数据库建模、核心功能编码实现、综合测试。使用B/S架构和前后端分离的方式，Web端包含景点地图展示、预订流转、在线互动、行程安排等各个功能模块，后台管理员对景点的分类、位置标注、票务审核、新闻发布进行管理。普通用户经过账户认证之后，依靠推荐查询和筛选机制来获得个性化的内容，整个协同过程运行稳定，功能完备地覆盖了预订、评价、收藏、行程管理等各个环节，系统整体目标得以实现。

　　系统在支付环节使用模拟处理的方式，门票预订和景点预订还没有接入真实的第三方支付接口，智能推荐部分没有对实时用户的物流路径进行优化的算法，用户消费数据的统计分析也还比较浅，云服务器部署环境下的并发访问能力也存在着一定的限制。后续的工作可以把真实的支付网关以及地图API路径优化算法加进去，用用户长期的行为数据来创建更加准确的偏好画像。景区管理者利用该平台可以减少人工咨询费用，游客出行前可得到景点、美食、行程等各方面的综合信息，该方案在智慧旅游服务方面有明显的应用推广价值。

谢辞

　　时光匆匆，四年大学生活即将画上句号，站在毕业的门槛上回望，从论文选题到最终定稿的每一个日夜都历历在目。校内指导教师自始至终保持治学严谨的态度，从选题方向的把握到开题报告的打磨，从系统框架的搭建到论文语言的推敲，老师在每个环节都给予悉心点拨。每当研究陷入理论难点或技术瓶颈时，老师总能以寥寥数语点破迷津，这种平和且坚定的指导方式让整个毕设过程少了许多曲折。

　　论文创作初期面对知识图谱与大语言模型的交叉应用，曾经感到无所适从。通过反复查阅文献与调试代码，那些最初令人困惑的概念逐渐变得清晰可辨。技术实现过程中的一个个障碍被逐一攻克后，系统功能从设想变为现实，这种从迷茫到明朗的转变本身便是一种成长。四年专业学习积累起来的理论素养与实践能力，在这段毕业设计的磨砺中得到检验与提升，知识体系由此更加完整。

　　感谢学院提供的实验环境与学习资源，辅导员的日常关怀与任课老师的谆谆教诲为专业成长奠定了坚实基础。父母一直是求学路上最坚实的后盾，他们用朴素的信任与无私的付出托举起这份学业。即将走出校园踏入社会，未来的道路上将继续保持踏实求索的态度，用所学所长服务于现实需求，不辜负这段求学时光的馈赠。

参考文献

[1] 　　中国电子技术标准化研究院.知识图谱应用实践指南[M].电子工业出版社:202505:506.

[2] 　　钱锋,李文文.基于Vue.js的就业满意度评价设计与实现[J].安徽水利水电职业技术学院学报,2024,24(2):67-73.

[3] 　　龚静,邓晨曦.MySQL数据库项目化教程[M].北京:人民邮电出版社,2023:253.

[4] 　　苏之阳,王锦鹏,姜迪,等.大语言模型[M].机械工业出版社:202409:258.

[5] 　　王大阜.科学知识图谱[M].人民邮电出版社:202311:335.

[6] 　　柯妍,孙佳留,朱士飞,等.基于MySQL的煤质信息数据库设计[J].资源信息与工程,2024,39(3):117-121.

[7] 　　胡劲.数据库信息管理系统的逻辑架构与功能设计探析[J].电脑知识与技术,2023,19(19):96-98.

[8] 　　吕云翔.实用软件工程[M].北京:人民邮电出版社,2024:310.

[9] 　　魏薇. 扬州旅游知识图谱构建方法及其在旅游规划生成中的应用研究[D]. 扬州: 扬州大学, 2025.

[10] 　　张庆. 基于多模态大语言模型数据增强的旅游景点推荐方法研究[D]. 合肥: 合肥工业大学, 2025.

[11] 　　石璇. 基于知识图谱的陶瓷文化乡村特色旅游推荐系统研究[D]. 长沙: 中南林业科技大学, 2025.

[12] 　　滕斯琦. 基于知识图谱嵌入的古都旅游景点推荐[D]. 南京: 南京信息工程大学, 2024.

[13] 　　许洋. 基于知识图谱的旅游路线推荐系统[D]. 呼和浩特: 内蒙古大学, 2022.

[14] 　　邵嘉进, 陈成栋, 陶俊樾, 等. 基于画像的旅游推荐服务实现[J]. 电脑编程技巧与维护, 2021, (7): 147-149.

[15] 　　吴杰. 以事件为中心的旅游知识图谱的构建与应用[D]. 北京: 北京邮电大学, 2021.

[16] 　　Chao Z, Chunhuan W. Research on optimization of personalized tourism recommendation system driven by artificial intelligence[J]. International Journal of Information Systems in the Service Sector, 2026, 16(1): 1-21.

[17] 　　Payandenick M, Othman K M, Payandenick M. A multi-criteria recommendation system for personalised tourism experiences with user query analysis[J]. Information Technology & Tourism, 2025, 28(1): 3.

[18] 　　Karlović R, Rovis M, Smajić A, et al. Context-aware tourism recommendations using retrieval-augmented large language models and semantic re-ranking[J]. Electronics, 2025, 14(22): 4448.

[19] 　　Zheng H, Xu Z, Pan Q, et al.Plugging small models in large language models for POI recommendation in smart tourism[J]. Algorithms, 2025, 18(7): 376.

[20] 　　Hui F, Chongcheng C, Yunfei L, et al.DTCRSKG: a deep travel conversational recommender system incorporating knowledge graph[J]. Mathematics, 2022, 10(9): 1402.

点赞+收藏+关注 → 私信领取本源代码、数据库