1. 从一句“在火车站建 AGI”说起这个项目到底在做什么第一次看到“Mistral 在火车站建 AGI”这个说法我愣了几秒。火车站和 AGI 这两个词放在一起画面感太强了——一边是嘈杂、拥挤、时刻表精确到秒的现实世界枢纽一边是实验室里动辄千亿参数、烧卡烧到冒烟的通用人工智能。把这两者硬凑到一块要么是标题党要么背后藏着一套非常务实的工程思路。我倾向于后者因为真正做过大模型落地的人都知道AGI 不会从真空里长出来它得先在一个足够复杂、足够真实、足够“脏”的场景里活下来而火车站恰好就是这样一个场景。先把话说清楚这里的“火车站”不是指某个具体城市的某个具体车站而是一类高密度、高流动性、多任务并发的现实场景的代称。它可以是交通枢纽、大型商场、医院门诊大厅、政务服务中心甚至是任何一个需要同时处理海量异构请求的物理空间。而“建 AGI”也不是说要在候车厅里训练一个通用人工智能而是指把大模型能力部署到这类场景中让它像一个真正的工作人员一样理解多模态输入、调度资源、回答问题、处理突发状况并且持续从交互中学习。这个项目的核心就是探索一条从“模型能力”到“场景智能”的落地路径。我之所以对这个方向感兴趣是因为过去两年我见过太多大模型项目死在“最后一公里”。模型在 benchmark 上刷分很漂亮一放到真实业务里就露馅响应慢、幻觉多、上下文一长就崩、多轮对话记不住前面说过什么、遇到没见过的输入直接摆烂。而火车站这类场景恰恰把这些弱点全部放大。旅客不会按你预设的 prompt 说话他们带着口音、带着情绪、带着各种奇怪的诉求而且同时有几百上千人在问不同的问题。这种压力测试比任何学术数据集都狠。所以这篇文章我想从工程落地的角度把这个项目拆开来讲。我会聊清楚它背后的技术选型逻辑、核心模块怎么搭、实操中会遇到哪些坑、以及我自己在类似场景里踩过的雷。不管你是做 AI 应用开发的工程师还是负责智能化改造的产品经理或者只是对大模型落地感兴趣的技术爱好者应该都能从里面找到能直接抄作业的东西。提示本文提到的所有项目名称、机构名称、人物称呼均为虚构代称仅用于说明技术方案不指向任何真实实体。2. 为什么是“火车站”场景选型背后的真实考量2.1 高密度并发请求下的架构压力测试火车站最显著的特征是什么不是大而是“同时”。同一时刻可能有几十个窗口在办理业务几百个旅客在问询广播在播报显示屏在刷新安检口在排队。如果把这个场景抽象成软件系统它就是一个典型的高并发、多模态、强实时的分布式环境。把 AGI 能力塞进这样的环境首先考验的不是模型有多聪明而是架构能不能扛住。我参与过一个类似规模的智能问询系统改造当时最大的教训就是不要指望单个大模型实例能搞定所有事。我们最初的设计很天真所有请求都打到同一个推理服务上结果高峰期延迟直接飙到十几秒旅客等得不耐烦就开始重复提问重复提问又进一步加剧拥堵形成恶性循环。后来改成“路由 专家”的架构用一个轻量级分类模型先判断请求类型再分发给不同的处理模块整体吞吐量提升了将近四倍。这个经验放到“火车站建 AGI”的项目里同样适用。核心思路是AGI 不是一个单体模型而是一套调度系统。它需要有一个“前台”负责快速响应和意图识别一个“后台”负责复杂推理和知识检索中间用消息队列和缓存层做缓冲。前台可以用蒸馏过的小模型甚至规则引擎保证毫秒级响应后台才调用大模型做深度处理允许几百毫秒到几秒的延迟。这样既保证了用户体验又控制了算力成本。2.2 多模态输入的真实复杂度火车站里的信息输入从来不是纯文本。旅客可能指着屏幕问“这个车次在哪检票”可能拿着票问“我这个还能改签吗”可能用方言说“我要去某某地方怎么走”甚至可能只是站在那里面露困惑。一个真正可用的 AGI 系统必须能处理文本、语音、图像、甚至视频流的多模态输入。我在做多模态融合的时候最大的体会是模态之间的对齐比单个模态的识别精度更重要。举个例子旅客说“这个”的时候如果系统不能结合他手指的方向或者视线焦点来判断“这个”指什么那语音识别再准也没用。所以项目里必须有一个“上下文融合层”把语音转写、视觉检测、位置信息、历史交互记录拼成一个统一的语义表示再送给大模型做推理。这里有个实操细节多模态输入的时序同步非常关键。语音有延迟视觉有帧率位置有刷新频率如果不对齐时间戳融合出来的上下文就是错的。我们的做法是给每个模态的数据打上统一的时间戳用一个滑动窗口做对齐窗口大小根据场景动态调整。在问询场景下窗口设为 2 秒左右比较合适既能覆盖一句话的时长又不会引入太多无关信息。2.3 从“能回答”到“能办事”的能力跃迁很多智能系统止步于“能回答”但火车站场景要求的是“能办事”。旅客问“我的车晚点了怎么办”他不想听一段关于晚点政策的解释他想知道“我现在该去哪、该做什么、能不能改签、要不要退票”。这就要求 AGI 系统不仅能理解语言还要能调用业务系统、查询实时数据、执行操作。这就引出了一个关键设计工具调用Tool Use能力。大模型本身不知道当前车次晚点多久也不知道改签窗口排了多少人它必须通过 API 去查。项目里需要定义一套清晰的工具接口让模型知道什么时候该调用哪个工具、传什么参数、怎么处理返回结果。我见过很多项目在这里翻车原因是工具描述写得太模糊模型不知道该用哪个或者参数格式不对调用直接失败。一个实用的技巧是给每个工具写一段“使用说明”用自然语言描述它的功能、输入输出格式、适用场景然后把这段说明作为系统提示的一部分喂给模型。实测下来这样能显著提升工具调用的准确率。另外一定要做参数校验和异常兜底模型传错参数是常态不能指望它一次就对。3. 核心架构拆解一套能扛住火车站流量的 AGI 系统长什么样3.1 分层架构设计与模块职责划分把这套系统拆开来看我倾向于分成四层接入层、调度层、推理层、数据层。每一层的职责必须清晰不能互相渗透否则后期维护会非常痛苦。接入层负责处理所有外部输入包括语音识别、图像预处理、文本归一化、协议转换。这一层的核心指标是延迟和吞吐不能做任何重逻辑。我通常会用 Go 或者 Rust 写接入层因为这两种语言在高并发下的表现比 Python 好太多。语音识别可以用流式方案边收边转不用等整句话说完。调度层是整个系统的大脑负责意图识别、路由分发、上下文管理、会话状态维护。这一层可以用一个轻量级模型加规则引擎来实现。意图识别不需要太复杂能把请求分到正确的处理通道就行。上下文管理要特别注意火车站场景下用户可能随时打断、切换话题、多人同时说话会话状态必须能正确处理这些情况。推理层才是大模型真正干活的地方。这里要根据请求类型选择不同的模型简单问答用小模型复杂推理用大模型知识检索用 RAG工具调用用 function calling。关键是要有一个统一的推理接口上层不用关心底层用的是哪个模型。数据层包括向量数据库、缓存、业务数据库、日志系统。向量数据库用于 RAG 检索缓存用于存储热点问答和会话状态业务数据库提供实时数据日志系统用于监控和迭代。这一层最容易出问题的是数据一致性缓存和数据库不同步会导致模型拿到过期信息一定要设计好失效策略。3.2 模型选型为什么不是越大越好在火车站这种场景里模型选型的核心原则是“合适比强大更重要”。我见过太多团队一上来就要上最大的模型结果推理成本高得离谱延迟也下不来最后不得不回退。实际上一个 7B 到 13B 的模型经过领域微调后在特定任务上的表现可以接近甚至超过通用大模型。具体怎么选我的经验是分任务来看。意图分类、实体抽取这类任务用小模型甚至 BERT 级别的模型就够了速度快、成本低。知识问答和简单推理用 7B 到 13B 的指令微调模型配合 RAG 效果很好。只有遇到复杂的多步推理、工具编排、长上下文理解才需要动用更大的模型。而且大模型也不是每次都全量推理可以用 speculative decoding 或者 draft model 来加速。还有一个容易被忽略的点模型的量化。在边缘设备或者成本敏感的场景下把模型量化到 4bit 甚至 3bit性能损失通常在可接受范围内但显存占用和推理延迟会大幅下降。我用过 GPTQ 和 AWQ 两种量化方案实测下来 AWQ 在保持精度方面略好一些但 GPTQ 的生态更成熟工具链更完善。具体选哪个要看你的部署环境和精度要求。3.3 上下文管理与会话状态保持火车站场景下的对话有一个特点短、碎、频繁切换。旅客不会跟你聊十分钟他们通常一两句话就要解决问题。但问题是这一两句话可能来自不同的人而且前后可能有关联。比如一个人问“去某地的车在哪检票”另一个人接着问“就是刚才说的那趟车晚点了吗”。如果系统不能把这两个请求关联起来就会答非所问。我的做法是引入“会话组”的概念。不是按用户 ID 来分组而是按空间位置和时间窗口来分组。同一个问询点、同一个时间段内的请求归入同一个会话组共享上下文。这样既能处理多人交替提问的情况又不会把不相关的请求混在一起。会话组的生命周期很短通常几分钟就过期避免上下文无限膨胀。上下文窗口的管理也很关键。大模型的上下文长度是有限的不能把所有历史都塞进去。我通常会用“摘要 最近轮次”的策略把较早的对话压缩成摘要保留最近几轮的完整内容。摘要用一个小模型来生成成本很低。这样既能保持长程记忆又不会撑爆上下文窗口。4. 实操落地从零搭建一套场景化 AGI 系统的关键步骤4.1 环境准备与基础依赖安装动手之前先把环境理清楚。我假设你用的是 Linux 服务器有 NVIDIA GPUCUDA 版本在 12.0 以上。Python 环境建议用 3.10 或 3.11太新的版本有些库还没适配太旧的版本又缺特性。虚拟环境用 conda 或者 venv 都行我个人习惯用 conda因为管理 CUDA 版本方便。基础依赖包括推理框架vLLM 或 TGI、向量数据库Milvus 或 Qdrant、缓存Redis、消息队列RabbitMQ 或 Kafka、Web 框架FastAPI。这些不用全上根据你的规模来。小规模试点的话vLLM Qdrant Redis FastAPI 就够了。安装 vLLM 的时候注意版本匹配。vLLM 对 CUDA 和 PyTorch 版本比较敏感装之前先查一下官方文档的兼容性矩阵。我踩过的坑是用 pip 直接装 vLLM结果它自动拉了一个不匹配的 PyTorch 版本推理时直接报错。后来改成先手动装好 PyTorch再装 vLLM就稳了。# 先装 PyTorch指定 CUDA 版本 pip install torch2.1.0 torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 # 再装 vLLM pip install vllm0.2.7 # 装向量数据库客户端 pip install qdrant-client redis fastapi uvicorn4.2 模型部署与推理服务配置模型部署这块我推荐用 vLLM 的 OpenAI 兼容接口这样上层应用可以用统一的 API 调用换模型的时候不用改代码。启动命令大概长这样python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name scene-llm \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000几个关键参数解释一下。--max-model-len控制上下文长度火车站场景下 8192 通常够用再长会吃显存。--gpu-memory-utilization设为 0.9 是留一点余量给其他进程设太高容易 OOM。--dtype auto让 vLLM 自动选择精度一般会选 float16如果显存不够可以手动改成 bfloat16 或者量化版本。启动之后用 curl 测一下curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: scene-llm, messages: [{role: user, content: 你好}], temperature: 0.1 }temperature 设低一点火车站场景不需要模型发挥创造力稳定准确最重要。top_p 也可以设低比如 0.9减少随机性。4.3 RAG 知识库构建与检索优化火车站场景的知识库很杂车次信息、票价规则、退改签政策、站内设施位置、周边交通、失物招领流程等等。这些知识有的结构化有的非结构化有的实时变化有的相对固定。构建 RAG 的时候不能一股脑全塞进向量数据库要分类处理。结构化数据比如车次时刻表直接走 API 查询不要做向量化。向量化适合处理非结构化的文本比如政策文档、常见问题解答。我的做法是把知识分成“实时查询类”和“静态检索类”实时类走工具调用静态类走 RAG。这样既保证了准确性又降低了检索压力。RAG 的检索质量取决于几个因素切块策略、嵌入模型、检索算法、重排序。切块不能太碎否则丢失上下文也不能太大否则检索精度下降。我通常按语义段落切每块 200 到 500 字重叠 50 字左右。嵌入模型用 bge-m3 或者 gte-large中文效果都不错。检索用混合检索向量相似度加关键词匹配再上一个重排序模型效果比纯向量检索好很多。from qdrant_client import QdrantClient from qdrant_client.models import Distance, VectorParams, PointStruct client QdrantClient(hostlocalhost, port6333) client.create_collection( collection_namestation_knowledge, vectors_configVectorParams(size1024, distanceDistance.COSINE), ) # 插入知识块 client.upsert( collection_namestation_knowledge, points[ PointStruct(id1, vector[...], payload{text: 退票规则..., category: policy}), PointStruct(id2, vector[...], payload{text: 失物招领流程..., category: service}), ] )4.4 工具调用与业务系统集成工具调用是让 AGI“能办事”的关键。在火车站场景里常见的工具包括查询车次、查询余票、查询晚点信息、查询站内设施、提交失物招领、呼叫人工服务。每个工具都要定义清晰的接口包括名称、描述、参数 schema、返回格式。我用 OpenAI 的 function calling 格式来定义工具因为生态成熟模型支持好。定义的时候描述要写得详细把使用场景、参数含义、返回示例都写清楚。模型看不懂模糊的描述它需要明确的指令。{ name: query_train_schedule, description: 查询指定车次的时刻信息包括发车时间、到达时间、当前状态。当用户询问某趟车的时间或是否晚点时使用。, parameters: { type: object, properties: { train_number: { type: string, description: 车次号例如 G1234 }, date: { type: string, description: 日期格式 YYYY-MM-DD默认为今天 } }, required: [train_number] } }工具调用的异常处理很重要。模型可能传错参数可能调用不存在的工具可能在不该调用的时候调用。我的做法是在调度层加一层校验参数不对就返回错误信息让模型重新生成工具不存在就返回可用工具列表调用频率过高就限流。这些兜底逻辑看起来琐碎但能避免很多线上事故。5. 踩坑实录那些文档里不会写的经验教训5.1 延迟优化的几个反直觉发现延迟是大模型落地最大的敌人。我做过统计用户对问询系统的耐心阈值大概在 3 秒左右超过 3 秒就开始不耐烦超过 5 秒就会放弃。而一个未优化的大模型推理首 token 延迟可能就超过 1 秒完整响应可能 5 到 10 秒。怎么把延迟压下来我试过很多方法有几个发现比较反直觉。第一个发现流式输出比批处理更省资源。听起来不合理但实测下来流式输出能让用户更早看到内容感知延迟大幅降低而且因为用户可以提前打断整体计算量反而减少了。vLLM 支持流式输出一定要开启。第二个发现缓存命中率比模型速度更重要。火车站场景下重复问题非常多“洗手间在哪”“检票口怎么走”这类问题占了很大比例。把这些高频问题的答案缓存起来直接返回不走模型推理能省下大量算力。缓存用 Redis 就行设置合理的过期时间一般 5 到 10 分钟。第三个发现预处理比后处理更值得投入。语音识别、文本归一化、意图分类这些前置步骤如果能做到又快又准后面的模型推理压力会小很多。我见过很多团队把精力全花在模型调优上结果前置处理一塌糊涂模型再快也没用。5.2 幻觉问题的场景化应对策略幻觉是大模型的固有缺陷在火车站场景下尤其危险。旅客问“我的车晚点了吗”模型如果编造一个晚点信息可能导致旅客误机误车。怎么控制幻觉我的经验是在事实性问题上不要让模型自由生成而是强制它走工具调用或 RAG 检索。具体做法是在系统提示里明确告诉模型“对于车次、时间、票价、政策等事实性问题必须调用工具或检索知识库不得凭记忆回答”。然后在输出层加一个校验如果模型回答里包含具体数字或事实陈述但没有对应的工具调用记录或检索来源就拦截并重新生成。还有一个技巧让模型在回答时附带来源。比如“根据查询结果G1234 次列车晚点 15 分钟”而不是直接说“G1234 晚点 15 分钟”。这样用户知道信息是从哪来的信任度更高也方便追溯。5.3 多轮对话中的上下文污染问题多轮对话最容易出的问题是上下文污染。前面的人问了一个问题后面的人接着问模型把两个人的信息混在一起给出莫名其妙的回答。我遇到过最离谱的一次一个旅客问“去某地的车”另一个人说“我带了小孩”模型居然回答“带小孩去某地可以走优先通道”。虽然不算完全错但明显是把两个不相关的请求混在一起了。解决这个问题的关键是会话隔离。不能简单地按时间窗口分组还要结合空间位置、用户特征、话题连续性来判断。我的做法是每个问询点独立维护会话状态不同问询点之间不共享上下文。同一个问询点内如果检测到话题切换或者用户特征变化就重置上下文。话题切换可以用一个轻量级分类器来判断用户特征可以用声纹或者视觉特征来辅助。另外上下文窗口里要保留“系统提示”和“最近几轮对话”但中间的旧对话要压缩成摘要。摘要里只保留关键信息比如用户意图、已确认的事实、待办事项。这样既能保持连贯性又不会让无关信息干扰模型判断。5.4 常见问题速查表问题现象可能原因排查方法解决方案响应延迟突然升高并发请求过多或模型 OOM查看 GPU 显存和请求队列长度增加推理实例或开启请求限流模型答非所问上下文污染或意图识别错误检查会话状态和意图分类结果重置会话或优化意图分类模型工具调用失败参数格式错误或工具未注册查看工具调用日志和参数校验结果修正工具描述或增加参数校验知识检索不准切块策略不合理或嵌入模型不匹配检查检索结果的相关性调整切块大小或更换嵌入模型语音识别错误率高环境噪音或口音问题对比语音转写结果和实际内容增加降噪处理或使用领域微调模型缓存命中率低缓存键设计不合理或过期时间太短统计缓存命中率和键分布优化缓存键或延长过期时间6. 效果验证与持续迭代怎么知道系统真的在变好6.1 离线评估与在线指标的结合评估一套场景化 AGI 系统不能只看模型在测试集上的准确率。我通常会把评估分成两部分离线评估和在线指标。离线评估用标注好的测试集测意图识别准确率、工具调用准确率、回答相关性、幻觉率。在线指标看真实用户的行为数据问题解决率、平均对话轮次、用户满意度、人工转接率。离线评估的好处是可控、可复现但容易过拟合。在线指标更真实但噪音大、周期长。我的做法是离线评估用于快速迭代每次模型更新或策略调整后跑一遍看核心指标有没有下降。在线指标用于长期监控设置告警阈值一旦异常就排查。有一个指标我特别看重首次解决率。就是用户第一次提问就得到满意回答的比例。这个指标直接反映系统的实用性。如果首次解决率低说明要么意图识别不准要么知识库覆盖不够要么回答质量不行。提升首次解决率比提升模型在 benchmark 上的分数有意义得多。6.2 用户反馈的采集与利用用户反馈是最宝贵的迭代信号但采集和利用都不容易。火车站场景下用户不会主动填问卷也不会给你打分。怎么收集反馈我的做法是通过行为信号来推断。用户如果重复提问说明上一次没解决如果直接走开说明放弃了如果点击了“转人工”说明对自动回答不满意。这些行为都可以埋点采集。另外可以设置一个简单的反馈机制比如回答后面跟一个“有帮助/没帮助”的按钮。虽然点击率不高但积累下来也能提供有价值的信号。对于“没帮助”的样本重点分析看看是知识缺失、意图识别错误、还是回答质量问题。采集到的反馈要闭环利用。我的做法是每周整理一次 bad case分类归因然后针对性地补充知识、优化提示词、调整路由策略。这个流程看起来很笨但效果最实在。我见过太多团队把反馈数据存着不用那还不如不采集。6.3 模型迭代与知识更新的节奏把控模型迭代和知识更新要有节奏不能太频繁也不能太久。太频繁会导致系统不稳定每次更新都可能引入新问题太久又会导致知识过时用户问的问题系统答不上来。我的经验是知识库更新可以频繁一些每天甚至每小时同步一次实时数据每周补充一次静态知识。模型迭代要谨慎通常一个月到两个月一次每次迭代前做好充分的离线评估迭代后做好灰度发布和回滚准备。灰度发布很重要。不要一次性全量上线新模型先切 5% 的流量观察一两天指标正常再逐步扩大。如果指标下降立即回滚。我吃过亏有一次新模型上线后离线指标很好但线上首次解决率反而下降了后来发现是新模型对某些口音的处理变差了。如果有灰度发布这个问题当天就能发现。7. 这套方案还能怎么扩展这套架构不只适用于火车站任何高密度、多模态、强实时的场景都可以复用。比如医院门诊大厅患者问“内科在哪”“我这个症状挂什么科”“检查结果什么时候出”逻辑和火车站几乎一样。再比如政务服务中心市民问“办护照要什么材料”“这个窗口几点下班”“能不能网上预约”也是同样的套路。扩展的时候主要改三个地方知识库、工具集、意图分类。知识库换成对应领域的文档工具集对接对应的业务系统意图分类重新训练或者微调。架构层和调度层基本不用动这就是分层设计的好处。还有一个扩展方向是多语言支持。火车站场景下外国旅客不少系统需要能处理英语、日语、韩语等常见语言。多语言支持可以在接入层做用语言检测模型判断语种然后路由到对应的处理通道。模型本身如果有多语言能力也可以直接处理不用额外路由。最后分享一个小技巧在系统提示里加一句“如果不确定就说不知道并建议用户咨询人工服务”。这句话看起来简单但能大幅降低幻觉率。模型有时候会硬答与其让它编造不如让它承认不知道。用户对“不知道”的容忍度远高于对错误信息的容忍度。