← → 翻页 · B 静态 · ESC 索引
本科毕业设计答辩 · 2026.05
01 / 15
本科毕业设计答辩

面向海外高校升学信息
检索增强生成系统的设计与实现

Design and Implementation of a RAG System
for Overseas University Admission Information

学 生王浏宇 220344129 专 业信息管理与信息系统 指导教师蔡程飞
Offer-Pilot · 毕业答辩
— 2026.05 —
研究背景与意义 · Background
02 / 15
第一章 · 选题缘由

研究背景与意义

留学申请是高风险、强时效的决策过程。学生面临的不是信息不够多,而是难以核实、难以对比、难以追溯。

  • · 海外院校官网信息分散,学生在多个标签间反复切换
  • · 通用大模型回答"看起来对",但无法核查、无法溯源
  • · 招生政策频繁更新,模型训练数据已过时
  • · 中介信息存在商业偏向,难以做客观对比
出国留学规模
91.3
教育部公开统计数据
官网 JS 动态渲染占比
约 90%
SPA 框架成为主流
研究背景与意义
Research Background
研究动机 · Motivation
03 / 15
为什么不能直接用通用大模型

通用 LLM 的两大根本局限

局限一

知识截止 · Training Cutoff

模型训练数据存在截止时间,而留学政策、申请截止日期、专业要求频繁变动。模型无法获取训练截止后的任何新信息。

局限二

幻觉 · Hallucination

模型以高置信度输出与事实不符的内容。在留学这类高风险决策场景中,看起来合理但错误的答案,远比"不知道"危险。

→ 这两点正是本系统引入 RAG(检索增强生成)的直接动因
研究动机 · Motivation
Why RAG
相关技术 · Related Tech I
04 / 15
第二章 · 相关技术介绍

检索增强生成 RAG

RAG 由 Lewis 等人于 2020 年提出。生成回答前先从外部知识库检索相关文档片段,作为上下文传入 LLM,缓解知识截止与幻觉问题,无需对模型参数微调。

离线索引阶段 · OFFLINE 原始文档 HTML / MD 语义切分 Chunks BGE-M3 嵌入 1024-dim 向量数据库 Neo4j Vector 在线查询阶段 · ONLINE 用户 Query 自然语言 ANN 检索 Top-K 查询向量库 Prompt 拼接 Query + 上下文 LLM Qwen3 带引文的答案 可溯源 · 可核查
本系统嵌入模型:BGE-M3(1024 维,中英文双语) 相似度:sim(q,d) = (q·d)/(‖q‖·‖d‖)
相关技术 · RAG 基础流程
Retrieval-Augmented Generation
相关技术 · Related Tech II
05 / 15
第二章 · 相关技术介绍

混合检索 + 知识图谱

BM25 · 全文检索

基于词频统计的概率检索模型,对专有名词、缩写、数字(如 GMAT、IELTS 7.0)有精确匹配优势,弥补向量检索语义近似的不足。

RRF · 互惠排名融合
RRF(d) = Σ 1 / (k + rank_i(d)),k = 60

按排名而非分数融合,自然消除两路检索分数量纲差异,工程实践中应用广泛。

知识图谱 + GraphRAG

以三元组 ⟨主体, 谓词, 客体⟩ 存储实体关系。GraphRAG 将跨文档推理转化为图路径遍历,对"跨校比较 / 多跳推理"类查询更可解释、更易追溯

GraphRAG 多跳推理示意
Imperial University UCL University CS MSc Program AI MSc Program CS MSc Program IELTS 7.0 Requirement GPA 3.5 Requirement IELTS 6.5 Requirement HAS HAS REQ REQ 紫色路径 = 一次跨校比较查询的多跳遍历
院校 项目 要求
相关技术 · 混合检索 · 知识图谱
BM25 · RRF · KG · GraphRAG
相关技术 III · Stack
06 / 15
第二章 · 相关技术介绍

爬虫 · 前后端技术栈

数据采集 · Firecrawl
无头浏览器爬虫

海外院校官网普遍采用 React / Vue 等 SPA 框架,传统爬虫拿到的是空壳 HTML。无头浏览器先执行 JS 渲染,再抽取正文并输出结构化 Markdown。

