这次我们来看一个很有意思的文本分析场景朱开点评 NIP 2-1 WBG 的这条评论表面上看只是赛评观点但实际上它非常适合用来演示大模型在电竞赛评文本中的结构化抽取能力。把“我的角度其实希望WBG能赢骑士之路第一绝对比第二好IG要力争第一一定是希望WBG能赢NIP粉丝应该期待IG更强”这样一段包含立场、理由、建议的信息自动拆成“持什么观点、支持哪支队伍、给出什么理由、建议谁做什么”是赛事舆情分析、赛报摘要、粉丝评论自动总结里的常见需求。这篇文章不会去争论 NIP 和 WBG 哪边该赢而是把“朱开锐评”作为一条输入样本带大家从零搭一个基于大模型的赛事评论分析工具。你可以把它理解成一个小项目输入一段赛事评论输出结构化 JSON支持批量读取 CSV 文件也支持通过 HTTP API 对外提供服务。整个流程覆盖环境准备、提示词设计、单条抽取、批量任务、API 封装和常见问题排查就算你没有 GPU用小体量模型也能把流程跑通。如果你平时关注 LPL 赛事数据、想做粉丝评论分析或者正在学习大模型应用开发这篇文章可以直接收藏并照着做。1. 核心能力速览能力项说明项目类型电竞赛评文本结构化抽取流程主要功能观点抽取、立场分类、理由提取、建议识别、批量分析输入格式单条文本或 CSV 文件列如comment输出格式结构化 JSON包含立场、观点、理由、建议等字段模型支持本地大模型通过 Ollama 或 Transformers或云端 API显存需求取决于模型规模需按实际模型测试支持平台Windows / Linux / macOSCPU 可运行小模型启动方式Python 脚本 / FastAPI 服务接口支持可作为 HTTP API 对外提供批量任务支持逐条循环调用也可扩展并发队列适合场景赛事舆情分析、赛报生成、粉丝评论归纳这套方案的核心思路不是训练新模型而是利用大模型已有的中文理解和指令跟随能力把非结构化的赛评文本转换成固定结构的字段。因此门槛集中在环境配置和提示词设计上不涉及 GPU 训练。2. 适用场景与使用边界2.1 适合谁用赛事运营团队希望快速汇总直播间弹幕、微博评论、论坛帖子中的主流观点。数据分析师需要将文字评论转成可统计的标签数据比如“支持WBG”“希望IG争第一”“认为骑士之路第一更好”。大模型应用开发者需要一个结构清晰、容易扩展的中文文本抽取案例。2.2 能解决什么问题传统的关键词统计只能看到“WBG”出现多少词无法判断语境是支持还是反对。大模型抽取可以直接输出{ stance: 希望WBG赢, view: 骑士之路第一比第二好, reason: 第一的赛程或排名优势更明显, suggestion: IG要力争第一希望WBG赢NIP, target_team: [WBG, IG] }这样的结果可以直接落库后续做统计图表、时间趋势分析都方便很多。2.3 不适合什么场景需要精确到选手个人操作的复盘这类文本抽取不涉及比赛数据不适合做技术复盘。需要实时弹幕毫秒级分析如果用大模型 API延迟较高不适合超高频场景。需要完全客观的赛事预测抽取的是观点不是真实胜率不能直接当作预测结果。2.4 合规边界使用公开的赛事评论、直播内容进行文本分析应当遵循平台规则。批量采集数据前需要确认目标平台的服务条款避免爬取非公开数据。涉及个人用户昵称、头像、联系方式等信息时在输出结果中要进行脱敏。分析结果只能作为参考不能用于恶意引流、冒充官方观点或误导投注。3. 环境准备与前置条件这一节只给通用要求具体版本根据自己的模型选择调整。3.1 系统与软件操作系统Windows 10/11、Ubuntu 20.04 以上、macOS 12 以上均可。Python建议 3.10 或 3.11。模型服务如果本地运行优先配置 Ollama如果调用云端兼容接口需要准备 API Key。依赖库pandas、requests、fastapi、uvicorn、openai 或 openai-compatible 客户端。安装命令pip install -U pandas requests fastapi uvicorn openai如果使用 Ollama还需要单独安装 Ollama 客户端curl -fsSL https://ollama.com/install.sh | shWindows 用户到官网下载 OllamaSetup.exe 后直接安装。3.2 硬件要求CPU 推理选择 1B ~ 4B 的量化模型内存建议 8GB 以上。GPU 推理选择 7B ~ 14B 模型显存建议 8GB 以上。显存具体占用与量化方式和上下文长度有关。纯 API 调用本机不需要 GPU只需要保证能访问模型服务地址。3.3 模型选择推荐先把文本分析任务跑通再考虑更大模型。常见选择本地 CPU 小模型Qwen2.5-1.5B-Instruct、Qwen2.5-3B-Instruct适合快速验证流程。本地 GPU 模型Qwen2.5-7B-Instruct 4bit 量化效果更好。云端模型任意支持 OpenAI 兼容接口的中文模型。本项目代码基于 OpenAI 兼容接口编写无论本地 Ollama 还是云端服务只要提供base_url和api_key就能统一调用。4. 构建评论样本与提示词模板4.1 准备输入文本以标题中的评论为例我们把核心内容整理成一条完整输入comment_text 朱开锐评 NIP 2-1 WBG 我的角度其实希望WBG能赢骑士之路第一绝对比第二好 IG要力争第一一定是希望WBG能赢NIP粉丝应该期待IG更强。 实际操作中这条文本可能来自直播字幕、微博帖子或采访稿。可以先保存成 CSV 文件再用 pandas 读取。4.2 设计提示词模板提示词质量直接决定抽取结果。要明确要求模型输出 JSON并给出字段说明和示例。下面是一个可复用的模板SYSTEM_PROMPT 你是一个电竞赛事评论分析助手。 你的任务是从用户输入的赛事评论中提取结构化信息并输出 JSON。 不要输出任何额外解释只能输出 JSON 对象。 JSON 字段说明 - stance: 评论者整体倾向支持的队伍或立场例如 希望WBG赢 - views: 评论中的核心观点列表例如 [骑士之路第一比第二好] - reasons: 评论中给出的理由列表如果没有理由返回 [] - suggestions: 评论中提出的建议或期望例如 [IG要力争第一] - target_teams: 评论中提到的战队缩写列表例如 [WBG, NIP, IG] - sentiment: 整体情绪可选值为 positive, negative, neutral 示例输入 我觉得IG今天状态很好WBG需要调整中野节奏。 示例输出 { stance: 看好IG, views: [IG今天状态很好, WBG需要调整中野节奏], reasons: [], suggestions: [WBG需要调整中野节奏], target_teams: [IG, WBG], sentiment: neutral } .strip()这里特意把suggestions和views分开因为评论中“骑士之路第一比第二好”是判断“IG要力争第一”是建议。如果混在一起后续统计就不方便。4.3 提示词注意事项字段名固定为英文避免模型输出中文 key。示例输入/输出不要写太长否则小模型容易模仿示例而忽略真实内容。对 JSON 格式不稳定的情况可以在 prompt 里加上“必须输出合法 JSON”。如果模型输出包含 Markdown 代码块后处理时要去掉 json 标记。5. 调用大模型完成单条评论解析5.1 通用调用函数这里使用 OpenAI 兼容接口方式兼容 Ollama 和大多数云端服务。import json import requests def analyze_comment(text, base_urlhttp://localhost:11434/v1, api_keyollama, modelqwen2.5:7b): url f{base_url}/chat/completions payload { model: model, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: text} ], temperature: 0.2, response_format: {type: json_object} } headers { Authorization: fBearer {api_key}, Content-Type: application/json } resp requests.post(url, jsonpayload, headersheaders, timeout120) resp.raise_for_status() content resp.json()[choices][0][message][content] content content.strip().strip(json).strip() try: result json.loads(content) except json.JSONDecodeError as e: return {error: fJSON解析失败: {e}, raw: content} return result如果使用 Ollama 本地接口默认地址是http://localhost:11434/v1API Key 随意填写。5.2 运行单条测试if __name__ __main__: result analyze_comment(comment_text) print(json.dumps(result, ensure_asciiFalse, indent2))预期输出结构与示例类似重点观察views、suggestions、stance是否正确。以标题样例输入合理输出可能如下{ stance: 希望WBG赢, views: [ 骑士之路第一绝对比第二好, 粉丝应该期待IG更强 ], reasons: [ 骑士之路第一比第二好 ], suggestions: [ IG要力争第一, 希望WBG能赢NIP ], target_teams: [WBG, NIP, IG], sentiment: positive }判断成功的标准是结果 JSON 能够被 Pythonjson.loads正常解析且字段含义与原文一致。如果字段出现明显偏差可以先调整SYSTEM_PROMPT中的示例。6. 批量分析多条评论实际业务中不会只分析一条评论而要把几十条、几百条评论一次性处理完。这里用 pandas 读取 CSV逐条调用逐条分析函数最后保存结果。6.1 准备 CSV 文件创建一个comments.csvid,comment 1,朱开锐评NIP 2-1 WBG希望WBG能赢骑士之路第一比第二好 2,IG要力争第一粉丝应该期待IG更强 3,NIP今天的发挥确实不稳定注意 CSV 编码建议使用 UTF-8避免中文乱码。6.2 批量处理脚本import pandas as pd import json import time from pathlib import Path def batch_analyze(input_path, output_path, modelqwen2.5:7b, sleep_time0.5): df pd.read_csv(input_path, encodingutf-8) results [] for idx, row in df.iterrows(): comment row[comment] print(f正在处理第 {idx 1} 条id{row[id]}) try: result analyze_comment(comment, modelmodel) result[id] row[id] except Exception as e: result { id: row[id], error: str(e) } results.append(result) time.sleep(sleep_time) out_df df.merge(pd.DataFrame(results), onid, howleft) out_df.to_json(output_path, orientrecords, force_asciiFalse, indent2) print(f处理完成结果已保存到 {output_path}) if __name__ __main__: batch_analyze(comments.csv, output.json)这里每处理一条加了 0.5 秒间隔主要用于控制本地模型压力。如果使用云端 API可以根据接口限流调整间隔。6.3 批量任务的失败重试大模型调用偶尔会超时或返回空内容。可以在analyze_comment外面封装一个重试逻辑def analyze_with_retry(text, modelqwen2.5:7b, max_retry3): for attempt in range(max_retry): try: result analyze_comment(text, modelmodel) if result and error not in result: return result except Exception as e: print(f第 {attempt 1} 次尝试失败: {e}) time.sleep(2) return {error: 重试多次后仍然失败, text: text[:50]}批量处理时建议把每条评论的原始内容一起输出方便排查。如果某一条反复失败可以把raw字段保存下来人工检查。7. 通过 FastAPI 封装接口服务如果不想只在本地脚本里运行可以封装成 HTTP 接口让其他服务、前端页面、定时任务统一调用。7.1 编写 API 服务from fastapi import FastAPI, HTTPException from pydantic import BaseModel import json import uvicorn app FastAPI(title电竞评论分析 API) class SingleRequest(BaseModel): text: str class BatchRequest(BaseModel): items: list[SingleRequest] app.post(/analyze) def analyze_single(req: SingleRequest): try: result analyze_comment(req.text) return result except Exception as e: raise HTTPException(status_code500, detailstr(e)) app.post(/analyze_batch) def analyze_batch(req: BatchRequest): results [] for item in req.items: result analyze_comment(item.text) results.append(result) return {results: results} if __name__ __main__: uvicorn.run(app, host127.0.0.1, port8000)7.2 启动与测试启动服务python app.py看到Uvicorn running on http://127.0.0.1:8000即表示启动成功。用 curl 测试单条接口curl -X POST http://127.0.0.1:8000/analyze \ -H Content-Type: application/json \ -d {text: 朱开锐评NIP 2-1 WBG希望WBG能赢骑士之路第一比第二好}用 Python requests 测试import requests resp requests.post( http://127.0.0.1:8000/analyze, json{text: IG要力争第一粉丝应该期待IG更强} ) print(resp.json())接口返回的就是前面定义的结构化 JSON。这个接口可以直接接给数据中台也可以做成一个小的网页服务。8. 资源占用与性能观察8.1 观察模型服务占用如果使用 Ollama 本地模型通过ollama ps查看当前加载的模型和显存占用ollama ps输出里可以看到SIZE和PROCESSOR列。不同量化级别、上下文长度都会影响占用实际占用需要以本机测试为准。8.2 CPU 与 GPU 差异CPU 推理启动慢单条文本耗时可能从几秒到十几秒。适合调试和低频批量任务。GPU 推理显存够用的情况下单条文本通常能明显缩短延迟并发能力也更好。云端 API本机占用几乎可以忽略但受网络延迟和限流影响。8.3 影响性能的关键参数输入长度评论越长需要计算的 token 越多耗时越长。输出长度如果模型输出很长的 JSON 或额外解释响应时间会增加。并发数量本地模型串行处理最稳。批量任务建议控制并发数避免显存溢出。上下文大小Ollama 默认上下文有限处理长评论时可能截断。可以在启动时调整num_ctx。8.4 降低占用与提速使用量化模型例如 4bit 或 8bit推荐 Ollama 自动量化。限制SYSTEM_PROMPT长度不要在 prompt 里塞太多历史样例。批量处理时固定请求间隔避免瞬时压力。如果只做中文短文本抽取小参数模型往往足够没必要强行上大模型。9. 常见问题与排查方法问题现象可能原因排查方式解决方案模型下载失败网络问题或模型名错误检查模型名是否拼写正确查看 Ollama 日志更换网络环境重新执行ollama pull调用本地接口超时模型未加载完成或输入太长观察ollama ps确认模型是否加载提前ollama run预热或减小输入文本返回内容不是 JSON模型能力不足或 prompt 不明确打印模型原始输出确认是否包含代码块在 prompt 中强调只输出 JSON并做后处理剥离api_key报错本地 Ollama 配置了错误的 key确认接口地址和 key 是否匹配本地可填写ollama云端需填写真实 keyCSV 中文乱码编码不是 UTF-8用编辑器另存为 UTF-8重新保存 CSV读取时指定encodingutf-8端口被占用8000 或 11434 被其他进程使用检查端口占用情况更换端口例如--port 8001显存不足模型太大或并发过高查看显存占用和日志换小模型、量化模型降低并发批量任务中断网络波动或接口超时查看中断前输出日志增加重试机制断点续跑10. 最佳实践与使用建议10.1 先小样本测试再全量跑第一次处理时不要直接跑几百条评论。先用 5 到 10 条数据测试确认输出字段稳定后再放量。这样能避免带着错误模板处理完所有数据。10.2 固定 system prompt减少随机性把temperature设置在 0.1 到 0.3 之间让输出尽量稳定。修改 prompt 后需要重新跑一轮小样本回归确认新增字段没有影响已有字段。10.3 对输出做后处理校验大模型偶尔会输出多余的键名、空字符串或者把views和suggestions混在一起。保存结果前先做一层字段清洗def normalize_result(result): # 确保关键字段存在且是列表 for key in [views, reasons, suggestions, target_teams]: if key not in result or not isinstance(result[key], list): result[key] [] return result10.4 数据与代码分离评论存储目录、模型输出目录、日志目录分开管理。建议结构project/ ├── app.py ├── analyzer.py ├── prompts/ │ └── system_prompt.py ├── data/ │ └── comments.csv └── output/ └── result_20250101.json10.5 接口服务限制访问范围FastAPI 服务如果部署到公网必须加鉴权和访问控制。最简单的方式是绑定内网地址或者在反向代理层加 Token。不要直接把没有鉴权的服务暴露到公网。10.6 合规使用评论数据从微博、B 站、虎扑等平台获取评论前先阅读平台的 Robot 协议和用户协议。只分析已公开的个人内容时也需要谨慎处理避免输出可定位到具体个人的敏感信息。分析报告应做脱敏处理尤其不要展示完整用户昵称。10.7 扩展方向后续可以继续做时间序列分析按比赛日统计粉丝情绪变化。多话题聚类用 embedding 把评论聚类成不同讨论主题。自动生成赛报把抽取出的views、suggestions填充进模板生成简要赛前预测或赛后总结。接入直播弹幕使用 WebSocket 将文本推送到分析服务实时输出观点标签。回到开头那条评论本身。这条文本最值得做的不是去争论“谁说得对”而是把它当成一个典型的观点结构化样本。先用一个小模型跑通单条解析再看输出字段是否符合预期。最容易踩的坑是提示词示例太复杂导致小模型跟着示例跑偏最稳妥的做法是保持 prompt 短、字段少、先跑通再优化。这套流程跑通之后换成其他赛事评论、产品评价、新闻评论只需要改一下示例和字段名模型底座的通用抽取能力就能复用到其他领域。