基于Llama-Factory的公共交通智能问询系统-平芜编程栈

基于Llama-Factory的公共交通智能问询系统

在城市轨道交通日均客流动辄百万级别的今天，乘客对出行服务的要求早已从“能查到”升级为“秒懂我”。一句“最近的车还有多久来？”背后，可能隐藏着赶飞机的焦虑、带孩子的不便或对换乘路线的陌生。传统客服系统面对这类模糊又高频的提问常常力不从心——要么答非所问，要么层层跳转菜单，用户体验大打折扣。

与此同时，大语言模型（LLM）展现出强大的自然语言理解与生成能力，似乎为这一难题提供了理想解法。但现实是，一个未经训练的通用模型虽然能写诗作画，却很可能告诉你“坐地铁去首都机场需要换乘三次高铁”，这显然无法满足公共服务对准确性和安全性的严苛要求。

真正的突破口，在于让大模型真正“懂公交”。而实现这一点的关键，并非重新训练整个模型，而是通过高效微调技术，赋予其领域知识和专业表达习惯。在这个过程中，Llama-Factory成为了那个“把复杂留给自己，把简单留给用户”的关键推手。

为什么是 Llama-Factory？

市面上并不缺少大模型微调工具，但大多数仍停留在“给开发者用的脚本集合”阶段：你需要自己处理数据格式、手动拼接训练代码、调试分布式配置，甚至要深入 Hugging Face 的源码才能解决兼容性问题。这对交通局信息中心或中小型科技公司而言，门槛太高。

Llama-Factory 的不同之处在于，它不是一个单纯的工具包，而是一套面向工程落地的完整解决方案。它的核心价值不是“支持多少种模型”，而是“能让一个不懂 PyTorch 的工程师，在三天内跑通第一个可用的领域问答原型”。

比如，你只需要准备一份 CSV 文件，里面包含类似这样的问答对：

问题	答案
地铁10号线几点末班车？	北京地铁10号线外环末班时间为22:48，内环为23:00，请根据方向选择乘车。
老年人坐公交怎么收费？	持有北京市养老助残卡的老年人可免费乘坐市域内地面公交线路。

然后上传到 WebUI 界面，选择Qwen-7B模型 +QLoRA微调方式，点击“开始训练”——剩下的事，框架会自动完成分词、指令包装、梯度累积、显存优化等一系列操作。几个小时后，你就拥有了一个初步具备公交领域服务能力的模型。

这种“开箱即用”的体验，正是推动 AI 技术下沉到政务、交通等传统行业的催化剂。

它是怎么做到的？拆解背后的机制

Llama-Factory 并没有发明全新的算法，它的强大来自于对现有技术栈的系统性整合与抽象封装。我们可以把它想象成一个“大模型工厂流水线”：

首先，所有输入的数据都会被统一转换为标准的instruction-response格式。无论原始数据来自工单系统、FAQ 文档还是语音转录文本，最终都变成：

{ "instruction": "解释北京公交老年卡使用规则", "input": "", "output": "持有北京市养老助残卡的65岁以上老人……" }

这个过程看似简单，实则至关重要。很多团队失败的原因，就是直接拿原始语料去训练，导致模型学不会“回答问题”的范式。Llama-Factory 内置了多种模板（template），适配不同场景下的对话结构，确保输出风格一致。

接下来是模型加载环节。这里最惊艳的设计是统一接口抽象。无论是阿里云的 Qwen、智谱的 ChatGLM，还是 Meta 的 LLaMA 系列，都可以用同一套参数命令启动训练。这意味着你可以今天试 Qwen-7B，明天换 Baichuan2-13B，而无需重写任何代码。

更进一步，它对 LoRA 和 QLoRA 的支持堪称“平民化大模型微调”的典范。以 QLoRA 为例，它将 4-bit 量化与低秩适配结合，使得原本需要 8×A100 才能微调的 13B 模型，现在一张 RTX 3090（24GB 显存）就能跑起来。这对于预算有限的地方交通部门来说，意味着不再依赖昂贵的云计算资源。

