Django+LLM大模型的滴滴出行分析与出租车供需平衡优化系统设计

每年准备毕业设计的同学里，总有一批人会盯上网约车和出租车数据。滴滴早在几年前就开放过规模不小的订单轨迹数据集，加上天气、节假日、POI这些公开数据源，做出来的分析系统既贴近生活场景，又能把数据清洗、时序预测、可视化这些硬技能全串起来。我陆陆续续带过好几个做这个方向的学生，自己也把供需平衡这块完整复现过一遍，今天这篇就把整个《Django+LLM大模型滴滴出行分析 出租车供需平衡优化系统》从题目拆解到答辩演示，一条线捋清楚，帮拿到这个题目的同学说说哪些环节千万别踩坑。

这个题目乍看是“大数据毕业设计”，本质上其实是一个**“时空数据分析+业务建模+系统集成”**的三层结构。出租车供需平衡优化的核心问题很简单：某些区域在某些时段，乘客打不到车，而司机却在旁边空驶绕圈。做系统不是为了炫技，而是要让平台运营者或城市管理者能直观看到错配发生的时间、地点和原因，然后给出一组可执行的调度建议。LLM大模型在这个系统里承担的是“解释和建议”层，而不是硬去替代时序预测模型，这是后面所有设计的出发点。

这篇内容主要面向两类人：一类是已经拿到这套源码和文档、准备快速跑通并弄懂逻辑的同学；另一类是准备自己做网约车或出租车方向选题、正在想架构和技术栈的人。我会先讲清楚供需失衡这个业务问题怎么被量化，再拆系统的整体架构，然后进到Django和LLM的具体实现细节，最后把答辩和演示需要注意的实务经验放出来。

1. 题目拆解：三个关键词分别扛什么活

1.1 供需失衡本质上是“时空错配”，不是单纯运力不够

做这个系统之前，我一直提醒学弟学妹先把业务模型想明白。出租车供需问题不能简单说“车不够”，因为高峰期全市平均来看可能运力是够的，但局部区域瞬时需求飙高，司机从周边过去需要时间，这就产生了供需剪刀差。典型场景就是晚高峰的CBD、雨后的大型商圈、演唱会散场后的体育馆周边，这些地方的应答时长和取消率会显著高于城市均值。

从数据处理的角度看，供需状态的原始表达非常简单：每一个订单都有起点坐标、起点时间、终点坐标、是否完成、从发单到应答的等待时长。把订单按空间网格+时间窗口做聚合，就能得到每个格子每段时间内的需求量；再把司机轨迹数据按同样方式聚合，就能得到运力供给量。供需差、需求满足率、平均等待时长都是在这个聚合结果上计算的。

我给学生画过一张很直白的图：把城市切成1公里×1公里的网格，时间切成15分钟一个窗口，每格里有两个数字——需求订单数和可接单车辆数。系统的第一层价值就是把这个二维矩阵算出来，剩下所有预测和优化都建立在这个矩阵之上。

1.2 Django、LLM和大数据在系统中的分工

三个关键词在标题里是并列的，但在系统里它们的职责完全不同：

• Django是整个系统的骨架，负责MTV架构、ORM数据模型、REST API、后台管理和Web页面渲染。所有分析结果、预测结果、LLM生成的内容都要通过Django统一输出到前端大屏。
• 大数据侧重数据处理和分析链路，包括Pandas清洗、Hive或ClickHouse式的聚合查询思路、基于时间序列的预测模型，以及最终的可视化呈现。毕设场景不需要上真正的分布式集群，但“大数据”的思路要体现为“能处理大规模订单数据并提取有价值指标”的能力。
• LLM大模型是这个题目近几年新加进来的亮点，它承担的是传统分析系统做不了的事情：把冷冰冰的指标表格翻译成人类能理解的业务洞察，回答“为什么这个区域出现供需失衡”这类归因问题，并生成具体的运力调度建议文本。

我见过不少翻车的毕设，问题就出在把LLM硬塞到预测环节。LLM去做纯数值预测，既慢又不稳定，而且评委一问就露馅。正确做法是：数值预测交给树模型或深度学习模型，LLM站在模型结果之上做语义理解和文本生成，两者各干各的活。

