尧图网站建设 
简介《大模型典型示范应用案例集》是一份面向大模型技术研究者、企业AI团队及行业决策者的参考文档系统梳理了2024年前后大模型在各行各业的代表性应用。案例集汇集了阿里云、百度、华为、腾讯、蚂蚁集团、商汤科技等众多知名企业及研究机构的实践覆盖金融、医疗、教育、汽车、政务、智能制造、媒体等多个领域清晰展示出从技术选型、场景落地到业务价值评估的完整过程。资源包仅包含1个PDF文件大小84.49MB内容排版完整适合直接阅读与长期留存。已有146人学习下载对于正在规划大模型应用的企业技术人员、产品经理和研究者来说具有直接的参考价值。阅读该案例集可以快速掌握不同行业的大模型应用模式理解企业实际部署时面临的挑战与解决思路为后续项目实践提供对比与借鉴。1. 大模型典型示范应用案例集不是收藏夹是拿来就能改的落地稿我刚开始接触大模型项目时最头疼的不是模型跑不起来而是拿到一个所谓“案例”不知道该看哪一行。网上到处是“我用大模型做了XX”的帖子可一旦想复现就会发现提示词是截图的、参数是隐去的、评估标准是“感觉还行”。后来我意识到一份能落地的大模型典型示范应用案例集本质上不是文档收藏夹而是一套被验证过的“输入-模型-参数-评估”组合包。它回答的不是“大模型能干什么”而是“在这个场景下用哪个模型、怎么组织上下文、怎么调参、怎么判断效果好”。这篇文章就把这类案例集拆开讲如何分辨好坏、如何选型、如何本地部署和微调落地以及我在复现过程中翻过的车。适合正在做企业AI落地、私有化部署或者想从单个Demo走向稳定交付的工程师。2. 读懂案例集场景、模型、成本三个维度决定你该抄哪个方案2.1 案例集里每个案例都在回答的“铁三角”问题一份好的大模型典型示范应用案例集第一个要看的不是代码而是它是否把“场景-模型-成本”说清楚了。场景决定了任务的边界是开放问答还是固定格式抽取是单轮指令还是多轮对话模型选型决定了效果上限7B、14B还是72B同样的提示词在不同规模模型上的表现差异极大。成本则是很多人忽略的暗坑用商业大模型API时长上下文和多轮会话会迅速烧掉token预算用本地部署则要算显存、CPU内存和电费。我在选择一个案例时会先画一个三角场景复杂度、模型能力、允许成本。如果案例只给了提示词和输出示例却没有说明模型版本和部署方式那它大概率是“观赏案例”不是“落地案例”。比如一个客服工单分类案例如果用7B模型就能做到85%准确率那就没必要上大模型API把数据留在本地更安全。反之如果案例里涉及复杂推理和长文档本地小模型往往力不从心这时用大模型API或更大参数量模型才是合理的。提示词工程和上下文工程在这套判断里只是手段不是目的。很多案例会刻意展示“花式提示词”但你真正要问的是这个场景的难点到底在指令理解还是信息召回还是格式约束搞清楚这一点你才能判断这个案例值不值得抄以及为什么要选择这套模型方案。否则就是把别人的参数搬过来换个场景立刻翻车。2.2 一套合格案例集的通用结构输入、预期、评估缺一不可我所见到的可复现案例集无论应用类型如何都具备四个要素输入样例、预期输出、模型与参数、评估方式。输入样例不是一句“用户问题”而是带业务背景的真实输入比如“用户咨询订单延迟包含订单号和情绪词”。预期输出也不是一句漂亮回答而是标注了格式、颗粒度和边界比如“先道歉再说明原因最后给补偿选项”。模型与参数要具体到模型版本和温度、top_p、max_tokens等。评估方式则是很多人缺失的一环——到底怎么算对举个例子一个“合同关键信息抽取”案例如果只有输入和输出没有评估标准你就无法判断模型抽取的字段是“对的”还是“看起来像”。合格案例集会告诉你用正则校验日期格式用字段级准确率评估或者用LLM作为裁判给输出打分。这套结构看起来繁琐但恰恰是它能复制的根本原因。我一般会拿这个结构去筛选案例集如果一份案例集里80%的案例都能找到这四个要素就值得花时间复现如果只是示范了“大模型能写文案”“大模型能做摘要”那它只能当灵感库不能当技术资产。对于后者我的建议是自己动手给它补上输入、预期和评估把它改造成属于自己的案例。改造过程其实就是一次很好的学习路线。2.3 把案例集变成选型清单一张表过滤掉80%的无效案例面对几十个案例最容易犯的错就是每个都看每个都浅尝辄止。我会把案例集里的信息压缩成一张选型清单用表格快速过滤。这张表包含五个字段业务场景、任务类型、推荐模型、部署方式、首次落地成本。任务类型分为检索增强生成、结构化抽取、内容生成、对话系统、多模态理解等部署方式分为本地私有化、云API、混合架构。成本不只看API价格还要看每次请求的latency和失败重试成本。业务场景任务类型推荐模型部署方式落地成本企业知识库问答检索增强生成7B/14B本地模型Ollama私有化低1张GPU或纯CPU合同信息抽取结构化抽取14B/32B模型或微调本地微调推理中需要标注数据营销文案生成内容生成商业大模型API云端API低按token计费多模态质检多模态理解开源多模态大模型本地部署高需要专用显卡把案例集转成这张表我通常花一小时但能过滤掉80%不适合当下环境的案例。比如团队没有GPU时所有本地微调案例直接跳过数据敏感时所有云端API案例直接跳过。表格里的“首次落地成本”是动态的随着模型尺寸、量化方式和batch大小变化。所以我每次复现一个新案例都会先更新这张表把实际跑通的参数回写进去。这也是把别人的案例变成自己能力的核心动作。3. 用Ollama部署私有大模型本地跑通案例集里的最小RAG问答3.1 为什么先选本地部署数据不出域调试还能白嫖显存案例集里最常见的应用类型就是知识库问答而知识库问答的经典方案是RAG。很多案例会默认你调用大模型API但企业场景下数据往往不能出域。这时就需要本地部署大模型让文档和向量库都留在内网。Ollama是目前最省心的本地部署工具之一它把模型下载、运行和API暴露都封装成了简单命令尤其适合我在案例落地初期做快速验证。选本地部署还有一个实际好处调试成本接近零。用API调一次可能几毛钱但调试提示词可能要几十次本地模型即使效果差一点但你能无限试错。而且本地部署能直接看到模型在prompt里的完整行为包括截断、重复、格式跑偏这些是API返回结果里看不到的。所以我现在的习惯是任何案例先用本地小模型跑通流程再根据效果决定是否换更大模型或升级到API。本地部署不等于效果差。现在主流的7B、14B量化模型在常见任务上已经够用尤其是配合RAG时知识来源被约束在检索结果里模型自己的知识缺陷被大幅淡化。我在一个内部工单答疑项目里用7B模型加RAG把首答准确率从40%提到了75%而推理成本几乎为零。所以别一上来就追求72B先让流程跑起来。3.2 最小启动命令ollama pull和run的参数选择首次使用Ollama只需要两个命令就能把服务跑起来。我推荐用qwen2.5系列因为中文能力强上下文长度也足够。以下是我常用的最小启动命令# 拉取qwen2.5 7B模型默认是q4_k_m量化约4.7GB ollama pull qwen2.5:7b # 启动服务指定监听地址和端口 ollama serve --host 0.0.0.0 --port 11434第一条命令把模型下载到本地磁盘如果已经下载过会自动跳过。模型文件放在Ollama的模型目录里不需要手动管理。第二条命令启动一个HTTP服务默认监听11434端口。--host 0.0.0.0表示允许局域网内其他机器访问这一步在生产环境要谨慎最好配合API网关或防火墙。如果只是本机调试可以省略--host参数只监听127.0.0.1即可。服务启动后可以用curl验证是否正常curl http://localhost:11434/v1/modelsOllama同时提供了原生API和OpenAI兼容API所以后面用Python调用时既可以用requests直接POST也可以用openai库。我建议使用OpenAI兼容接口因为后续如果切到GPT或其他API代码改动最小。3.3 用Python组装RAG流程embedding、检索、生成三步走把案例集里的知识库问答案例落地核心是三步文档切片、向量检索、拼接提示词后让本地模型生成。下面是一个最小实现我刻意没有用LangChain让你看清每一步在做什么import requests import numpy as np from sentence_transformers import SentenceTransformer # 1. 初始化一个轻量embedding模型 embedder SentenceTransformer(BAAI/bge-small-zh-v1.5) # 准备一个简单的知识库每段文本一个切片 docs [ 公司报销流程员工在OA系统提交申请附发票和说明部门主管审批后由财务付款。, 年假规则入职满一年可享受5天年假满三年7天需提前一周申请。, 加班调休工作日加班按1:1调休法定节假日加班按3倍工资计算。 ] doc_vectors embedder.encode(docs) doc_vectors doc_vectors / np.linalg.norm(doc_vectors, axis1, keepdimsTrue) # 2. 输入用户问题检索最相关的切片 query 报销需要什么材料 query_vec embedder.encode([query]) query_vec query_vec / np.linalg.norm(query_vec, axis1, keepdimsTrue) scores doc_vectors query_vec.T # 余弦相似度 top_idx np.argsort(scores[:, 0])[::-1][:2] # 取top2 retrieved \n.join([docs[i] for i in top_idx]) # 3. 拼接提示词调用本地Ollama模型生成回答 prompt f基于以下资料回答问题如果资料中没有答案就回答不知道。 资料 {retrieved} 问题{query} 回答 resp requests.post( http://localhost:11434/v1/chat/completions, json{ model: qwen2.5:7b, messages: [{role: user, content: prompt}], temperature: 0.2, max_tokens: 200 }, timeout30 ) answer resp.json()[choices][0][message][content] print(answer)这段代码的逻辑很直白先用bge-small-zh-v1.5把文档和问题都转成向量然后计算余弦相似度取前两个最相关的切片最后把切片拼进提示词交给Ollama的本地大模型API生成回答。这样做的优势是模型不需要理解全部知识只需要基于给定的切片做摘要和表达幻觉概率会显著下降。参数里最值得留意的是temperature和max_tokens。知识库问答属于事实性任务温度我一般设在0.1到0.3之间太高会让回答发散。max_tokens要根据预期回答长度设置我的经验是200左右够用。还要注意timeout本地模型推理可能会超过默认的2秒所以设30秒比较稳妥。3.4 影响问答质量的三个参数chunk_size、top_k、temperature同样的RAG代码参数不同效果天差地别。第一个是切片大小chunk_size。切片太短单个片段信息量不足检索出来也不够回答切片太长多个主题混在一个向量里检索精度下降。我一般按句子边界切每个切片100到300字。第二个是检索数量top_k。取1个可能漏掉关键信息取5个噪声会淹没答案。我的经验是先取3看效果再调。第三个是温度temperature。低温度适合事实问答高温度适合创意写作。参数推荐值影响调参方向chunk_size100~300字信息密度和检索精度答案缺上下文就调大答非所问就调小top_k2~5召回广度和噪声召回不够就调大噪声干扰就调小temperature0.1~0.3回答确定性和创造性事实问答调低文案生成调高这三个参数是RAG案例里最常调的部分但真正决定效果上限的是embedding模型和知识库质量。如果你的文档本身没有做清洗切片里全是表格和扫描件乱码那再调参数也没用。我见过不少人卡在RAG效果不好反复调温度最后发现是切片太碎把一句话拆成了两半。所以遇到效果问题时先用人工看一眼检索出来的切片再决定要不要动参数。4. 案例集里的微调实战用LoRA把通用模型改造成领域小助手4.1 什么案例适合微调而不是改提示词案例集里有一部分案例会走到微调而不是靠提示词工程解决。判断标准很简单如果同样的输入换了几种提示词写法输出依然不稳定或者格式始终不对那就应该考虑微调。典型场景包括特定的输出格式约束例如“输出JSON且必须包含三个字段”领域术语输入例如医疗报告、法律条文、技术规范还有风格一致性例如客服话术要求耐心、亲切。微调并不是万能的它解决的是“模型不会按你的规则说话”的问题。如果只是偶尔回答不准改提示词更便宜如果模型总是漏掉关键字段或者总是把格式写错那微调才是对症下药。我见过一个合同抽取案例用提示词时模型偶尔会把甲方乙方搞反改成微调后模型学会了字段位置和实体关系错误率降了一个数量级。这就是从“碰运气”变成“有规律”。但注意微调需要数据集这是案例集最有价值的地方。一份优秀案例集会给出完整的指令数据格式甚至包含几十条标注样例。你不需要从零开始而是可以从案例集里挑出当前业务最接近的几组指令模板替换成自己的数据就能快速跑通微调流程。这也是“大模型微调实战”在案例落地里最常见的用法。4.2 从案例集构造微调数据集对话模板和字段映射开源模型的微调数据格式一般分两种单轮指令和多轮对话。以qwen系列为例最通用的是把数据组织成instruction、input、output三个字段。下面是一个JSONL片段{instruction: 抽取合同中的付款条款, input: 甲方应于收到发票后30日内支付全部款项。, output: 付款方式银行转账付款时限30日付款条件收到发票。} {instruction: 抽取合同中的违约条款, input: 如乙方延期交货每延一日向甲方支付合同金额0.5%的违约金。, output: 违约情形延期交货违约后果每日支付0.5%违约金。}把案例集转换成这种格式时我一般会写一个小脚本从原有案例中批量提取而不是手工复制。提取的关键是保持字段的一致性instruction必须描述任务不能写“请回答以下问题”input要包含待处理的原始文本output则是标准答案。这个标准答案非常关键它不只是模型输出的漂亮话而是要精确到模型必须复刻的字段和结构。import json # 假设案例集里是原始记录转换成微调格式 raw_cases [ {场景: 合同付款条款抽取, 原文: 甲方应于收到发票后30日内支付全部款项。, 结果: 付款方式银行转账付款时限30日付款条件收到发票。}, {场景: 合同违约条款抽取, 原文: 如乙方延期交货每延一日向甲方支付合同金额0.5%的违约金。, 结果: 违约情形延期交货违约后果每日支付0.5%违约金。} ] with open(fine_tune_data.jsonl, w, encodingutf-8) as f: for item in raw_cases: sample { instruction: f抽取{item[场景]}中的关键信息, input: item[原文], output: item[结果] } f.write(json.dumps(sample, ensure_asciiFalse) \n)这段脚本把原始案例转成了微调模型需要的JSONL格式。脚本里的raw_cases可以换成从Excel、数据库读出来的记录核心是把业务结果映射到output字段。这里要注意如果案例集的输出是长段落而不是结构化字段微调效果会变差因为模型不容易从长文本里学会精确规则。所以如果可能尽量把输出整理成“方面值”的列表形式让模型学到的是规则而不是文案。4.3 基于PEFT跑通一次LoRA微调的最小脚本微调不需要训练完整模型用LoRA冻结原模型、只训练一小部分参数是当前最主流的做法。下面我用transformers和peft写一个最小脚本模型使用qwen2.5-7b数据使用上一步生成的JSONL文件from datasets import load_dataset from transformers import AutoTokenizer, AutoModelForCausalLM, TrainingArguments, Trainer from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training import torch # 1. 加载模型和分词器这里用4bit量化节省显存 model_name qwen/Qwen2.5-7B tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_name, load_in_4bitTrue, device_mapauto, trust_remote_codeTrue ) # 2. 配置LoRA lora_config LoraConfig( r8, lora_alpha16, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model prepare_model_for_kbit_training(model) model get_peft_model(model, lora_config) # 3. 加载数据集并做tokenize dataset load_dataset(json, data_filesfine_tune_data.jsonl) def tokenize_func(examples): text examples[instruction] \n examples[input] \n examples[output] return tokenizer(text, truncationTrue, max_length512, paddingmax_length) dataset dataset.map(tokenize_func, batchedFalse) train_dataset dataset[train] # 4. 训练参数 training_args TrainingArguments( output_dir./qwen_lora, per_device_train_batch_size1, gradient_accumulation_steps8, num_train_epochs3, learning_rate2e-4, fp16True, save_steps200, logging_steps20, ) trainer Trainer( modelmodel, argstraining_args, train_datasettrain_dataset, ) trainer.train()这段脚本的核心逻辑是用4bit量化加载7B模型降低显存占用然后配置LoRA只对注意力层的四个线性投影做微调之后把数据tokenize成固定长度最后用Trainer完成训练。整个过程在单张24GB显存显卡上可以跑通数据量不大时甚至可以用纯CPU跑只是慢很多。参数里最需要理解的是per_device_train_batch_size和gradient_accumulation_steps。受显存限制单卡batch设成1通过累积8步达到相当于batch size 8的效果。fp16True可以在RTX系列显卡上加速如果是A100等卡可以用bf16True。num_train_epochs我一般设2到5数据量小就设多点数据量大设1到2防止过拟合。4.4 微调参数怎么调lora_rank、target_modules、learning_rateLoRA微调效果不好八成是参数没调对。r是低秩矩阵的秩值越大模型可学习的参数越多表达能力越强但也更容易过拟合。我一般从8开始效果不够就加到16数据量很小就降到4。lora_alpha控制LoRA在下游任务中的影响权重一般设为r的1到2倍。target_modules决定改哪些层默认的注意力层四件套基本够用如果任务需要更强语义理解可以加上mlp相关模块。参数常见范围作用我的调参经验r4~32低秩矩阵维度小数据用4大数据用16再大收益递减lora_alpha8~64微调影响强度设为r的2倍时收敛稳定learning_rate1e-5~5e-4学习率7B模型用2e-4数据量大降到1e-4num_train_epochs1~5训练轮数先看loss达到平台期就停这些参数之间是联动的不能只看单个。比如r调大后如果learning_rate不变训练可能震荡这时应该同步降低学习率。我的习惯是先用小数据跑两个epoch观察训练loss有没有下降如果loss一直在0.5以上纹丝不动就先调learning_rate然后再调r。微调不是玄学但确实需要几次实验才能找到合适的组合。把每次实验的参数和效果记下来回到上一章那张选型清单里慢慢就有体感了。5. 案例集落地避坑5个我翻过车的地方5.1 提示词换模型就失效从ChatGLM到Qwen的格式差异现象案例集里同一段提示词在ChatGLM上表现很好换成Qwen后输出结构完全乱了甚至出现重复内容。原因不同模型的对话模板不同有的模型要求|im_start|标签有的模型用[INST]标签提示词里的角色字段“system”和“user”在不同模型里定义也不一样。案例集如果只给出“提示词内容”而没有给出“模型模板”复现时很容易忽略这部分。解决使用Ollama或vLLM部署时先确认模型对应的chat template。我现在的做法是统一走OpenAI兼容接口让框架自动处理模板同时在提示词本身里显式写明“你是……”避免依赖模型默认的system prompt。遇到换模型就失效的情况先把模板差异排除再调内容。5.2 RAG召回一堆噪声chunk答案反而变差现象加了RAG后模型回答比不加还差甚至把无关文档里的信息也编进去。原因检索阶段召回了大量低相关度切片这些噪声和正确答案混在一起把模型带偏了。常见原因是embedding模型任务不匹配或者top_k设得太大还有切片质量差比如把表格截断成一半。解决先在代码里打印出检索到的前几个切片人工检查它们和问题是否相关。如果不相关先换embedding模型比如从bge-small换到bge-large如果相关再调top_k和chunk_size。还有一个我自己常用的办法是给切片加“标题”权重让包含标题或关键词的切片排到前面这个简单规则经常比调模型更有效。5.3 微调数据混入多轮对话训练Loss震荡不收敛现象训练loss一直上下跳动降到一定程度后不再下降模型输出开始胡言乱语。原因数据集里混了单轮指令和多轮对话但tokenize时没有区分格式模型一会儿学“指令-回答”一会儿学“对话历史-回答”学习目标不一致。另一个原因是learning_rate过高导致最优区域震荡。解决做数据集清理把所有样本统一成单轮指令格式。多轮对话要转成instruction里包含“用户…… 助手…… 用户……”这样的完整历史再让模型预测最后一轮。同时把learning_rate降到1e-4增加warmup_steps让训练前段更平稳。我一般先做一遍数据格式检查统计每条样本的字段和长度再开始训练。5.4 Ollama本地部署OOM显存和模型量化怎么配现象启动Ollama后第一次请求直接报out of memory或者系统开始疯狂使用交换内存服务卡死。原因默认拉取的是Q4量化模型占空间较小但7B模型也需要至少6GB RAM。如果你的电脑只有8GB内存再跑embedding模型和文档处理内存立刻见顶。而且推理时除了显存CPU内存也要预留上下文缓存空间。解决先看机器配置内存小于16GB时优先选择4B或3B的量化模型例如qwen2.5:3b。启动前用ollama ps查看占用如果依然不够减少num_ctx参数把上下文长度从默认的4096降到2048也可以在ollama serve时设置OLLAMA_MAX_LOADED_MODELS1避免同时加载多个模型。我的经验是本地部署最低配置是16GB内存CPU推理可以用但会慢最好还是有一张8GB显存的显卡。5.5 上下文工程没做长度预算长文档被截断现象处理长文档时模型回答总是说“资料不足”或者突然重复检查发现输入被截断了。原因大模型API和服务端都有最大上下文长度限制比如Ollama默认4096你一次性塞入几千字的文档加上提示词超出的部分被静默截断而模型不知道自己的输入被截断了只能基于残缺内容回答。解决在做上下文工程时先计算token长度。中文一个字大概1.5到2个token可以用tokenizer或tiktoken提前计算。如果文档长先用RAG检索而不是把整个文档都塞进prompt。如果业务场景一定要长上下文要么选用支持更长的模型比如qwen2.5的32k版本要么手动分段多次调用再合并结果。我之前在合同分析案例里吃过这个亏后来把输入控制在每一段不超过1500字分三次调用才解决了回答残缺问题。6. 进阶把案例集变成你的回归评估集每次调参都有后悔药6.1 给案例集补上“预期答案”和“判定规则”读完一份案例集后最值得做的事不是照抄而是把它改造成一个私有评估集。我会给每个案例补上两个字段expected_answer和judge_rule。expected_answer是理想输出judge_rule是判断标准可以是一段关键词列表也可以是一个正则表达式或者一条“必须包含XX字段”的规则。有了这个评估集你再改提示词或微调时就能快速知道改动到底是变好了还是变差了。6.2 用一个小脚本批量对比新版和老版模型的输出我常用一个几十行的脚本从评估集里批量跑问题然后把输出和expected_answer做相似度或规则匹配最终输出一行准确率。这样每次调参后都能看到数字变化而不是凭感觉说“好像好了一点”。用这个办法我在一次微调实验里发现learning_rate从2e-4调到1e-5准确率反而升高了4个百分点这是肉眼完全看不出来的差异。数字不会骗人连续试错才能真正积累经验。6.3 我的习惯把改过的案例回写进案例集形成私有版本每当我跑通一个新案例或者把一个公开案例改造得比原来效果更好时我会把结果回写进案例集更新模型版本、参数、踩坑记录和最终评估分数。这样几个月后回头看整个演进过程都在。这个私有案例集后来成了团队内部新人的训练材料也成了我每次向上汇报时的底稿。大模型典型示范应用案例集看的时候是别人的经验改完之后就是你自己的规则。希望这个思路能帮你在自己的项目里少走点弯路。本文还有配套的精品资源点击获取 大模型案例集落地指南：从模型选型到Ollama部署与LoRA微调
简介《大模型典型示范应用案例集》是一份面向大模型技术研究者、企业AI团队及行业决策者的参考文档系统梳理了2024年前后大模型在各行各业的代表性应用。案例集汇集了阿里云、百度、华为、腾讯、蚂蚁集团、商汤科技等众多知名企业及研究机构的实践覆盖金融、医疗、教育、汽车、政务、智能制造、媒体等多个领域清晰展示出从技术选型、场景落地到业务价值评估的完整过程。资源包仅包含1个PDF文件大小84.49MB内容排版完整适合直接阅读与长期留存。已有146人学习下载对于正在规划大模型应用的企业技术人员、产品经理和研究者来说具有直接的参考价值。阅读该案例集可以快速掌握不同行业的大模型应用模式理解企业实际部署时面临的挑战与解决思路为后续项目实践提供对比与借鉴。1. 大模型典型示范应用案例集不是收藏夹是拿来就能改的落地稿我刚开始接触大模型项目时最头疼的不是模型跑不起来而是拿到一个所谓“案例”不知道该看哪一行。网上到处是“我用大模型做了XX”的帖子可一旦想复现就会发现提示词是截图的、参数是隐去的、评估标准是“感觉还行”。后来我意识到一份能落地的大模型典型示范应用案例集本质上不是文档收藏夹而是一套被验证过的“输入-模型-参数-评估”组合包。它回答的不是“大模型能干什么”而是“在这个场景下用哪个模型、怎么组织上下文、怎么调参、怎么判断效果好”。这篇文章就把这类案例集拆开讲如何分辨好坏、如何选型、如何本地部署和微调落地以及我在复现过程中翻过的车。适合正在做企业AI落地、私有化部署或者想从单个Demo走向稳定交付的工程师。2. 读懂案例集场景、模型、成本三个维度决定你该抄哪个方案2.1 案例集里每个案例都在回答的“铁三角”问题一份好的大模型典型示范应用案例集第一个要看的不是代码而是它是否把“场景-模型-成本”说清楚了。场景决定了任务的边界是开放问答还是固定格式抽取是单轮指令还是多轮对话模型选型决定了效果上限7B、14B还是72B同样的提示词在不同规模模型上的表现差异极大。成本则是很多人忽略的暗坑用商业大模型API时长上下文和多轮会话会迅速烧掉token预算用本地部署则要算显存、CPU内存和电费。我在选择一个案例时会先画一个三角场景复杂度、模型能力、允许成本。如果案例只给了提示词和输出示例却没有说明模型版本和部署方式那它大概率是“观赏案例”不是“落地案例”。比如一个客服工单分类案例如果用7B模型就能做到85%准确率那就没必要上大模型API把数据留在本地更安全。反之如果案例里涉及复杂推理和长文档本地小模型往往力不从心这时用大模型API或更大参数量模型才是合理的。提示词工程和上下文工程在这套判断里只是手段不是目的。很多案例会刻意展示“花式提示词”但你真正要问的是这个场景的难点到底在指令理解还是信息召回还是格式约束搞清楚这一点你才能判断这个案例值不值得抄以及为什么要选择这套模型方案。否则就是把别人的参数搬过来换个场景立刻翻车。2.2 一套合格案例集的通用结构输入、预期、评估缺一不可我所见到的可复现案例集无论应用类型如何都具备四个要素输入样例、预期输出、模型与参数、评估方式。输入样例不是一句“用户问题”而是带业务背景的真实输入比如“用户咨询订单延迟包含订单号和情绪词”。预期输出也不是一句漂亮回答而是标注了格式、颗粒度和边界比如“先道歉再说明原因最后给补偿选项”。模型与参数要具体到模型版本和温度、top_p、max_tokens等。评估方式则是很多人缺失的一环——到底怎么算对举个例子一个“合同关键信息抽取”案例如果只有输入和输出没有评估标准你就无法判断模型抽取的字段是“对的”还是“看起来像”。合格案例集会告诉你用正则校验日期格式用字段级准确率评估或者用LLM作为裁判给输出打分。这套结构看起来繁琐但恰恰是它能复制的根本原因。我一般会拿这个结构去筛选案例集如果一份案例集里80%的案例都能找到这四个要素就值得花时间复现如果只是示范了“大模型能写文案”“大模型能做摘要”那它只能当灵感库不能当技术资产。对于后者我的建议是自己动手给它补上输入、预期和评估把它改造成属于自己的案例。改造过程其实就是一次很好的学习路线。2.3 把案例集变成选型清单一张表过滤掉80%的无效案例面对几十个案例最容易犯的错就是每个都看每个都浅尝辄止。我会把案例集里的信息压缩成一张选型清单用表格快速过滤。这张表包含五个字段业务场景、任务类型、推荐模型、部署方式、首次落地成本。任务类型分为检索增强生成、结构化抽取、内容生成、对话系统、多模态理解等部署方式分为本地私有化、云API、混合架构。成本不只看API价格还要看每次请求的latency和失败重试成本。业务场景任务类型推荐模型部署方式落地成本企业知识库问答检索增强生成7B/14B本地模型Ollama私有化低1张GPU或纯CPU合同信息抽取结构化抽取14B/32B模型或微调本地微调推理中需要标注数据营销文案生成内容生成商业大模型API云端API低按token计费多模态质检多模态理解开源多模态大模型本地部署高需要专用显卡把案例集转成这张表我通常花一小时但能过滤掉80%不适合当下环境的案例。比如团队没有GPU时所有本地微调案例直接跳过数据敏感时所有云端API案例直接跳过。表格里的“首次落地成本”是动态的随着模型尺寸、量化方式和batch大小变化。所以我每次复现一个新案例都会先更新这张表把实际跑通的参数回写进去。这也是把别人的案例变成自己能力的核心动作。3. 用Ollama部署私有大模型本地跑通案例集里的最小RAG问答3.1 为什么先选本地部署数据不出域调试还能白嫖显存案例集里最常见的应用类型就是知识库问答而知识库问答的经典方案是RAG。很多案例会默认你调用大模型API但企业场景下数据往往不能出域。这时就需要本地部署大模型让文档和向量库都留在内网。Ollama是目前最省心的本地部署工具之一它把模型下载、运行和API暴露都封装成了简单命令尤其适合我在案例落地初期做快速验证。选本地部署还有一个实际好处调试成本接近零。用API调一次可能几毛钱但调试提示词可能要几十次本地模型即使效果差一点但你能无限试错。而且本地部署能直接看到模型在prompt里的完整行为包括截断、重复、格式跑偏这些是API返回结果里看不到的。所以我现在的习惯是任何案例先用本地小模型跑通流程再根据效果决定是否换更大模型或升级到API。本地部署不等于效果差。现在主流的7B、14B量化模型在常见任务上已经够用尤其是配合RAG时知识来源被约束在检索结果里模型自己的知识缺陷被大幅淡化。我在一个内部工单答疑项目里用7B模型加RAG把首答准确率从40%提到了75%而推理成本几乎为零。所以别一上来就追求72B先让流程跑起来。3.2 最小启动命令ollama pull和run的参数选择首次使用Ollama只需要两个命令就能把服务跑起来。我推荐用qwen2.5系列因为中文能力强上下文长度也足够。以下是我常用的最小启动命令# 拉取qwen2.5 7B模型默认是q4_k_m量化约4.7GB ollama pull qwen2.5:7b # 启动服务指定监听地址和端口 ollama serve --host 0.0.0.0 --port 11434第一条命令把模型下载到本地磁盘如果已经下载过会自动跳过。模型文件放在Ollama的模型目录里不需要手动管理。第二条命令启动一个HTTP服务默认监听11434端口。--host 0.0.0.0表示允许局域网内其他机器访问这一步在生产环境要谨慎最好配合API网关或防火墙。如果只是本机调试可以省略--host参数只监听127.0.0.1即可。服务启动后可以用curl验证是否正常curl http://localhost:11434/v1/modelsOllama同时提供了原生API和OpenAI兼容API所以后面用Python调用时既可以用requests直接POST也可以用openai库。我建议使用OpenAI兼容接口因为后续如果切到GPT或其他API代码改动最小。3.3 用Python组装RAG流程embedding、检索、生成三步走把案例集里的知识库问答案例落地核心是三步文档切片、向量检索、拼接提示词后让本地模型生成。下面是一个最小实现我刻意没有用LangChain让你看清每一步在做什么import requests import numpy as np from sentence_transformers import SentenceTransformer # 1. 初始化一个轻量embedding模型 embedder SentenceTransformer(BAAI/bge-small-zh-v1.5) # 准备一个简单的知识库每段文本一个切片 docs [ 公司报销流程员工在OA系统提交申请附发票和说明部门主管审批后由财务付款。, 年假规则入职满一年可享受5天年假满三年7天需提前一周申请。, 加班调休工作日加班按1:1调休法定节假日加班按3倍工资计算。 ] doc_vectors embedder.encode(docs) doc_vectors doc_vectors / np.linalg.norm(doc_vectors, axis1, keepdimsTrue) # 2. 输入用户问题检索最相关的切片 query 报销需要什么材料 query_vec embedder.encode([query]) query_vec query_vec / np.linalg.norm(query_vec, axis1, keepdimsTrue) scores doc_vectors query_vec.T # 余弦相似度 top_idx np.argsort(scores[:, 0])[::-1][:2] # 取top2 retrieved \n.join([docs[i] for i in top_idx]) # 3. 拼接提示词调用本地Ollama模型生成回答 prompt f基于以下资料回答问题如果资料中没有答案就回答不知道。 资料 {retrieved} 问题{query} 回答 resp requests.post( http://localhost:11434/v1/chat/completions, json{ model: qwen2.5:7b, messages: [{role: user, content: prompt}], temperature: 0.2, max_tokens: 200 }, timeout30 ) answer resp.json()[choices][0][message][content] print(answer)这段代码的逻辑很直白先用bge-small-zh-v1.5把文档和问题都转成向量然后计算余弦相似度取前两个最相关的切片最后把切片拼进提示词交给Ollama的本地大模型API生成回答。这样做的优势是模型不需要理解全部知识只需要基于给定的切片做摘要和表达幻觉概率会显著下降。参数里最值得留意的是temperature和max_tokens。知识库问答属于事实性任务温度我一般设在0.1到0.3之间太高会让回答发散。max_tokens要根据预期回答长度设置我的经验是200左右够用。还要注意timeout本地模型推理可能会超过默认的2秒所以设30秒比较稳妥。3.4 影响问答质量的三个参数chunk_size、top_k、temperature同样的RAG代码参数不同效果天差地别。第一个是切片大小chunk_size。切片太短单个片段信息量不足检索出来也不够回答切片太长多个主题混在一个向量里检索精度下降。我一般按句子边界切每个切片100到300字。第二个是检索数量top_k。取1个可能漏掉关键信息取5个噪声会淹没答案。我的经验是先取3看效果再调。第三个是温度temperature。低温度适合事实问答高温度适合创意写作。参数推荐值影响调参方向chunk_size100~300字信息密度和检索精度答案缺上下文就调大答非所问就调小top_k2~5召回广度和噪声召回不够就调大噪声干扰就调小temperature0.1~0.3回答确定性和创造性事实问答调低文案生成调高这三个参数是RAG案例里最常调的部分但真正决定效果上限的是embedding模型和知识库质量。如果你的文档本身没有做清洗切片里全是表格和扫描件乱码那再调参数也没用。我见过不少人卡在RAG效果不好反复调温度最后发现是切片太碎把一句话拆成了两半。所以遇到效果问题时先用人工看一眼检索出来的切片再决定要不要动参数。4. 案例集里的微调实战用LoRA把通用模型改造成领域小助手4.1 什么案例适合微调而不是改提示词案例集里有一部分案例会走到微调而不是靠提示词工程解决。判断标准很简单如果同样的输入换了几种提示词写法输出依然不稳定或者格式始终不对那就应该考虑微调。典型场景包括特定的输出格式约束例如“输出JSON且必须包含三个字段”领域术语输入例如医疗报告、法律条文、技术规范还有风格一致性例如客服话术要求耐心、亲切。微调并不是万能的它解决的是“模型不会按你的规则说话”的问题。如果只是偶尔回答不准改提示词更便宜如果模型总是漏掉关键字段或者总是把格式写错那微调才是对症下药。我见过一个合同抽取案例用提示词时模型偶尔会把甲方乙方搞反改成微调后模型学会了字段位置和实体关系错误率降了一个数量级。这就是从“碰运气”变成“有规律”。但注意微调需要数据集这是案例集最有价值的地方。一份优秀案例集会给出完整的指令数据格式甚至包含几十条标注样例。你不需要从零开始而是可以从案例集里挑出当前业务最接近的几组指令模板替换成自己的数据就能快速跑通微调流程。这也是“大模型微调实战”在案例落地里最常见的用法。4.2 从案例集构造微调数据集对话模板和字段映射开源模型的微调数据格式一般分两种单轮指令和多轮对话。以qwen系列为例最通用的是把数据组织成instruction、input、output三个字段。下面是一个JSONL片段{instruction: 抽取合同中的付款条款, input: 甲方应于收到发票后30日内支付全部款项。, output: 付款方式银行转账付款时限30日付款条件收到发票。} {instruction: 抽取合同中的违约条款, input: 如乙方延期交货每延一日向甲方支付合同金额0.5%的违约金。, output: 违约情形延期交货违约后果每日支付0.5%违约金。}把案例集转换成这种格式时我一般会写一个小脚本从原有案例中批量提取而不是手工复制。提取的关键是保持字段的一致性instruction必须描述任务不能写“请回答以下问题”input要包含待处理的原始文本output则是标准答案。这个标准答案非常关键它不只是模型输出的漂亮话而是要精确到模型必须复刻的字段和结构。import json # 假设案例集里是原始记录转换成微调格式 raw_cases [ {场景: 合同付款条款抽取, 原文: 甲方应于收到发票后30日内支付全部款项。, 结果: 付款方式银行转账付款时限30日付款条件收到发票。}, {场景: 合同违约条款抽取, 原文: 如乙方延期交货每延一日向甲方支付合同金额0.5%的违约金。, 结果: 违约情形延期交货违约后果每日支付0.5%违约金。} ] with open(fine_tune_data.jsonl, w, encodingutf-8) as f: for item in raw_cases: sample { instruction: f抽取{item[场景]}中的关键信息, input: item[原文], output: item[结果] } f.write(json.dumps(sample, ensure_asciiFalse) \n)这段脚本把原始案例转成了微调模型需要的JSONL格式。脚本里的raw_cases可以换成从Excel、数据库读出来的记录核心是把业务结果映射到output字段。这里要注意如果案例集的输出是长段落而不是结构化字段微调效果会变差因为模型不容易从长文本里学会精确规则。所以如果可能尽量把输出整理成“方面值”的列表形式让模型学到的是规则而不是文案。4.3 基于PEFT跑通一次LoRA微调的最小脚本微调不需要训练完整模型用LoRA冻结原模型、只训练一小部分参数是当前最主流的做法。下面我用transformers和peft写一个最小脚本模型使用qwen2.5-7b数据使用上一步生成的JSONL文件from datasets import load_dataset from transformers import AutoTokenizer, AutoModelForCausalLM, TrainingArguments, Trainer from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training import torch # 1. 加载模型和分词器这里用4bit量化节省显存 model_name qwen/Qwen2.5-7B tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_name, load_in_4bitTrue, device_mapauto, trust_remote_codeTrue ) # 2. 配置LoRA lora_config LoraConfig( r8, lora_alpha16, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model prepare_model_for_kbit_training(model) model get_peft_model(model, lora_config) # 3. 加载数据集并做tokenize dataset load_dataset(json, data_filesfine_tune_data.jsonl) def tokenize_func(examples): text examples[instruction] \n examples[input] \n examples[output] return tokenizer(text, truncationTrue, max_length512, paddingmax_length) dataset dataset.map(tokenize_func, batchedFalse) train_dataset dataset[train] # 4. 训练参数 training_args TrainingArguments( output_dir./qwen_lora, per_device_train_batch_size1, gradient_accumulation_steps8, num_train_epochs3, learning_rate2e-4, fp16True, save_steps200, logging_steps20, ) trainer Trainer( modelmodel, argstraining_args, train_datasettrain_dataset, ) trainer.train()这段脚本的核心逻辑是用4bit量化加载7B模型降低显存占用然后配置LoRA只对注意力层的四个线性投影做微调之后把数据tokenize成固定长度最后用Trainer完成训练。整个过程在单张24GB显存显卡上可以跑通数据量不大时甚至可以用纯CPU跑只是慢很多。参数里最需要理解的是per_device_train_batch_size和gradient_accumulation_steps。受显存限制单卡batch设成1通过累积8步达到相当于batch size 8的效果。fp16True可以在RTX系列显卡上加速如果是A100等卡可以用bf16True。num_train_epochs我一般设2到5数据量小就设多点数据量大设1到2防止过拟合。4.4 微调参数怎么调lora_rank、target_modules、learning_rateLoRA微调效果不好八成是参数没调对。r是低秩矩阵的秩值越大模型可学习的参数越多表达能力越强但也更容易过拟合。我一般从8开始效果不够就加到16数据量很小就降到4。lora_alpha控制LoRA在下游任务中的影响权重一般设为r的1到2倍。target_modules决定改哪些层默认的注意力层四件套基本够用如果任务需要更强语义理解可以加上mlp相关模块。参数常见范围作用我的调参经验r4~32低秩矩阵维度小数据用4大数据用16再大收益递减lora_alpha8~64微调影响强度设为r的2倍时收敛稳定learning_rate1e-5~5e-4学习率7B模型用2e-4数据量大降到1e-4num_train_epochs1~5训练轮数先看loss达到平台期就停这些参数之间是联动的不能只看单个。比如r调大后如果learning_rate不变训练可能震荡这时应该同步降低学习率。我的习惯是先用小数据跑两个epoch观察训练loss有没有下降如果loss一直在0.5以上纹丝不动就先调learning_rate然后再调r。微调不是玄学但确实需要几次实验才能找到合适的组合。把每次实验的参数和效果记下来回到上一章那张选型清单里慢慢就有体感了。5. 案例集落地避坑5个我翻过车的地方5.1 提示词换模型就失效从ChatGLM到Qwen的格式差异现象案例集里同一段提示词在ChatGLM上表现很好换成Qwen后输出结构完全乱了甚至出现重复内容。原因不同模型的对话模板不同有的模型要求|im_start|标签有的模型用[INST]标签提示词里的角色字段“system”和“user”在不同模型里定义也不一样。案例集如果只给出“提示词内容”而没有给出“模型模板”复现时很容易忽略这部分。解决使用Ollama或vLLM部署时先确认模型对应的chat template。我现在的做法是统一走OpenAI兼容接口让框架自动处理模板同时在提示词本身里显式写明“你是……”避免依赖模型默认的system prompt。遇到换模型就失效的情况先把模板差异排除再调内容。5.2 RAG召回一堆噪声chunk答案反而变差现象加了RAG后模型回答比不加还差甚至把无关文档里的信息也编进去。原因检索阶段召回了大量低相关度切片这些噪声和正确答案混在一起把模型带偏了。常见原因是embedding模型任务不匹配或者top_k设得太大还有切片质量差比如把表格截断成一半。解决先在代码里打印出检索到的前几个切片人工检查它们和问题是否相关。如果不相关先换embedding模型比如从bge-small换到bge-large如果相关再调top_k和chunk_size。还有一个我自己常用的办法是给切片加“标题”权重让包含标题或关键词的切片排到前面这个简单规则经常比调模型更有效。5.3 微调数据混入多轮对话训练Loss震荡不收敛现象训练loss一直上下跳动降到一定程度后不再下降模型输出开始胡言乱语。原因数据集里混了单轮指令和多轮对话但tokenize时没有区分格式模型一会儿学“指令-回答”一会儿学“对话历史-回答”学习目标不一致。另一个原因是learning_rate过高导致最优区域震荡。解决做数据集清理把所有样本统一成单轮指令格式。多轮对话要转成instruction里包含“用户…… 助手…… 用户……”这样的完整历史再让模型预测最后一轮。同时把learning_rate降到1e-4增加warmup_steps让训练前段更平稳。我一般先做一遍数据格式检查统计每条样本的字段和长度再开始训练。5.4 Ollama本地部署OOM显存和模型量化怎么配现象启动Ollama后第一次请求直接报out of memory或者系统开始疯狂使用交换内存服务卡死。原因默认拉取的是Q4量化模型占空间较小但7B模型也需要至少6GB RAM。如果你的电脑只有8GB内存再跑embedding模型和文档处理内存立刻见顶。而且推理时除了显存CPU内存也要预留上下文缓存空间。解决先看机器配置内存小于16GB时优先选择4B或3B的量化模型例如qwen2.5:3b。启动前用ollama ps查看占用如果依然不够减少num_ctx参数把上下文长度从默认的4096降到2048也可以在ollama serve时设置OLLAMA_MAX_LOADED_MODELS1避免同时加载多个模型。我的经验是本地部署最低配置是16GB内存CPU推理可以用但会慢最好还是有一张8GB显存的显卡。5.5 上下文工程没做长度预算长文档被截断现象处理长文档时模型回答总是说“资料不足”或者突然重复检查发现输入被截断了。原因大模型API和服务端都有最大上下文长度限制比如Ollama默认4096你一次性塞入几千字的文档加上提示词超出的部分被静默截断而模型不知道自己的输入被截断了只能基于残缺内容回答。解决在做上下文工程时先计算token长度。中文一个字大概1.5到2个token可以用tokenizer或tiktoken提前计算。如果文档长先用RAG检索而不是把整个文档都塞进prompt。如果业务场景一定要长上下文要么选用支持更长的模型比如qwen2.5的32k版本要么手动分段多次调用再合并结果。我之前在合同分析案例里吃过这个亏后来把输入控制在每一段不超过1500字分三次调用才解决了回答残缺问题。6. 进阶把案例集变成你的回归评估集每次调参都有后悔药6.1 给案例集补上“预期答案”和“判定规则”读完一份案例集后最值得做的事不是照抄而是把它改造成一个私有评估集。我会给每个案例补上两个字段expected_answer和judge_rule。expected_answer是理想输出judge_rule是判断标准可以是一段关键词列表也可以是一个正则表达式或者一条“必须包含XX字段”的规则。有了这个评估集你再改提示词或微调时就能快速知道改动到底是变好了还是变差了。6.2 用一个小脚本批量对比新版和老版模型的输出我常用一个几十行的脚本从评估集里批量跑问题然后把输出和expected_answer做相似度或规则匹配最终输出一行准确率。这样每次调参后都能看到数字变化而不是凭感觉说“好像好了一点”。用这个办法我在一次微调实验里发现learning_rate从2e-4调到1e-5准确率反而升高了4个百分点这是肉眼完全看不出来的差异。数字不会骗人连续试错才能真正积累经验。6.3 我的习惯把改过的案例回写进案例集形成私有版本每当我跑通一个新案例或者把一个公开案例改造得比原来效果更好时我会把结果回写进案例集更新模型版本、参数、踩坑记录和最终评估分数。这样几个月后回头看整个演进过程都在。这个私有案例集后来成了团队内部新人的训练材料也成了我每次向上汇报时的底稿。大模型典型示范应用案例集看的时候是别人的经验改完之后就是你自己的规则。希望这个思路能帮你在自己的项目里少走点弯路。本文还有配套的精品资源点击获取