AL Airways 智能助手：RAG 驱动的航空客服机器人

AL Airways 智能助手的 Web 聊天界面，蓝色航空主题设计

---

你有没有遇到过这种崩溃时刻？

凌晨两点，你坐在候机厅，航班取消通知刚弹出来。你打电话给航空公司客服，等了 47 分钟，对面永远是忙音。你发邮件，回复要等 48 小时。你想问一句"我的航班改签要收费吗"，翻遍官网也没找到答案。

AL Airways 智能助手（AL Bot）就是来解决这个问题的——一个基于检索增强生成（RAG）技术的航空公司专属 AI 客服。它能秒级回答乘客关于行李、票务、退款、餐食、服务政策的各类问题，不需要人工介入，也不需要排队等待。

这个项目来自印度尼西亚泗水的开发者 thameemhub，是作者为了演示 RAG 在垂直领域落地而构建的完整 Demo 系统。虽然目前 star 数不多（53），但其架构设计清晰、实现完整，对于想学习如何用 RAG 改造传统行业的开发者来说，是一个非常值得研究的参考案例。

---

为什么航空客服特别适合用 RAG？

航空行业的知识库有个显著特点：体量大、更新频繁、格式规范。航空公司有几十上百份政策文档——行李规定、票务规则、特殊乘客服务条款、危险品运输说明——这些内容既不适合塞进大模型的上下文窗口（Context Window），也无法靠模型自己记住（模型知识有截止日期）。

RAG（Retrieval-Augmented Generation，检索增强生成）的核心思路就是：让模型先检索，再生成。用户提问时，系统先从知识库中找出最相关的文本片段（Chunks），再把这些片段作为上下文喂给语言模型，让模型"照着原文回答"。这样既保证了答案的准确性（来自真实政策文档），又保留了自然语言生成的流畅性。

这个项目的数据目录里包含 18 份 PDF，涵盖行李政策、航班取消与延误、餐饮服务、特殊物品托运、安全检查、公司概况等航空公司常见场景。每个 PDF 都经过分块（Chunking）处理后存入向量数据库。

---

技术架构：朴实但实用的三层设计

项目的代码结构非常直接，体现了"先跑通、再优化"的工程思维。

AL-RAG-CHATBOT/
├── backend/           # Flask 后端
│   ├── pdf_loader.py   # PDF 文本提取
│   ├── chunker.py      # 文档分块（500字符/块，50字符重叠）
│   ├── embeddings.py    # 文本向量化（基于 SHA256 哈希，非真实 Embedding）
│   ├── vector_store.py  # 向量存储与检索（sklearn TfidfVectorizer + NumPy 点积）
│   ├── intent_classifier.py  # 意图识别（关键词规则匹配）
│   ├── answer_generator.py   # 答案生成（Flan-T5-base 模型）
│   ├── ingest.py       # 数据导入脚本
│   └── app.py          # Flask API（/chat、/metrics）
├── frontend/           # 原生 HTML/CSS/JS 聊天界面
│   ├── index.html      # 主页面
│   ├── style.css       # 蓝色航空主题样式（带动画）
│   ├── script.js        # 前端逻辑（Fetch API 调用后端）
│   └── chatbot.jpg      # 机器人头像
└── data/               # 18 份 PDF 政策文档

向量检索层（最值得关注的创新点）

这里有一个非常有趣的设计决策：作者没有使用真实的 Embedding 模型（如 sentence-transformers），而是使用了基于 SHA256 哈希 + 维度填充的方式构造伪向量。

具体来说，代码将文本的 SHA256 哈希值（32 字节）转换为 np.uint8，再 pad 到 384 维，然后用 NumPy 点积计算相似度。这个方法的优点是速度快、无需 GPU，缺点是精度较低——哈希相似度并不能真正反映语义相似性。这更像是"字符串匹配"的向量版本，在严肃生产环境中应该替换为真实的文本嵌入模型（如 sentence-transformers/all-MiniLM-L6-v2）。

检索阶段使用的是 sklearn 的 TfidfVectorizer（TF-IDF），配合 NumPy 点积计算 Top-3 相关文本块。TF-IDF 相比纯哈希向量的语义理解能力要强一些，但仍然无法捕捉同义词、多义词等语义层面的关系。

答案生成层

使用 google/flan-t5-base 模型（Hugging Face text2text-generation pipeline）生成最终答案。Prompt 中要求模型"仅使用提供的上下文作答"，并以"友好的航空公司语气 + emoji"回复。意图分类器会先对问题进行分类（greeting / food / logistics / policy），如果是打招呼或常见问题（如"有什么吃的"），直接返回预设回复，绕过 LLM 生成以提升响应速度。

---

部署体验：能跑起来，但要手动调

依赖安装

项目提供了 backend/requirements.txt 和 PACAKGES_TO_BE_DOWNLOADED.txt，核心依赖：

torch
transformers
sentencepiece（Flan-T5 依赖）
python-dotenv
pypdf
numpy
scikit-learn

最重的是 PyTorch + Transformers（Flan-T5-base 约 890MB），如果用 CPU 推理，首次加载模型可能需要 3-5 分钟。

启动流程

# 1. 安装依赖
pip install -r backend/requirements.txt

# 2. 导入 PDF 数据（首次）
cd backend
python ingest.py
# 输出: 加载 PDF → 分块 → 保存向量库（vector_store.pkl）

# 3. 启动后端
python app.py
# Flask 运行在 http://127.0.0.1:5000

# 4. 打开前端
# 直接用浏览器打开 frontend/index.html
# 前端通过 Fetch API 调用 http://127.0.0.1:5000/chat

注意：由于前端 script.js 中硬编码了 http://127.0.0.1:5000 作为后端地址，如果前端不是从同一台机器访问，需要修改此处。

容器化支持

没有 Dockerfile 或 docker-compose.yml。生产部署需要自己编写 Dockerfile，建议基于 python:3.10-slim 镜像，分阶段构建以减小镜像体积。

Web UI

有，界面质量还不错。蓝色航空主题，带打字动画、用户/机器人消息气泡区分、头像展示、CORS 已正确配置。配色和动效（标题 flyIn、文字浮动）都体现了航空出行的专业感。

---

局限性与改进建议

1. 语义检索能力弱：SHA256 哈希伪向量无法处理同义词（如"托运"和"行李"）。建议替换为 sentence-transformers/all-MiniLM-L6-v2，仅需额外安装约 90MB 模型。

2. 意图分类过于简单：纯关键词匹配，覆盖有限。建议微调一个轻量分类模型或使用 few-shot prompting。

3. 无流式输出：答案生成完成后一次性返回，用户等待时间较长。可接入 Flask 流式响应或 WebSocket。

4. PDF 解析依赖 PyPDF：对扫描版 PDF（图片格式）无能为力，需接入 OCR 管道（如 PaddleOCR）。

5. 向量数据库用 pickle：pickle 无法跨进程共享，生产环境建议换 ChromaDB 或 Qdrant。

---

总结

AL Airways 智能助手是一个麻雀虽小、五脏俱全的 RAG 行业应用 Demo。它的价值不在于技术多前沿，而在于完整展示了 RAG 落地的全链路：PDF → 分块 → 向量检索 → Prompt 组装 → LLM 生成 → Web UI 展示。

对于 AI 爱好者，这个项目能让你直观理解 RAG 各环节的工作原理；对于开发者，它提供了可借鉴的 Flask + React-free 前端分离架构，以及用 metrics 模块做 LLM 调用统计的方法。核心改进方向明确——替换语义向量模型、增加流式输出、完善意图分类——每一步都有清晰的升级路径。