1.3 为什么这个选题在毕业设计市场里热度这么高

从带学生的经验来看，这个题目受欢迎有几个很现实的原因。第一，数据题材好讲，网约车和出租车的供需问题全社会都有体感，开题报告和答辩都能轻松讲清楚背景；第二，技术栈覆盖面广，从数据库设计到后端API再到前端可视化，再到模型训练和LLM调用，几乎把本科阶段能用的技术都串了一遍，工作量表很好写；第三，可扩展性强，同一个数据管道加一个模块就能变成景区客流分析、共享单车调度、外卖骑手热力分析，改题成本低。

这些特点决定了一件事：拿着源码跑通只是起步，你要真正理解数据是怎么流动的、LLM是在哪个环节介入的、系统怎么回答业务问题的，否则OpenCV类的“PPT式集成”一眼就会被导师看穿。接下来我把整套系统的搭建步骤和实现原理按实战顺序完整过一遍。

2. 数据工程：订单轨迹如何变成供需指标

2.1 数据来源与字段设计

做网约车分析常用的公开数据有两类：一类是滴滴盖亚数据计划开放的部分城市订单和轨迹数据，另一类是TLC纽约出租车数据。国内毕设场景绝大多数用滴滴盖亚的几个城市子集，我这边复现用的也是这类数据。订单数据核心字段包括订单ID、司机ID、乘客ID、开始时间、结束时间、起点经纬度、终点经纬度、正常计价时长、计价里程。如果拿到的是轨迹数据，那还需要按时间序列拆出每辆车的行驶方向变化。

数据库表设计上我建议按五张表来做，职责分明：

大多数毕设代码里会直接落一个宽表，叫agg_15min之类的派生表。宽表虽然查询快，但业务语义不清晰，如果要加新指标还得改表结构。我一般还是推荐拆窄表再用视图层聚合。Django的ORM在跨表查询上性能可以接受，因为毕设数据量一般就几百万行，加好索引之后完全不用担心。

2.2 时空聚合：向后兼容的网格划分

网格划分是这个系统数据链路的第一个关键决策点。1公里方形网格的做法实现简单、用经纬度整除就能算，但存在边界效应——某辆在网格边缘的车可能离乘客只有100米，却因为位置编码落到了邻居格子。更合理的做法是使用H3六边形网格，Uber开源的那套方案，边界误差更小，而且天然支持多级分辨率。

我个人建议直接采用H3的resolution 7作为聚合粒度，每格大约1.2平方公里，对应城市15分钟级的供需分析正好合适。Django代码里加一个h3-py依赖，把原始经纬度转成H3索引，再按索引和15分钟时间窗口做group by，逻辑干净又高效。如果是赶工图快，也可以用Geohash，它能精确到米级但跨格跳变比H3更频繁，绘图时不够平滑。

2.3 数据处理链路：从CSV到模型输入的完整管道

实际数据处理流程我拆成四步：

1. 数据清洗：去掉经纬度为0、时间异常、订单状态非正常的脏数据；同一司机ID在同一时间窗口的重叠订单要去重。
2. 特征工程：对时间戳拆出小时、星期、是否节假日、是否为早晚高峰标记；对网格坐标补出该区域的POI密度、周边小区数、商圈距离等静态特征。
3. 供需聚合：按H3网格+15分钟窗口聚合，计算每格需求数、供给数，然后算供需指数。
4. 模型数据集构建：把历史N个时间窗口的供需指标拼成滑窗特征，未来一个窗口的值作为预测目标，按时间顺序切训练集和测试集，避免随机切分造成数据泄漏。

这里要特别注意一条纪律：模型训练只能用过去预测未来。很多人直接把数据随机打乱训练，调参调出来效果很好，结果一拿给导师看就被质疑，因为测试集里混着未来的信息。时序项目切数据集必须按时间截点来，比如用前75%时间窗口做训练、后25%做验证，模型选型和评估全在时间轴上操作。

3. 供需不平衡度量与预测建模

3.1 核心指标：供需指数怎么算才不虚