下面这段 CLI 命令就是一个典型示例：

CUDA_VISIBLE_DEVICES=0 python src/train_bash.py \ --stage sft \ --do_train \ --model_name_or_path qwen/Qwen-7B \ --dataset public_transit_qa \ --dataset_dir data/ \ --finetuning_type lora \ --lora_target q_proj,v_proj \ --output_dir output/qwen7b-lora-transit \ --per_device_train_batch_size 4 \ --gradient_accumulation_steps 8 \ --learning_rate 1e-4 \ --num_train_epochs 3.0 \ --fp16 \ --quantization_bit 4 \ --plot_loss

几个关键点值得细说：
---quantization_bit 4启用了 4-bit 量化，大幅降低显存占用；
---lora_target q_proj,v_proj表示只在注意力机制中的查询和值投影层插入可训练参数，其他权重全部冻结，这样整个模型新增参数不到 0.1%；
---fp16配合梯度累积，可以在小批量下模拟大批次训练效果，避免因显存不足导致学习不稳定。

这套组合拳下来，不仅节省了硬件成本，也让迭代速度大幅提升——一次完整的微调周期可以从几天缩短到几小时，真正实现了“快速试错、持续进化”。

在真实交通场景中，它是如何工作的？

设想这样一个系统架构：

+---------------------+ | 用户交互层 | | (微信小程序 / APP) | +----------+----------+ | v +---------------------+ | 服务网关与API层 | | FastAPI + Nginx | +----------+----------+ | v +---------------------+ | 智能问答引擎 | | 微调后的大模型 SFT-M | +----------+----------+ | v +---------------------+ | 数据与知识源 | | 时刻表 / 票价规则 / | | 运营公告 / 历史QA库 | +---------------------+

当一位乘客问：“明天早上8点从西直门去首都机场最快怎么走？”系统并不会直接把这个句子丢给模型。聪明的做法是先做一次上下文增强。

API 层会主动查询航班信息系统、地铁运行状态数据库，获取如下信息：
- 当前时间：2024年6月18日 15:30
- 机场快轨：正常运行
- 地铁13号线：西段因施工延误5分钟
- 最近一班机场快轨发车时间：15:42

然后把这些动态信息注入提示词中：

prompt = f""" 你是一名专业的北京公共交通客服助手，请根据以下信息回答用户问题。 【当前时间】{current_time} 【可用交通工具】地铁、公交、机场快轨、出租车 【实时状态】机场快轨正常运行，13号线西段有轻微延误 用户问题：{user_question} 请给出具体路线建议，包括出发时间、换乘站点、预计耗时和备选方案。 """

经过微调的模型已经学会了在这种结构化提示下进行推理。它不会凭空编造路线，而是基于已知规则输出如：

“建议您乘坐16:00的机场快轨，从西直门直达首都机场T3航站楼，全程约30分钟。由于13号线存在延误，不推荐经东直门换乘方案。若错过此班车，下一班将于16:15发车。”

这种回答既精准又具解释性，远超简单的关键词匹配系统。

实战中的设计取舍：我们踩过的坑

在实际部署过程中，有几个经验教训值得分享：

1. 别迷信“越大越好”

我们曾尝试用 QLoRA 微调 Qwen-14B 模型，期望获得更强的理解能力。结果发现，在公交领域任务上，其准确率仅比 Qwen-7B 高出不到3%，但推理延迟翻倍，部署成本陡增。最终回归到 7B 级别模型 + 更高质量的数据标注策略，反而取得了更好的综合表现。

2. 安全控制必须前置

有一次模型被问及“怎么逃票”时，竟给出了“可以躲在车厢连接处”之类的危险建议。这提醒我们必须设置严格的system prompt和输出过滤机制。现在的做法是：
- 固定角色设定：“你是一名遵守规定的公共交通客服人员”；
- 输出前过一遍正则规则库，拦截敏感词和非法路径；
- 对涉及金额、时间的回答做合理性校验（如“步行10公里只需5分钟”应被拒绝）。