后端 · Python · FastAPI
异步 API 服务

采用现代 Python 异步 Web 框架,提供 RESTful 接口与流式响应能力,承载检索、问答、管理等业务逻辑。

前端 · Next.js + React
现代化 Web 前端

基于 React 组件化开发,Next.js 提供路由与服务端渲染能力。Node.js 作为运行环境,前端通过 SSE 实时接收回答流。

数据存储
关系库 + 图数据库

PostgreSQL 存储用户与会话;Neo4j 同时承载文档向量、全文索引与实体图谱,简化跨索引一致性管理。

相关技术(三)· 爬虫 · Next.js / React · 后端
Related Tech III
系统设计 · Architecture
07 / 15
四层架构

系统总体架构

前端层 · Frontend
Next.js + React · 登录 / 对话 / 管理界面 · SSE 流式渲染 · 引文卡片展示
↕ HTTP / SSE
服务层 · API Layer
FastAPI 异步服务 · Router → Service → Repository · JWT 鉴权 · 检索与问答逻辑
↕ SQL / Cypher / HTTP
数据层 · Data Layer
PostgreSQL 存储用户与会话 + Neo4j 同时承载向量索引 · BM25 全文索引 · 知识图谱(三索引同库)
↕ Firecrawl API
采集层 · Ingestion
无头浏览器爬取 SPA 官网 → 清洗为结构化 Markdown → 分块 → 向量化 → 实体抽取入库
系统总体架构 · Four-Tier
第四章 · 系统设计
核心实现 · Data Ingestion
08 / 15
数据来源 · Phase 01

院校官网数据采集

海外院校官网约 90% 基于 SPA 框架动态渲染,传统 HTTP 爬虫只能拿到空壳 HTML。

解决方案 · Firecrawl

  • · 底层无头浏览器,完整执行 JS 渲染
  • · 自动清洗导航、页脚、广告等非主体内容
  • · 输出 LLM 友好的结构化 Markdown
  • · 支持单页精准抓取 + 站点级联爬取
采集流水线
院校 URL 列表
Firecrawl 渲染 + 清洗
Markdown 分块 + BGE-M3 嵌入
LLM 抽取三元组写入 Neo4j
数据采集流水线 · Firecrawl Ingestion
第五章 · 系统实现
核心实现 · Hybrid Retrieval
09 / 15
检索管道 · Hybrid Retrieval + RRF

混合检索管道

用户 Query 自然语言 STEP 01 向量 ANN 检索 BGE-M3 · 语义近邻 覆盖同义改写 STEP 02 BM25 全文检索 Lucene · 词法匹配 覆盖专名 · 缩写 · 数字 STEP 03 并行 RRF 融合 按排名融合 k = 60 STEP 04 Cross-Encoder BGE · 精排 STEP 05 Top-K → LLM
STEP 01
意图识别,NER 抽取院校名,判断单校/对比查询模式。
STEP 02
BGE-M3 编码为 1024 维向量,ANN 召回语义近邻,覆盖同义改写。
STEP 03
并行执行 BM25,精确匹配专名、缩写、数字,弥补向量检索短板。
STEP 04
RRF(k=60) 按排名融合两路结果,自动消除分数量纲差异。
STEP 05
BGE Cross-Encoder 精排候选集,取 Top-5 传入 LLM 生成答案。
混合检索管道 · Hybrid Retrieval Pipeline
第五章 · 系统实现
代码实现 · Code Highlight
10 / 15
graph_retriever.py

核心:混合检索器

# 1. 意图识别:NER 抽学校 + 对比关键词 unis = extract_universities(query) compare = is_compare_query(query) # 2. 并行双路 Cypher 查询 vec_rows = _vector_search(session, embedding) bm_rows = _bm25_search(session, q_escaped) # 3. RRF 融合(超参 k=60) fused = rrf_fuse([vec_ids, bm_ids], k=60) # 4. 跨校配额(多校对比模式) if compare: candidates = bucket_allocate(fused, unis) # 5. BGE Cross-Encoder 精排 results = bge_rerank(candidates, query, top_k=5)
代码解释