供需平衡需要一个可量化、可比较的指标。常用的定义是每个时空格子内“需求订单数/可用车辆数”的比值，但直接用订单数做分母是不对的，因为需求本身是和运力互相作用的——运力充足时需求会被释放，运力不足时一部分乘客直接放弃叫车，你不会看到这部分隐性需求。所以业界更常用的做法是结合实际完成订单量和接单率来反推需求规模。

我在这套系统里用的定义是：

supply_demand_ratio = total_demand_orders / max(active_supply_vehicles, 1)

其中total_demand_orders不是当天总订单量，而是该时间窗内的“发单请求数”，包括最终被取消的单；active_supply_vehicles是网格内空闲或即将空闲的车辆数。当比值大于阈值（比如2.0）时标记为供不应求，低于阈值时标记为运力过剩。

为让失衡程度更直观，可以构造一个区间在0到1之间的指数：

imbalance_index = (supply_demand_ratio - 1) / (supply_demand_ratio + 1)

这样正值表示供不应求，负值表示供给过剩，范围天然对称。这个指数在时间轴上画出来，能清楚看到早晚高峰的错配形态。

3.2 时序预测：树模型为主、深度学习为辅

需求预测是这个系统的技术核心之一。预测对象可以选网格级的订单量，也可以选城市级总需求，前者空间维度高、单个格子序列噪声大，后者序列平滑但丢失调度场景。毕设层面我建议采用折中方案：先做城市级需求总量预测，再把总量加上历史空间分布比例，下推回网格级。

模型选择上，我用过Prophet、LightGBM、LSTM三个方案对比下来，LightGBM在这个场景是性价比最高的，理由很实在：

• 特征工程友好的离散特征（小时、星期、节假日）树模型天然能处理；
• 对2019年疫情前后的市场突变，树模型在短周期特征上的适应速度快于LSTM；
• 训练时间短，一台普通笔记本就能跑十几个城市级别模型。

Prophet看着是时序专用，但对节假日和突发事件的建模太粗，预测曲线的峰值比真实值平滑很多；LSTM表现中规中矩，但特征归一化和调参成本高，如果论文里没有充足分析和对比，容易被评委追问细节。我的建议是主模型用LightGBM，同时跑一个Prophet做对比曲线，展示出你比较过不同方案的能力。

3.3 LLM在预测之外的增值场景

把预测结果交给LLM之前，需要先准备一套归因知识库。这个知识库可以预置一些规则和相关指标，比如“周日17:00-19:00商圈周边POI密集区供需指数偏高”，LLM拿到实时聚合结果后，会从知识库里抽取相关因素，生成一段自然语言解释。这比直接甩一个数字给用户有用得多，也是系统在答辩时最容易被记住的亮点。

实际操作时，可以把当天各网格的供需指数计算好，拼成一段JSON，然后让LLM从以下角度分析：

• 供需失衡最严重的3个区域及其共性特征
• 与上周同期相比的变化幅度、可能的原因
• 建议的调度策略，比如从闲置率高的区域引导多少辆车过去

这一步利用的是LLM的上下文理解和生成能力，不需要它做任何数值推理，避免让大模型算错数这种尴尬局面。数值都是后端算好的，LLM只负责“好看地说话”和“解释”。

4. Django系统实现：从ORM模型到可视化大屏

4.1 MTV代码组织与核心模型

用Django做这套系统，项目结构我建议按模块切分，而不是堆在一个app里。推荐分出四个app：

• analysis：承载数据聚合和指标计算逻辑
• predict：模型训练、预测调度和结果缓存
• llm_service：封装与大模型接口的交互
• dashboard：可视化页面和API接口

模型层的核心可以落在analysis里。定义一个GridStat模型，代表每个网格每个时间窗口的聚合数据：

class GridStat(models.Model): h3_index = models.CharField(max_length=32, db_index=True) time_window = models.DateTimeField(db_index=True) demand_count = models.IntegerField() supply_count = models.IntegerField() imbalance_index = models.FloatField() create_time = models.DateTimeField(auto_now_add=True) class Meta: indexes = [ models.Index(fields=['h3_index', 'time_window']), ]

这个模型是系统所有查询的核心入口。大屏上的热力图、柱状图、趋势线，底层全是按不同维度对这个表做group by。索引建对了，查询速度才有保障。

