简介这是一份面向旅游信息化规划者、大数据平台架构师及政府文旅管理者的专题方案演示文档聚焦如何运用大模型与多维旅游数据要素如游客、景区、酒店、交通等推动全域旅游大数据平台升级。内容覆盖行业现状与痛点提出统一数据标准、质量管理体系与隐私保护机制并详解游客行为分析、旅游流监测调度、个性化资源推荐等典型应用场景。随后展开总体架构设计、功能模块划分、技术选型、实施步骤与保障措施并以效果评估与持续改进计划收尾。资源为单个文件共一个演示文档大小六点九二兆已有一百二十七人浏览学习。读者可借此快速掌握这类方案的完整逻辑适合作为方案构思、项目汇报或教学研讨的参考底稿。1. 这个标题说的事情不是一个汇报PPT是一套要跑起来的数据工程从「大模型和数据要素赋能全域旅游大数据平台解决方案.pptx」这个文件名看交付物是个 PPT但真正要被评审的是 PPT 背后那套数据链路能不能在评审后 90 天内落地。全域旅游的经典困境是数据散在文旅局、景区、交通、OTA 和电信运营商手里每个源都有数据但互相不认账。很多项目把预算砸进大模型 API 调用结果知识问答把两个景区的票价搞混因为底层数据根本没做资产化。所以这篇先解决“数据要素怎么变成资产”再讲“大模型在哪里接入、怎么接入”最后落到可量化验证上。适合数据平台工程师、解决方案架构师以及负责政企类文旅项目的技术负责人。2. 数据要素治理把景区、交通、OTA原始数据变成可用资产数据要素在工程上就是“有明确权责、有质量标准、能被计量计费的数据集”。全域旅游平台要同时服务游客、企业和监管侧同样的“景区”在不同系统里可能叫三种名字这是数据治理的第一个坎。常见做法是先画数据域而不是先建数据湖。2.1 从需求出发确定必须的数据域而不是先建湖我一般按业务场景拆四个数据域游客域包含客流、来源地、停留时长、消费记录资源域包含景区、酒店、餐饮、场馆的基础信息和实时营业状态交通域包含高速出口流量、停车场饱和度、公交地铁客流舆情域包含OTA评价、短视频评论和12345投诉工单。每个域在数仓里对应一个 ODS schema命名规则建议是ods_{domain}_{source}_{date}例如ods_tourist_ticket_gate_20251101。不要在建湖阶段追求贴源全量接入因为全域旅游的数据源头很杂接得越多后面清洗越费劲。这张表是平台启动阶段的建议范围数据域典型数据源接入方式更新频率优先级游客域景区闸机、OTA订单、运营商位置API/离线文件/实时推送T1或10minP0交通域高速卡口、停车场、公交API轮询/消息队列5minP0资源域景区信息系统、地图POI全量增量同步T1P1舆情域主流媒体网页、OTA评论爬虫/开放接口小时级P1如果项目里已经存在上级部门统一下发的文旅基础库优先对齐它们的字典表避免后续数据共享时字段互相认不了。我会单独留一层base库放字典和主数据比如行政区划代码、景区等级。这层数据也是后面大模型做实体对齐时的锚点没有它RAG 检索回来的片段里景区名称仍然对不上。2.2 数据接入链路批流一体与主数据映射接入层最常见的问题是“同一个景区闸机系统里叫黄山风景区OTA 里缩写 HS运营商信令里用行政区域名”。所以接入之后第一件事不是统计而是做一次主数据映射。实现上我用一个轻量级 Python 服务配合数据平台上的映射表在入湖时同步规整。import pandas as pd park_abbr { 黄山风景区: HS, 九寨沟: JZG, 西湖景区: XH, } def normalize_park_name(raw: str) - str: 把闸机、OTA和信令来源的景区名移到统一编码 raw raw.strip().upper() return park_abbr.get(raw, raw) # 采样检查一天的数据里能匹配上的比例 df pd.read_parquet(hdfs://.../ods_tourist_ticket_gate/dt2024-11-01) df[park_code] df[park_name].map(normalize_park_name) match_rate df[park_code].ne(df[park_name]).mean() print(fmapped: {match_rate:.2%})这段代码说明一个容易被忽略的点数据治理不只是在调度里加依赖更重要的是把名称归一做成一个在线函数在数据入湖时就开始调。match_rate低于 0.9 就要回头补别名表否则后面大模型检索到的景区名称都是分裂的。对于实时数据常见做法是 Flink 或 Spark Structured Streaming 从消息队列消费位置数据做窗口聚合后写入 Doris 或 ClickHouse供大屏实时展示。不要为一个数据大屏强行上 Kappa 架构批流一体里“流”只处理 P0 的动态数据即可。2.3 数据质量规则与“一数一源”冲突消解多源数据一旦开始跑批必然出现同一个指标对不上。闸机游客量 3.1 万人次运营商信令推断 4.5 万人次两者数不一样才是正常的。此刻要做三件事第一定义口径字段。在输出宽表前用配置代替硬编码把“游客量”拆成“购票入园人次”“OTA预订人次”“信令估算人次”让下游各取所需。第二设置质量规则。我至少会配非空率、唯一率、波动率三个阈值比如闸机数据非空率低于 95% 就阻断下游依赖任务而不是继续用脏数据覆盖指标。规则配置可以维护成 JSON由平台每日扫描{ rule_name: gate_visitor_completeness, table: dws_tourist_visitor_di, check: non_null_ratio, column: visitor_count, threshold: 0.95, action: block }第三解决多源冲突时不要直接做加权平均而是保留多源口径用“前一周同比”的绝对值作为告警基线超过 20% 就触发人工确认。很多项目把精力放在复杂权重公式上结果数据不可解释我更推荐在生成口径上保留标签并把这个口径写进大模型提示词例如“实时大屏用闸机口径”效果比瞎加权更好。2.4 数据要素登记让平台上的数据集可计量、可结算把数据当作要素意味着每一个被大模型调用的数据集都要有资产编号、授权范围、计量方式。这是平台能不能长期运营的关键也是很多方案里漏掉的一环。我会在治理引擎上为每个数据集维护一张元数据表字段说明示例asset_id资产编码ATTR-0001data_domain数据域tourist_visitorsource_system来源系统scenic_gatelicense_type授权类型内部/按次计费metric_columns可计量字段visitor_count, park_codemodel_access允许被调用的模型级rag_publicmodel_access很重要。大模型做 RAG 时才会去访问对应数据集同时要求返回内容里带来源信息避免生成“今天下午黄山游客拥挤度”这种看似合理但无依据的答案。数据要素登记这一步实际是把数据资产改成可追溯的调用接口后面做计量计费时才拿得出凭证。3. 大模型在旅游大数据平台里的三个落地位置语义检索、舆情研判与行程规划很多方案会把大模型写进“智能客服”一个章节就结束。实际能落地的位置有三个分别对应游客服务、管理侧舆情以及更长期的个性化推荐。选对位置比选对模型版本重要得多。3.1 为什么直接拿大模型做预测不靠谱要先做 RAG直接拿预训练大模型回答“票价、开放时间、限流规则”这类高时效知识效果一定不稳定。文旅数据时效性极强而模型参数在训练完成时已经冻结。回归到工程就是把结构化数据和文档灌进向量库通过检索增强生成把相关片段拼给大模型。这正是大模型在数据平台里最值得写的一层也是“大模型本地部署”在中小型项目里最常见的形态。做 RAG 前必须先做第 2 章的数据治理。如果原始文档里“黄山”和“HS”并存embedding 之后检索出来的片段会互相干扰。不要指望靠 rerank 模型解决脏数据问题rerank 只能优化排序不能把错误口径改成对的。一个区域内所有文档的命名、单位、时间格式都要先统一RAG 才有意义。3.2 游客服务侧的窄场景用 RAG 做景区知识助手选一个用户最容易感知的场景游客输入“明天去黄山需要预约吗几点开门”平台必须从最新公告、预约规则和天气数据中给出明确答复。这个场景知识库更新频繁、答案准确性要求高非常适合 RAG。一个可运行的检索链实现如下from langchain_community.vectorstores import Milvus from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.llms import Ollama from langchain.chains import RetrievalQA embedding HuggingFaceEmbeddings( model_nameBAAI/bge-large-zh-v1.5, encode_kwargs{normalize_embeddings: True}, ) vector_store Milvus( embedding_functionembedding, collection_nametourism_knowledge, connection_args{host: 127.0.0.1, port: 19530}, ) qa_chain RetrievalQA.from_chain_type( llmOllama(modelqwen2.5:14b, temperature0.1), retrievervector_store.as_retriever(search_kwargs{k: 4}), return_source_documentsTrue, ) resp qa_chain.invoke({query: 明天去黄山需要预约吗几点开门}) print(resp[result]) for src in resp[source_documents][:2]: print(src.metadata[source], src.page_content[:80])这里有两个关键参数temperature0.1是为了让开放域回答尽量保守k4是平衡召回数量与上下文窗口超过 8 个片段会稀释注意力。生产场景中建议只把景区官方公告、文旅局文件灌入知识库不要混入用户生成内容避免模型学到错误信息。单机演示用 Ollama 没问题生产可以用 vLLM 部署同一个模型再通过--max-model-len 8192限制长度降低显存占用。3.3 管理侧用大模型做网络舆情的事件要素抽取管理侧通常需要每周涉旅舆情摘要。传统方法是抓关键词再人工看标题大模型可以更进一步把原始评论抽成结构化事件要素包括时间、地点、涉事主体、情绪倾向和问题类型。这个场景值得做因为结构化舆情数据可以进数仓形成长期可分析的数据要素资产而不是模型生成报告后一次性消费。实现上不要先让大模型做“正面还是负面”的分类而是先抽取要素再按规则判定。目的是让结果可复核避免模型输出无依据的定性判断。一个最小实现如下from langchain_core.output_parsers import JsonOutputParser from langchain_core.prompts import ChatPromptTemplate from langchain_community.llms import Ollama parser JsonOutputParser() prompt ChatPromptTemplate.from_template( 抽取句中的要素只输出JSON。 字段event_location, event_time, subject, sentiment, issue_type 文本{text} ) llm Ollama(modelqwen2.5:7b, temperature0) chain prompt | llm | parser out chain.invoke({text: 昨天在XX景区排队超2小时景区现场没有疏导。}) print(out) # {event_location: XX景区, event_time: 昨天, subject: 排队, sentiment: 负面, issue_type: 拥堵}这里刻意不让模型输出“建议”因为建议类内容不能作为数据要素沉淀也不好审计。用 JSON 输出解析器确保落库稳定后续可以直接写 SQL 汇总或再喂给大模型写周报。舆情字段里的“昨天”这种相对时间建议在抽取后用业务日期做一次换算存成绝对时间否则按周聚合时会错位。3.4 模型选型边界一张表说清什么场景用什么模型在预算有限时按场景把模型分成三类而不是全家桶式微调。下表是方案设计中常用的参考场景推荐模型规模部署方式关键指标游客知识问答RAG7B~14B本地私有化答案命中率首字延迟舆情要素抽取7BvLLM离线批量schema遵守率抽取F1个性化行程规划32B或外部API量化多卡并行规划合理性安全性微调不是这个平台必须做的事。RAG 解决知识更新提示词工程解决抽取格式只有当你确定某个景区的知识体系固定、话术风格必须统一时才考虑用微调框架做小规模训练。一上来就微调很容易把数据治理没解决的口径问题误判成模型能力不足成本翻倍效果还不一定好。4. 平台核心实现Lakehouse基础设施与大模型服务编排数据治理和大模型应用之间还缺一个能抗住并发的运行底座。实际交付时我会把平台画成四层数据基础层、数据服务层、模型服务层、应用编排层。能落地的方案不是把几十个开源组件堆在一台服务器上而是用最少的基础设施配合明确的接口约定。4.1 整体架构ODSDWS特征存储大模型服务的分层数据基础层使用 HDFS 或对象存储作原始区Spark 清洗后进数仓 DWS 层。关键设计是在数仓上方增加一个特征存储层把游客潮汐、景区饱和度、天气等常用特征整理成宽表目的就是给大模型推理提供快速读取路径。只有被大模型访问的表才称为特征表避免特征层退化成又一个贴源层。-- 大模型问答场景使用的景区实时特征视图 CREATE VIEW v_attraction_realtime_features AS SELECT a.park_code, a.park_name, COALESCE(g.visitor_cnt, 0) AS visitor_cnt, COALESCE(p.parking_occupancy, 0) AS parking_occupancy, COALESCE(w.weather_desc, 未知) AS weather_desc FROM base_dim_park a LEFT JOIN dws_gate_visitor_5min g ON a.park_code g.park_code LEFT JOIN dws_parking_occupancy_5min p ON a.park_code p.park_code LEFT JOIN dws_weather_realtime w ON a.park_code w.park_code;这个视图把多张动态表拉成宽表下游大模型服务和 API 网关只依赖视图不依赖背后的分区表。当停车场数据源中断时COALESCE 会把空缺填成 0不会让模型得到错误信息。这是演示系统上线后最容易踩的坑原表字段一断模型就开始胡说。4.2 用 Docker Compose 跑起一个可演示的 Milvus本地大模型环境为了让方案在 POC 阶段最快跑通我一般准备一组容器编排把向量库、模型服务和主服务串起来。下面是一个可改写的 Compose 骨架version: 3.8 services: etcd: image: quay.io/coreos/etcd:v3.5.14 environment: - ETCD_AUTO_COMPACTION_MODErevision - ETCD_AUTO_COMPACTION_RETENTION1000 - ETCD_QUOTA_BACKEND_BYTES4294967296 minio: image: minio/minio:RELEASE.2024-12-18T13-15-44Z command: server /data --console-address :9001 environment: MINIO_ROOT_USER: minioadmin MINIO_ROOT_PASSWORD: minioadmin milvus: image: milvusdb/milvus:v2.4.15 command: [milvus, run, standalone] depends_on: - etcd - minio ports: - 19530:19530 model-server: image: vllm/vllm-openai:v0.6.6.post1 command: --model Qwen/Qwen2.5-14B-Instruct-AWQ --served-model-name tourism-bot --port 8000 --max-model-len 8192 --tensor-parallel-size 2 deploy: resources: reservations: devices: - driver: nvidia count: 2 capabilities: [gpu]启动命令不复杂docker compose up -d等模型加载完成后通过http://127.0.0.1:8000/v1/chat/completions调用接口。这个环境的价值在于评审现场能真实演示而不是只放 PPT。很多方案最终败在写得越宏大现场越难复现。这里有两个参数要特别说明--max-model-len必须结合显存估算24GB 双卡跑 14B AWQ 量化可以开到 8192显存偏小就降到 4096--tensor-parallel-size必须小于等于 GPU 数量否则 vLLM 启动直接报错。4.3 并发接入、限流与 GPU 显存预算大模型服务一暴露给外部应用并发就是第一个问题。API 网关需要给“同步问答”和“异步抽取”分别配流量策略。同步问答限制在 5 QPS 以内做体验优化异步抽取批量任务不受单路并发限制但要用队列削峰避免批量任务把 GPU 打满后影响在线问答。在网关层可以用 OpenResty 或 APISIX 配置一条按用户维度的限流规则limit_req_zone $binary_remote_addr zonetourism_qps:10m rate5r/s; server { location /v1/chat/ { limit_req zonetourism_qps burst10 nodelay; proxy_pass http://model-server:8000; proxy_read_timeout 120s; } }这个配置含义是客户端 IP 平均每秒最多 5 个请求突发可到 10 个。proxy_read_timeout必须调大因为大模型生成是流式的长文本经常超过 30 秒默认 60 秒勉强够用写 120 秒更稳妥。显存预算通常按模型参数量估算FP16 下每个参数约占 2 字节13B 模型约 26GBAWQ 4bit 量化可降到 7-8GB。KV Cache 还需要为每个并发序列额外留出空间所以单张 24GB 卡只够跑一个 14B 量化模型生产环境要监控显存使用率去做弹性伸缩不能只靠启动时的静态配置。4.4 三个必调的部署参数最终交付时有三个参数经常决定成败值得直接写进运维手册参数建议值影响MAX_MODEL_LEN8192输入太长会截断知识片段显存不够则直接溢出TENSOR_PARALLEL_SIZE等于GPU数小模型过度的并行会因通信开销变慢TEMPERATURE0.1~0.2高于 0.5 时推荐结果不稳定问答场景拒答率上升另外大模型服务的调用日志一定要记录prompt_tokens和completion_tokens。将来按 token 为数据要素计费时这就是计费凭证。这类调用明细本身就是平台运营过程中产生的数据资产不要只当普通日志删掉。5. 验证方法用两个可量化实验证明平台没有白建方案评审时最常被问“怎么知道这个平台有效”。我建议选两个实验一个面向 RAG 问答一个面向舆情抽取放进演示脚本中。这两个实验都不依赖跳动的演示数据评审逻辑清晰也方便后面持续回归。5.1 RAG答案命中率实验给大模型划出答题红线构建一个包含 100 条景区问题的测试集每条问题都要有标准答案或答案来源。评测时不要用开放问答而是用“答案是否包含正确知识点”来判断。实现脚本from difflib import SequenceMatcher def answer_hit(real: str, pred: str, keywords: list) - bool: 判断答案是否包含关键知识点 for kw in keywords: if kw not in pred: return False return True testset [ {question: 黄山几点停止入园, keywords: [17:00], source: 景区公告}, # 共100条 ] hits 0 for item in testset: resp qa_chain.invoke({query: item[question]})[result] if answer_hit(item[question], resp, item[keywords]): hits 1 print(fhit_rate: {hits / len(testset):.2%})这里把评价标准定义成关键知识点命中而不是 ngram 相似度因为评审关心的是“答案里有没有出现正确时间”不是措辞是否一致。答错的案例要记录失败原因比如“向量召回中没有来源文档”或“多源口径冲突”下一轮就能针对性调k或过滤规则。5.2 舆情抽取场景的可靠性评估舆情抽取实验更简单取 200 条评论人工标注事件主体和情感倾向然后对比模型抽取结果。评估时统计两个数字schema 遵守率和抽取 F1。7B 模型上把 temperature 设 0提示词里给一个示例通常都能达到较高的 schema 遵守率。最容易错的是相对时间表达和地点实体的标准化所以抽取后建议直接回写数据治理层做实体对齐。一个实用技巧是把模型拒绝解析的样本单独存一张表作为负面样本回流到治理层。下一轮迭代时先看是不是实体库缺了这个景点而不是立刻换更大参数的模型。5.3 结果如何回写平台两个实验最后都会生成一份模型评估报告包含命中率表格、失败 case、模型参数版本和对应的数据资产编号。这份报告会以离线任务的方式写入平台的指标表形成“数据治理 — 大模型调用 — 结果回流”的闭环。之后每周自动跑一次评估报告直接作为平台运营数据资产的一部分也作为下一轮优化数据质量、提示词和检索参数的依据。本文还有配套的精品资源点击获取
简介这是一份面向旅游信息化规划者、大数据平台架构师及政府文旅管理者的专题方案演示文档聚焦如何运用大模型与多维旅游数据要素如游客、景区、酒店、交通等推动全域旅游大数据平台升级。内容覆盖行业现状与痛点提出统一数据标准、质量管理体系与隐私保护机制并详解游客行为分析、旅游流监测调度、个性化资源推荐等典型应用场景。随后展开总体架构设计、功能模块划分、技术选型、实施步骤与保障措施并以效果评估与持续改进计划收尾。资源为单个文件共一个演示文档大小六点九二兆已有一百二十七人浏览学习。读者可借此快速掌握这类方案的完整逻辑适合作为方案构思、项目汇报或教学研讨的参考底稿。1. 这个标题说的事情不是一个汇报PPT是一套要跑起来的数据工程从「大模型和数据要素赋能全域旅游大数据平台解决方案.pptx」这个文件名看交付物是个 PPT但真正要被评审的是 PPT 背后那套数据链路能不能在评审后 90 天内落地。全域旅游的经典困境是数据散在文旅局、景区、交通、OTA 和电信运营商手里每个源都有数据但互相不认账。很多项目把预算砸进大模型 API 调用结果知识问答把两个景区的票价搞混因为底层数据根本没做资产化。所以这篇先解决“数据要素怎么变成资产”再讲“大模型在哪里接入、怎么接入”最后落到可量化验证上。适合数据平台工程师、解决方案架构师以及负责政企类文旅项目的技术负责人。2. 数据要素治理把景区、交通、OTA原始数据变成可用资产数据要素在工程上就是“有明确权责、有质量标准、能被计量计费的数据集”。全域旅游平台要同时服务游客、企业和监管侧同样的“景区”在不同系统里可能叫三种名字这是数据治理的第一个坎。常见做法是先画数据域而不是先建数据湖。2.1 从需求出发确定必须的数据域而不是先建湖我一般按业务场景拆四个数据域游客域包含客流、来源地、停留时长、消费记录资源域包含景区、酒店、餐饮、场馆的基础信息和实时营业状态交通域包含高速出口流量、停车场饱和度、公交地铁客流舆情域包含OTA评价、短视频评论和12345投诉工单。每个域在数仓里对应一个 ODS schema命名规则建议是ods_{domain}_{source}_{date}例如ods_tourist_ticket_gate_20251101。不要在建湖阶段追求贴源全量接入因为全域旅游的数据源头很杂接得越多后面清洗越费劲。这张表是平台启动阶段的建议范围数据域典型数据源接入方式更新频率优先级游客域景区闸机、OTA订单、运营商位置API/离线文件/实时推送T1或10minP0交通域高速卡口、停车场、公交API轮询/消息队列5minP0资源域景区信息系统、地图POI全量增量同步T1P1舆情域主流媒体网页、OTA评论爬虫/开放接口小时级P1如果项目里已经存在上级部门统一下发的文旅基础库优先对齐它们的字典表避免后续数据共享时字段互相认不了。我会单独留一层base库放字典和主数据比如行政区划代码、景区等级。这层数据也是后面大模型做实体对齐时的锚点没有它RAG 检索回来的片段里景区名称仍然对不上。2.2 数据接入链路批流一体与主数据映射接入层最常见的问题是“同一个景区闸机系统里叫黄山风景区OTA 里缩写 HS运营商信令里用行政区域名”。所以接入之后第一件事不是统计而是做一次主数据映射。实现上我用一个轻量级 Python 服务配合数据平台上的映射表在入湖时同步规整。import pandas as pd park_abbr { 黄山风景区: HS, 九寨沟: JZG, 西湖景区: XH, } def normalize_park_name(raw: str) - str: 把闸机、OTA和信令来源的景区名移到统一编码 raw raw.strip().upper() return park_abbr.get(raw, raw) # 采样检查一天的数据里能匹配上的比例 df pd.read_parquet(hdfs://.../ods_tourist_ticket_gate/dt2024-11-01) df[park_code] df[park_name].map(normalize_park_name) match_rate df[park_code].ne(df[park_name]).mean() print(fmapped: {match_rate:.2%})这段代码说明一个容易被忽略的点数据治理不只是在调度里加依赖更重要的是把名称归一做成一个在线函数在数据入湖时就开始调。match_rate低于 0.9 就要回头补别名表否则后面大模型检索到的景区名称都是分裂的。对于实时数据常见做法是 Flink 或 Spark Structured Streaming 从消息队列消费位置数据做窗口聚合后写入 Doris 或 ClickHouse供大屏实时展示。不要为一个数据大屏强行上 Kappa 架构批流一体里“流”只处理 P0 的动态数据即可。2.3 数据质量规则与“一数一源”冲突消解多源数据一旦开始跑批必然出现同一个指标对不上。闸机游客量 3.1 万人次运营商信令推断 4.5 万人次两者数不一样才是正常的。此刻要做三件事第一定义口径字段。在输出宽表前用配置代替硬编码把“游客量”拆成“购票入园人次”“OTA预订人次”“信令估算人次”让下游各取所需。第二设置质量规则。我至少会配非空率、唯一率、波动率三个阈值比如闸机数据非空率低于 95% 就阻断下游依赖任务而不是继续用脏数据覆盖指标。规则配置可以维护成 JSON由平台每日扫描{ rule_name: gate_visitor_completeness, table: dws_tourist_visitor_di, check: non_null_ratio, column: visitor_count, threshold: 0.95, action: block }第三解决多源冲突时不要直接做加权平均而是保留多源口径用“前一周同比”的绝对值作为告警基线超过 20% 就触发人工确认。很多项目把精力放在复杂权重公式上结果数据不可解释我更推荐在生成口径上保留标签并把这个口径写进大模型提示词例如“实时大屏用闸机口径”效果比瞎加权更好。2.4 数据要素登记让平台上的数据集可计量、可结算把数据当作要素意味着每一个被大模型调用的数据集都要有资产编号、授权范围、计量方式。这是平台能不能长期运营的关键也是很多方案里漏掉的一环。我会在治理引擎上为每个数据集维护一张元数据表字段说明示例asset_id资产编码ATTR-0001data_domain数据域tourist_visitorsource_system来源系统scenic_gatelicense_type授权类型内部/按次计费metric_columns可计量字段visitor_count, park_codemodel_access允许被调用的模型级rag_publicmodel_access很重要。大模型做 RAG 时才会去访问对应数据集同时要求返回内容里带来源信息避免生成“今天下午黄山游客拥挤度”这种看似合理但无依据的答案。数据要素登记这一步实际是把数据资产改成可追溯的调用接口后面做计量计费时才拿得出凭证。3. 大模型在旅游大数据平台里的三个落地位置语义检索、舆情研判与行程规划很多方案会把大模型写进“智能客服”一个章节就结束。实际能落地的位置有三个分别对应游客服务、管理侧舆情以及更长期的个性化推荐。选对位置比选对模型版本重要得多。3.1 为什么直接拿大模型做预测不靠谱要先做 RAG直接拿预训练大模型回答“票价、开放时间、限流规则”这类高时效知识效果一定不稳定。文旅数据时效性极强而模型参数在训练完成时已经冻结。回归到工程就是把结构化数据和文档灌进向量库通过检索增强生成把相关片段拼给大模型。这正是大模型在数据平台里最值得写的一层也是“大模型本地部署”在中小型项目里最常见的形态。做 RAG 前必须先做第 2 章的数据治理。如果原始文档里“黄山”和“HS”并存embedding 之后检索出来的片段会互相干扰。不要指望靠 rerank 模型解决脏数据问题rerank 只能优化排序不能把错误口径改成对的。一个区域内所有文档的命名、单位、时间格式都要先统一RAG 才有意义。3.2 游客服务侧的窄场景用 RAG 做景区知识助手选一个用户最容易感知的场景游客输入“明天去黄山需要预约吗几点开门”平台必须从最新公告、预约规则和天气数据中给出明确答复。这个场景知识库更新频繁、答案准确性要求高非常适合 RAG。一个可运行的检索链实现如下from langchain_community.vectorstores import Milvus from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.llms import Ollama from langchain.chains import RetrievalQA embedding HuggingFaceEmbeddings( model_nameBAAI/bge-large-zh-v1.5, encode_kwargs{normalize_embeddings: True}, ) vector_store Milvus( embedding_functionembedding, collection_nametourism_knowledge, connection_args{host: 127.0.0.1, port: 19530}, ) qa_chain RetrievalQA.from_chain_type( llmOllama(modelqwen2.5:14b, temperature0.1), retrievervector_store.as_retriever(search_kwargs{k: 4}), return_source_documentsTrue, ) resp qa_chain.invoke({query: 明天去黄山需要预约吗几点开门}) print(resp[result]) for src in resp[source_documents][:2]: print(src.metadata[source], src.page_content[:80])这里有两个关键参数temperature0.1是为了让开放域回答尽量保守k4是平衡召回数量与上下文窗口超过 8 个片段会稀释注意力。生产场景中建议只把景区官方公告、文旅局文件灌入知识库不要混入用户生成内容避免模型学到错误信息。单机演示用 Ollama 没问题生产可以用 vLLM 部署同一个模型再通过--max-model-len 8192限制长度降低显存占用。3.3 管理侧用大模型做网络舆情的事件要素抽取管理侧通常需要每周涉旅舆情摘要。传统方法是抓关键词再人工看标题大模型可以更进一步把原始评论抽成结构化事件要素包括时间、地点、涉事主体、情绪倾向和问题类型。这个场景值得做因为结构化舆情数据可以进数仓形成长期可分析的数据要素资产而不是模型生成报告后一次性消费。实现上不要先让大模型做“正面还是负面”的分类而是先抽取要素再按规则判定。目的是让结果可复核避免模型输出无依据的定性判断。一个最小实现如下from langchain_core.output_parsers import JsonOutputParser from langchain_core.prompts import ChatPromptTemplate from langchain_community.llms import Ollama parser JsonOutputParser() prompt ChatPromptTemplate.from_template( 抽取句中的要素只输出JSON。 字段event_location, event_time, subject, sentiment, issue_type 文本{text} ) llm Ollama(modelqwen2.5:7b, temperature0) chain prompt | llm | parser out chain.invoke({text: 昨天在XX景区排队超2小时景区现场没有疏导。}) print(out) # {event_location: XX景区, event_time: 昨天, subject: 排队, sentiment: 负面, issue_type: 拥堵}这里刻意不让模型输出“建议”因为建议类内容不能作为数据要素沉淀也不好审计。用 JSON 输出解析器确保落库稳定后续可以直接写 SQL 汇总或再喂给大模型写周报。舆情字段里的“昨天”这种相对时间建议在抽取后用业务日期做一次换算存成绝对时间否则按周聚合时会错位。3.4 模型选型边界一张表说清什么场景用什么模型在预算有限时按场景把模型分成三类而不是全家桶式微调。下表是方案设计中常用的参考场景推荐模型规模部署方式关键指标游客知识问答RAG7B~14B本地私有化答案命中率首字延迟舆情要素抽取7BvLLM离线批量schema遵守率抽取F1个性化行程规划32B或外部API量化多卡并行规划合理性安全性微调不是这个平台必须做的事。RAG 解决知识更新提示词工程解决抽取格式只有当你确定某个景区的知识体系固定、话术风格必须统一时才考虑用微调框架做小规模训练。一上来就微调很容易把数据治理没解决的口径问题误判成模型能力不足成本翻倍效果还不一定好。4. 平台核心实现Lakehouse基础设施与大模型服务编排数据治理和大模型应用之间还缺一个能抗住并发的运行底座。实际交付时我会把平台画成四层数据基础层、数据服务层、模型服务层、应用编排层。能落地的方案不是把几十个开源组件堆在一台服务器上而是用最少的基础设施配合明确的接口约定。4.1 整体架构ODSDWS特征存储大模型服务的分层数据基础层使用 HDFS 或对象存储作原始区Spark 清洗后进数仓 DWS 层。关键设计是在数仓上方增加一个特征存储层把游客潮汐、景区饱和度、天气等常用特征整理成宽表目的就是给大模型推理提供快速读取路径。只有被大模型访问的表才称为特征表避免特征层退化成又一个贴源层。-- 大模型问答场景使用的景区实时特征视图 CREATE VIEW v_attraction_realtime_features AS SELECT a.park_code, a.park_name, COALESCE(g.visitor_cnt, 0) AS visitor_cnt, COALESCE(p.parking_occupancy, 0) AS parking_occupancy, COALESCE(w.weather_desc, 未知) AS weather_desc FROM base_dim_park a LEFT JOIN dws_gate_visitor_5min g ON a.park_code g.park_code LEFT JOIN dws_parking_occupancy_5min p ON a.park_code p.park_code LEFT JOIN dws_weather_realtime w ON a.park_code w.park_code;这个视图把多张动态表拉成宽表下游大模型服务和 API 网关只依赖视图不依赖背后的分区表。当停车场数据源中断时COALESCE 会把空缺填成 0不会让模型得到错误信息。这是演示系统上线后最容易踩的坑原表字段一断模型就开始胡说。4.2 用 Docker Compose 跑起一个可演示的 Milvus本地大模型环境为了让方案在 POC 阶段最快跑通我一般准备一组容器编排把向量库、模型服务和主服务串起来。下面是一个可改写的 Compose 骨架version: 3.8 services: etcd: image: quay.io/coreos/etcd:v3.5.14 environment: - ETCD_AUTO_COMPACTION_MODErevision - ETCD_AUTO_COMPACTION_RETENTION1000 - ETCD_QUOTA_BACKEND_BYTES4294967296 minio: image: minio/minio:RELEASE.2024-12-18T13-15-44Z command: server /data --console-address :9001 environment: MINIO_ROOT_USER: minioadmin MINIO_ROOT_PASSWORD: minioadmin milvus: image: milvusdb/milvus:v2.4.15 command: [milvus, run, standalone] depends_on: - etcd - minio ports: - 19530:19530 model-server: image: vllm/vllm-openai:v0.6.6.post1 command: --model Qwen/Qwen2.5-14B-Instruct-AWQ --served-model-name tourism-bot --port 8000 --max-model-len 8192 --tensor-parallel-size 2 deploy: resources: reservations: devices: - driver: nvidia count: 2 capabilities: [gpu]启动命令不复杂docker compose up -d等模型加载完成后通过http://127.0.0.1:8000/v1/chat/completions调用接口。这个环境的价值在于评审现场能真实演示而不是只放 PPT。很多方案最终败在写得越宏大现场越难复现。这里有两个参数要特别说明--max-model-len必须结合显存估算24GB 双卡跑 14B AWQ 量化可以开到 8192显存偏小就降到 4096--tensor-parallel-size必须小于等于 GPU 数量否则 vLLM 启动直接报错。4.3 并发接入、限流与 GPU 显存预算大模型服务一暴露给外部应用并发就是第一个问题。API 网关需要给“同步问答”和“异步抽取”分别配流量策略。同步问答限制在 5 QPS 以内做体验优化异步抽取批量任务不受单路并发限制但要用队列削峰避免批量任务把 GPU 打满后影响在线问答。在网关层可以用 OpenResty 或 APISIX 配置一条按用户维度的限流规则limit_req_zone $binary_remote_addr zonetourism_qps:10m rate5r/s; server { location /v1/chat/ { limit_req zonetourism_qps burst10 nodelay; proxy_pass http://model-server:8000; proxy_read_timeout 120s; } }这个配置含义是客户端 IP 平均每秒最多 5 个请求突发可到 10 个。proxy_read_timeout必须调大因为大模型生成是流式的长文本经常超过 30 秒默认 60 秒勉强够用写 120 秒更稳妥。显存预算通常按模型参数量估算FP16 下每个参数约占 2 字节13B 模型约 26GBAWQ 4bit 量化可降到 7-8GB。KV Cache 还需要为每个并发序列额外留出空间所以单张 24GB 卡只够跑一个 14B 量化模型生产环境要监控显存使用率去做弹性伸缩不能只靠启动时的静态配置。4.4 三个必调的部署参数最终交付时有三个参数经常决定成败值得直接写进运维手册参数建议值影响MAX_MODEL_LEN8192输入太长会截断知识片段显存不够则直接溢出TENSOR_PARALLEL_SIZE等于GPU数小模型过度的并行会因通信开销变慢TEMPERATURE0.1~0.2高于 0.5 时推荐结果不稳定问答场景拒答率上升另外大模型服务的调用日志一定要记录prompt_tokens和completion_tokens。将来按 token 为数据要素计费时这就是计费凭证。这类调用明细本身就是平台运营过程中产生的数据资产不要只当普通日志删掉。5. 验证方法用两个可量化实验证明平台没有白建方案评审时最常被问“怎么知道这个平台有效”。我建议选两个实验一个面向 RAG 问答一个面向舆情抽取放进演示脚本中。这两个实验都不依赖跳动的演示数据评审逻辑清晰也方便后面持续回归。5.1 RAG答案命中率实验给大模型划出答题红线构建一个包含 100 条景区问题的测试集每条问题都要有标准答案或答案来源。评测时不要用开放问答而是用“答案是否包含正确知识点”来判断。实现脚本from difflib import SequenceMatcher def answer_hit(real: str, pred: str, keywords: list) - bool: 判断答案是否包含关键知识点 for kw in keywords: if kw not in pred: return False return True testset [ {question: 黄山几点停止入园, keywords: [17:00], source: 景区公告}, # 共100条 ] hits 0 for item in testset: resp qa_chain.invoke({query: item[question]})[result] if answer_hit(item[question], resp, item[keywords]): hits 1 print(fhit_rate: {hits / len(testset):.2%})这里把评价标准定义成关键知识点命中而不是 ngram 相似度因为评审关心的是“答案里有没有出现正确时间”不是措辞是否一致。答错的案例要记录失败原因比如“向量召回中没有来源文档”或“多源口径冲突”下一轮就能针对性调k或过滤规则。5.2 舆情抽取场景的可靠性评估舆情抽取实验更简单取 200 条评论人工标注事件主体和情感倾向然后对比模型抽取结果。评估时统计两个数字schema 遵守率和抽取 F1。7B 模型上把 temperature 设 0提示词里给一个示例通常都能达到较高的 schema 遵守率。最容易错的是相对时间表达和地点实体的标准化所以抽取后建议直接回写数据治理层做实体对齐。一个实用技巧是把模型拒绝解析的样本单独存一张表作为负面样本回流到治理层。下一轮迭代时先看是不是实体库缺了这个景点而不是立刻换更大参数的模型。5.3 结果如何回写平台两个实验最后都会生成一份模型评估报告包含命中率表格、失败 case、模型参数版本和对应的数据资产编号。这份报告会以离线任务的方式写入平台的指标表形成“数据治理 — 大模型调用 — 结果回流”的闭环。之后每周自动跑一次评估报告直接作为平台运营数据资产的一部分也作为下一轮优化数据质量、提示词和检索参数的依据。本文还有配套的精品资源点击获取