① 意图识别 — 调用 NER 模型抽取查询中的学校实体(如"Imperial"),同时检测是否包含对比关键词("对比"、"哪个更好"),判断查询模式(单校/多校/开放)。

② 并行双路查询 — 在 Neo4j 中同时执行向量检索(db.index.vector.queryNodes)与 BM25 全文检索(db.index.fulltext.queryNodes),两路异步并行减少串行延迟。特殊字符转义防止 Lucene 注入。

③ RRF 融合 — 将两路结果按排名融合(k=60 超参来自工程实践),自动去重、合并候选集,避免单一检索策略的局限性。

④ 跨校配额 — 若检测到多校对比查询,对融合结果按学校分桶(bucket),确保每校至少分配 2 个候选文档,避免单校垄断 Top-K。

⑤ 精排 — 调用 BGE Cross-Encoder 重排序候选集,计算 Query 与每个候选的语义相关度得分,取 Top-5 传入 LLM 生成最终答案。

代码实现 · 混合检索器
graph_retriever.py
系统实现 · UI
11 / 15
全栈系统实现

系统界面展示

完整实现从用户登录、个人背景采集、对话问答,到后台学校与用户管理的全流程功能。

登录页面
个人背景向导
个人背景优化
主对话界面
学校管理
文件上传与咨询
系统实现 · 界面展示
第五章 · 系统实现
实验验证 · Evaluation
12 / 15
第六章 · 系统测试

关键实验数据

在 60 道领域专项问答对上,对比通用大模型基线 DeepSeek-V3 与本系统的端到端效果。

DeepSeek-V3 基线
Offer-Pilot 本系统
事实准确率↑ 越高越好
base
58.3%
ours
85.0%
幻觉率↓ 越低越好
base
41.7%
ours
11.7%
截止日期准确率↑ 越高越好
base
27.8%
ours
88.9%
引文率(可溯源)↑ 越高越好
base
0%
ours
100%
检索 Hit@5↑ 越高越好
base
ours
0.867
· 测试集:60 道由人工编写的留学领域问答对,覆盖 9 所目标院校 · 基线模型:DeepSeek-V3(同一时间窗、同一提示词)
实验验证 · End-to-End Evaluation
60 题集 · 对比基线
核心结论 · Conclusion
13 / 15
第七章 · 核心结论

核心结论

本研究围绕"让大模型在留学场景下回答更可信、更可查、更贴合个体",完成了一套可运行的端到端系统。

结论 ①
RAG 有效抑制幻觉

引入检索后,回答均来自真实文档片段,并附引文链接,显著优于直接调用通用大模型。

结论 ②
知识可追溯、可更新

通过爬虫定期采集官网,知识库可持续更新,避免大模型训练截止带来的过时问题。

结论 ③
端到端可用

从前端登录到后端检索、从普通用户到管理员的完整业务闭环,验证了方案的工程可行性。

核心结论 · Conclusion
第七章
创新点 · Contributions
14 / 15
论文创新点

主要创新点

01
面向 SPA 官网的数据采集方案

针对海外院校官网普遍采用动态渲染、传统爬虫失效的问题,采用无头浏览器方案获取真实正文,并清洗为 LLM 友好的结构化 Markdown。

02
RAG 与知识图谱融合的留学问答

将文档检索与院校—项目—要求三元组结合,回答既能精确引用原文,又能沿图谱关系完成"跨学校 / 多条件"类比较,答案可溯源

03
个人背景驱动的个性化回答

通过个人背景向导收集学生画像并注入对话上下文,使系统输出"针对你"的建议,区别于通用问答机器人。

主要创新点 · Contributions
第七章
致谢 · Acknowledgements
15 / 15
致谢

谢谢各位老师

感谢指导教师蔡程飞老师在选题、技术路线与论文写作上的悉心指导; 感谢答辩委员会各位老师在百忙之中评阅本论文; 感谢同学与家人一路以来的支持与陪伴。

恳请各位老师批评指正

王浏宇 · 220344129 · 指导教师 蔡程飞
— 2026.05 —