4.2 异步任务链：定时预测与WebSocket实时推送

为了让系统有“实时分析”的感觉，不能每次页面刷新都现算指标，必须有一个定时任务管道。我用的是Celery + Redis的经典组合：定期任务每15分钟拉一次最新订单数据，跑聚合计算，写库，更新预测模型缓存，把结果通过WebSocket推给前端页面。

这里有个实现细节容易被忽略：Django默认的同步ORM在Celery的异步任务里调会阻塞事件循环。如果你用了Django Channels的WebSocket，建议在异步消费者里用database_sync_to_async包一层，或者干脆把推送给前端的数据从Redis缓存里读，不直接查库。我踩过的坑就是WebSocket连接建立后，第一次查库直接把事件循环卡了几秒，前端所有推送全部乱序，后来改成从Redis读最近一轮结果才稳定下来。

Django Channels的消费者核心逻辑类似这样：

class DashboardConsumer(AsyncWebsocketConsumer): async def connect(self): await self.accept() self.group_name = 'dashboard' await self.channel_layer.group_add(self.group_name, self.channel_name) async def push_data(self, event): await self.send(text_data=json.dumps(event['data']))

然后Celery任务里算完指标，通过channel_layer.group_send往这个组里扔数据就行。前端收到后直接刷新ECharts图表的setOption，大屏就是这样“动”起来的。

4.3 LLM模块的接口封装与提示词设计

LLM模块建议独立封装一个llm_client.py，对外只暴露analyze_imbalance(data_json)和generate_suggestions(context)两个函数，底层用哪个大模型都可以，方便在答辩现场切换模型。默认实现可以走OpenAI兼容接口，也可以在本地用Ollama跑Qwen等开源模型。

提示词设计对输出质量影响极大，我贴一个实际调优过的模板结构：

你是一位城市运力调度分析专家。以下是某城市在最近15分钟内的供需聚合数据（JSON格式）： {data_json} 请基于数据完成以下任务： 1. 指出供需失衡最严重的三个区域及其特点； 2. 结合历史同期数据进行归因分析，说明可能的原因； 3. 提出具体可执行的运力调度建议，按优先级排序。 要求：语言简洁专业，不超过500字。

注意这里没有让LLM计算任何数值，所有结论都基于输入JSON里的指标，所以它的输出大部分情况下是准确且可信的。答辩时评委问“大模型在系统里的价值是什么”，你就可以很坦然地讲：它负责把结构化数据翻译成决策者可读的建议，并生成归因假设，而不是参与数值计算。

5. 可视化大屏与交付演示：别让答辩毁在演示细节上

5.1 大屏页面布局与地图呈现

可视化是毕业设计最直观的分数来源。我建议大屏按三列布局：中间是城市热力地图，展示当前时段供需指数分布，红色表示供不应求、蓝色表示供给过剩；左侧放订单量趋势曲线和预测对比图；右侧放供需不平衡Top10榜单和LLM生成的调度建议文本。

地图用ECharts的bmap或map系列，把H3网格渲染成多边形热力图。颜色映射建议用红色系表示需求大于供给，蓝绿色表示供给大于需求，中间色表示平衡，这样一眼就能看出问题区域。地图上的数据来自API接口，地址类似/api/v1/grid_stats/?window=2024-01-15 18:00:00，Django的DRF写起来干净利落。

预测模块单独放一个对比图，画两条线：历史上真实订单量与模型预测值，并标注RMSE和MAPE。这里不需要做得太复杂，但一定要让人看出模型“预测得差不多”，而不是画了一堆看不懂的曲线。

5.2 演示前检查清单：从数据到模型再到LLM

答辩演示最容易翻车的环节有三个，我逐个说：

第一，数据过旧或为空。如果数据库里只导入了两个月前的数据，演示时点开实时大屏会发现所有数据都是静止的。解决办法是初始化时把数据时间改为“最近一段时间”，让趋势图和热力图看起来像活的。

第二，模型预测结果不加载。预测模型如果每次答辩前重新训练，很容易因环境差异导致性能下降甚至直接报错。正确做法是把训练好的模型缓存为文件或存入Redis，页面加载时直接读取预测结果，后台异步重新训练。

第三，LLM接口超时。大模型API在网络波动时有概率长时间无响应，页面因此卡死，这种情况非常被动。必须在Django视图层加超时和降级逻辑——LLM调用超过8秒就返回一条预设的缓存建议，保证页面永远有内容可看。

5.3 源码复现时的高频报错与修复

拿到这套源码，照着作者文档跑，基本上会有三个高频报错点：

• Python版本不匹配。老版本Django项目对3.10以下有兼容问题，但新版Django 5.x又要求Python 3.10以上。建议直接建Python 3.10的虚拟环境，装requirements.txt之前先看Django版本再决定。
• MySQL时区问题。聚合表按15分钟窗口分组时，如果MySQL和Django的时区设置不一致，会出现整点结果对不齐。保险做法是全局设UTC，展示层再转本地时间。
• H3依赖安装失败。h3-py在某些Windows环境需要预编译二进制，解决方案是安装h3-py之前先装Microsoft C++ Build Tools，或者直接改用Geohash库绕开。

这些问题大多不是代码逻辑问题，是环境问题。冷静下来看报错栈，往往一条命令就能解决。

6. 论文、PPT与答辩论点：让评委觉得你“懂业务”

6.1 论文写作主线：问题驱动而非技术堆砌

写论文时很多同学喜欢先讲Django多好、LLM多强，再讲自己用了哪些技术，这是评委最反感的写法。好的主线应该是问题驱动的：先讲出租车供需存在什么样的时空错配问题，再推导出要量化这个错配需要哪些数据和指标，进而推导出需要怎样的系统来监控和辅助决策，最后落到Django和LLM如何支撑这套系统。

这样一来，Django是解决业务问题的工程框架，LLM是解决解释与建议问题的智能助手，两者都在业务链条上找到位置，而不是两个孤立的“技术亮点”。

6.2 论文结构建议与每个章节的“废话禁区”

我建议论文按七章走：绪论、相关技术介绍、系统需求分析、系统设计、系统实现、系统测试、总结展望。其中第三章“需求分析”是答辩印象分的重要来源，一定要包含用例图和数据流描述；第四章“系统设计”要把数据库表结构、接口设计、模型训练流程放进去；第五章“系统实现”多放截图和核心代码片段。

写这类技术论文尤其要避开的雷区是“大段全抄官方文档介绍”。Django和LLM的技术介绍写三页可以，但必须落回到你这个系统里，比如讲Django的ORM时顺手带出GridStat表的索引设计，讲LLM时引出你设计的提示词结构。技术是为业务服务的，这一句话在论文里要贯彻始终。

6.3 答辩高频问题与参考应答方向

答辩前可以把下面这几个问题背熟思路：

• 问：为什么用Django而不用Spring Boot？答：一是Python生态在数据处理和机器学习上更顺畅，从Pandas清洗到训练模型到Django后端可以共用一套语言；二是项目定位是数据分析系统，不是高并发工程平台，Django开发效率更高。
• 问：LLM大模型在这个系统里究竟起了什么作用？答：它不参与数值计算，主要负责把结构化分析结果转化为自然语言的业务洞察和调度建议，保证分析结果的易读性和可解释性。
• 问：预测模型的可解释性怎么保证？答：树模型可以输出特征重要性排序，再加上时间窗口内的对比分析，可以解释“为什么某个区域未来一小时会供不应求”，而不是只给一个预测数字。

这些都是把系统的业务价值和技术细节结合起来讲的应答方式。顺着这个思路，绝大多数评委问不倒你。

最后再分享一个实操小技巧：答辩演示前，把LLM调用的提示词模板预先放置到页面配置文件里，演示时完全不用现场写。系统初始化时就把当天的历史数据预热好，模型结果和LLM建议都预生成一份缓存。这样评委看到的永远是“秒开”的状态，而不是现场等待进度条。我每次给这套系统做演示，都会额外加一个“数据刷新按钮”放在角落里，既展示了实时能力，又不影响主流程的流畅度。记住，好演示的核心不是功能多，而是节奏稳。