大模型入门系统教程：从概念、部署到微调全链路实战

后台经常有人问我同一个问题我想入门大模型但网上的资料要么太零散要么一上来就甩一堆论文和代码根本不知道从哪里下手。这篇系统性入门资料就是想把大模型这件事从概念、生态、学习路线、本地部署到应用开发一次性讲清楚让你看完之后既有全局认知也能动手跑起第一个模型。这篇文章适合完全没有基础的新手也适合已经会调API但想深入理解原理的开发者。我会尽量用大白话解释清楚那些吓人的术语同时给出可以直接照做的命令和配置。1. 先建立坐标系大模型是什么能力边界在哪1.1 从大型神经网络到通用文字接口大模型简称LLMLarge Language Model本质上是一个参数规模非常大的神经网络它通过海量文本数据训练出来学会了语言的统计规律和知识。它的输入是文字输出也是文字但在文字的背后它已经拥有了翻译、总结、编程、推理、信息抽取等能力。很多人的误解是大模型就是一个更聪明的聊天机器人。实际上聊天只是它能力的一种呈现方式。你可以把它理解成一台通用文字计算器——你给它一段文字任务它返回一段文字结果至于这段结果是对话、代码、表格、JSON还是SQL完全取决于你怎么描述需求。我个人的体会是入门大模型第一个要建立的认知就是不要把它当成数据库它不一定知道2025年之后发生的事也不要把它当成搜索引擎它回答问题时是凭记忆生成而不是检索事实。理解了这两点你之后遇到的很多翻车场景就都有了解释。1.2 Token、上下文窗口、参数规模这三个词必须搞清这三个概念是后续所有讨论的地基。Token词元模型读取文本的最小单位。一段中文可能被切分成多个Token通常一个汉字约占1到1.5个Token一个英文单词约1个Token。计费、上下文长度限制都是按Token算的。上下文窗口Context Window模型一次能看到的文字总量。比如8K上下文意味着它一次最多能处理大约8000个Token的输入加输出超出部分就会报错或被截断。现在主流模型已经做到128K甚至200K但长度越长对计算资源的要求也越高。参数规模7B、13B、72B等模型内部权重的数量B表示十亿。参数越多理论上知识越丰富、推理能力越强但需要的显存和算力也越大。7B模型可以在消费级显卡上跑72B模型通常需要多张服务器级显卡。有个还比较直观的类比Token是模型的识字量上下文窗口是模型的工作台大小参数规模是模型的大脑容量。三者共同决定了这个模型能做什么、能做多快、能做多复杂。1.3 大模型能做什么从写文案到调度工具把能力边界搞清楚之后你会发现大模型的落地场景其实就几大类内容生产类写文案、写周报、润色、翻译、生成代码。这类任务门槛最低用提示词就能做得不错。知识处理类信息抽取、文档总结、问答系统。这类任务通常要结合检索增强RAG因为模型本身的知识有截止时间而企业内部的资料它没见过。推理调度类让模型调用工具、操作API、做Agent决策。比如根据用户指令查询天气接口、订机票、操作数据库这属于进阶玩法需要配合函数调用或者Agent框架使用。多模态类输入图片、音频、视频输出文字描述或生成内容。比如让模型识别图片里的物体、根据一段录音生成会议纪要。对刚入门的人来说我建议先把精力放在第一类和第二类因为这两类见效最快也能帮你建立对大模型能力的直觉判断。2. 生态地图一览从国际主流到国内开源我做了张选型表2.1 世界有哪些知名的大模型这个问题的答案每隔几个月就要更新一次因为大模型的迭代速度实在太快了。截至我写这篇文章时值得关注的模型大致分两个阵营阵营代表模型特点国际商业OpenAI GPT-4o系列、Anthropic Claude系列、Google Gemini系列综合能力强闭源按API付费国际开源Meta Llama系列、Mistral系列社区生态好可以本地部署国内商业阿里通义千问Qwen大模型、字节豆包、智谱GLM中文表现优秀API接入方便国内开源Qwen系列、DeepSeek系列、GLM系列开源权重中文数据突出适合私有化部署这里我不太想把它做成一个简单的排行榜因为最强这个概念在你的实际场景里未必有意义。如果你要的是API调用、快速上线产品商业模型通常是省心选择如果你要的是数据隐私、定制化训练、控制成本开源模型基本是必走的路。2.2 开源与闭源怎么选免费API到底靠不靠谱选模型的第一步永远是确认两件事你的数据能不能出本地以及你的预算到底是多少。如果数据涉及公司内部机密或者医疗、金融信息闭源API基本不用考虑优先选开源模型自部署。如果是个人学习、做Demo、写点自动化工具直接用云厂商API就行省心省力。很多人问免费大模型API靠不靠谱。我的看法是适合学习和验证不适合生产。免费额度通常有QPS限制、模型版本落后、高峰时段排队等问题。真正跑业务还是要按量付费——不过现在国内很多大模型API价格已经非常低了几块钱能跑几百万Token成本根本不是问题。2.3 参数规模与量化7B到72B你怎么挑开源模型选型时除了看参数规模还要看一个很关键的东西量化格式。同样的模型从FP16到INT4量化体积能缩小到原来的四分之一推理速度也大幅提升代价是精度略微下降。目前最常见的本地部署格式是GGUF由llama.cpp生态推动几乎支持所有主流开源模型。量化等级的选择经验Q2_K体积最小效果损失明显只适合低配电脑尝鲜。Q4_K_M性价比之王普通显卡和16G内存的电脑首选。Q5_K_M效果接近原版对内存要求稍高。Q8_0几乎无损但体积大适合显存充足的用户。参数规模方面在没有专业显卡的情况下7B到14B是最实际的区间如果你有24G显存的显卡可以挑战32B想跑70B以上要么用多卡服务器要么用Apple Silicon的高内存Mac跑GGUF大模型。我见过很多新手一上来就想跑70B结果下载了200GB的模型文件电脑根本带不动白白浪费时间。先跑小模型把流程走通再逐步升级才是正确节奏。3. 三步走学习路线提示词工程、上下文工程、微调3.1 提示词工程最基础的落地技能很多新手入门时最大的错觉是提示词就是把需求说清楚。实际上提示词工程是一门有方法论可循的技能。从结构化角度一个高质量的提示词通常包含以下部分角色设定告诉模型它要扮演什么角色影响回答风格和知识调用方式。任务描述明确要做什么最好带上输出格式。约束条件比如不超过200字不要使用专业术语只输出JSON。示例Few-shot给出1到3个输入输出例子模型会按照示例的格式和风格生成。这是目前性价比最高的技巧之一。进阶技巧是思维链CoTChain of Thought。遇到推理类问题比如数学题、逻辑题最有效的做法是在提示词里加一句请一步步思考把推理过程写出来。模型在输出推理过程时准确率会明显提升。另外要注意同一个提示词在不同模型上的效果并不一致通用型提示词拿到技术类模型上很可能浪费了后者的编程能力反之亦然。3.2 上下文工程用RAG补足知识短板上下文工程的核心理念是既然模型的知识有截止时间那我就在提问时动态地把相关资料塞进上下文里让它看着资料回答问题。这就是RAG检索增强生成的基本思路。RAG流程并不神秘就三步把文档切分成小块用向量模型变成向量存入向量数据库。用户提问时把问题也转成向量在数据库中检索相似的文档片段。将检索到的文档片段和原始问题一起交给大模型让它基于这些材料生成回答。为什么先学RAG而不是直接学微调因为对绝大多数业务问题模型不知道的根源是知识不足而不是模型能力不足。你用微调去教模型记住新知识效率低、成本高、还容易影响原有能力而用RAG把资料喂给它改资料就能改答案完全不需要重新训练模型。我强烈建议在你动任何微调念头之前先用RAG跑一遍大概率能满足需求。上下文工程还包括上下文窗口管理比如长对话中怎么压缩历史、怎么截断、怎么避免模型忘掉前面的指令。这些细节在开发真实应用时会反复遇到。3.3 微调什么时候需要什么时候别碰微调是在预训练模型的基础上用特定数据集继续训练让模型学会某种特定行为模式或特定领域知识。比如让通用模型变成客服专家、变成法律文书助手。但我必须强调一个反直觉的结论80%的微调需求其实是伪需求。你需要的可能只是更好的提示词、更多的示例、或者一套RAG。微调最适合的场景是让模型学习一种稳定的输出格式或行为习惯比如始终用JSON返回总是用四川话回答严格按照公司术语模板写报告。至于真正的领域知识补充RAG仍然是首选。如果确定要微调入门阶段请优先学LoRA低秩适配。它只训练原模型的一小部分参数显存占用小普通显卡就能跑效果在很多场景下已经很接近全量微调。千万别一上来就全参数微调那是服务器集群才干的事。4. 本地部署实战从Ollama到GGUF把你的电脑变成模型服务器4.1 Ollama五步跑起第一个模型本地部署大模型目前对新手最友好的是Ollama。它几乎把下载模型、跑模型、提供API这几件事做到了一键化真正做到让个人电脑智能化。安装过程很简单从Ollama官网下载对应系统的安装包装完打开终端验证一下即可。# 启动服务 ollama serve # 拉取并运行Qwen2.5 7B模型 ollama run qwen2.5:7b执行第二条命令后Ollama会自动从模型仓库下载权重文件然后进入一个类似ChatGPT的交互界面直接就可以对话。整个过程不需要手动配置Python环境不需要处理CUDA依赖对新手非常友好。跑起来之后Ollama会默认在本地启动一个HTTP服务端口是11434。这意味着你的电脑已经变成了一台小型的模型服务器# 查看本地已有哪些模型 ollama list # 查看模型占用的资源情况 ollama ps我建议你下载模型时留意参数版本qwen2.5:7b是基础版本而带-instruct后缀的版本针对性更强对话体验更好一些。另外还有一个常用参数的写法示例qwen2.5:0.5b这种小模型适合低配电脑用来把流程跑通。4.2 llama.cpp与GGUF没有大显存也能玩如果Ollama在你的机器上跑不动或者你手里就有一台很老的电脑另一个方案就是llama.cpp。它最大的特点是极度优化了CPU推理没有独立显卡也能跑出不错的速度。流程分三步先克隆源码编译再下载GGUF格式的模型文件最后用命令行跑模型。# 1. 编译llama.cpp git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j # 2. 运行GGUF模型 ./build/bin/llama-cli -m /path/to/qwen2.5-7b-instruct-q4_k_m.gguf -p 你好GGUF模型文件可以在Hugging Face、ModelScope这类模型下载平台上获取。注意同一模型会有不同的量化版本文件大小和效果不一样优先选Q4_K_M不会错。这里要专门提一下macOS用户Apple Silicon芯片的Mac因为统一内存架构可以加载比同价位PC更大的模型。很多人在16G内存的MacBook上跑14B模型速度完全可用。跑本地大模型大内存比大显存更重要这是跟传统理解差别最大的一点。4.3 Windows下的GPU选型问题TCC与WDDM如果你在Windows上部署并且有NVIDIA显卡可能会遇到一个细节有些计算工具会询问或检测驱动模型是TCC还是WDDM。简单解释一下**WDDMWindows Display Driver Model**是Windows的默认显示驱动模式显卡既负责屏幕显示也负责计算。好处是即插即用坏处是图形任务会抢占算力推理性能有一定损耗。**TCCTesla Compute Cluster**是NVIDIA为专业计算卡提供的模式显卡完全用于计算不再输出画面推理性能更稳定。对个人电脑来说高性能游戏显卡在WDDM模式下完全够用不需要折腾TCC。但如果是服务器上的专业计算卡建议查看一下NVIDIA控制面板在工作站选项里把计算卡的驱动模型切换为TCC部署vLLM这类推理引擎时效率会有提升。务必注意的是TCC模式会关闭该显卡的显示输出所以不要在主卡上切换否则屏幕会黑掉。我之前帮朋友排查过一次诡异的重启问题最后发现就是他把主显卡切成了TCC模式系统找不到显示设备。4.4 本地模型对外提供APIOpenAI兼容协议部署本地模型不只是为了自己聊天更重要的价值是把它作为后端服务供其他应用调用。Ollama和llama.cpp都提供了HTTP接口而且生态都兼容OpenAI的API格式。这意味着你用习惯了云厂商API的那套代码改个base_url就能接本地模型。一个最典型的调用示例Pythonfrom openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama # 本地服务任意字符串占位即可 ) resp client.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: 你是一个技术助手。}, {role: user, content: 用三句话解释什么是RAG} ] ) print(resp.choices[0].message.content)既然协议是兼容的那你完全可以先在本地用小模型调试代码确认没问题后再切到云端的大模型API非常灵活。5. 应用开发第一课API对接与SSE流式输出5.1 怎么写一个最小可用的对话接口从零开发一个大模型应用最核心的任务就是封装与大模型的交互逻辑。基于什么技术栈封装我的建议是Java/Spring生态选Spring AIPython生态直接用OpenAI SDK前端负责渲染和中断。先用Python写一个FastAPI接口把大模型的对话能力暴露给前端from fastapi import FastAPI from fastapi.responses import StreamingResponse from openai import OpenAI app FastAPI() client OpenAI(base_urlhttp://localhost:11434/v1, api_keyollama) app.post(/chat) async def chat(prompt: str): # 普通非流式 resp client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: prompt}] ) return {answer: resp.choices[0].message.content}这个版本能跑但体验很差。因为大模型生成文字是需要时间的生成一个几百字的长回答可能要几十秒如果前端要等全部生成完才显示用户体验就是转了二十多秒忽然蹦出一整篇。要解决这个问题必须上流式输出。5.2 SSE流式输出原理与前端实现SSEServer-Sent Events是Web开发里并不新鲜的一项技术它允许服务器持续向客户端推送数据。大模型流式输出的应用场景里它的格式通常是这样的data: {choices: [{delta: {content: 你好}}]} data: {choices: [{delta: {content: }}]} data: [DONE]服务端代码其实很简单就是把OpenAI SDK返回的流式数据转成SSE格式from fastapi import FastAPI from fastapi.responses import StreamingResponse from openai import OpenAI app FastAPI() client OpenAI(base_urlhttp://localhost:11434/v1, api_keyollama) app.post(/chat/stream) async def chat_stream(prompt: str): stream client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: prompt}], streamTrue ) def event_generator(): for chunk in stream: delta chunk.choices[0].delta if delta and delta.content: yield fdata: {delta.content}\n\n yield data: [DONE]\n\n return StreamingResponse(event_generator(), media_typetext/event-stream)前端用fetch的流式读取来解析关键点是要处理Buffer边界、累积不完整的SSE消息以及配合AbortController实现停止生成按钮const controller new AbortController(); const { signal } controller; const response await fetch(/chat/stream?prompt encodeURIComponent(prompt), { signal }); const reader response.body.getReader(); const decoder new TextDecoder(); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); const parts buffer.split(\n\n); buffer parts.pop(); // 保留最后一个不完整的消息 for (const part of parts) { if (part.startsWith(data: )) { const data part.slice(6); if (data [DONE]) break; // 将增量追加到界面上 renderDelta(data); } } } // 用户点击停止按钮时调用 function stop() { controller.abort(); }这段代码里最容易踩的坑有两个一是不用buffer拼接直接按data:切分会导致中文乱码因为一个中文字符可能被拆在两个数据块里二是忘记了处理[DONE]结束标志导致前端一直等不到结束信号。5.3 Spring AI还是自己封装取决于你的技术栈Java后端开发者经常会问是不是要用Spring AI。我的建议是如果你所在的团队已经全面拥抱Spring Boot那就直接用Spring AI因为它把对话模型、提示词模板、结构化输出都做了统一抽象换模型厂商时改动量小很多。但如果你的项目只是一个简单的工具脚本、前端直接Node或者Python调用那就没必要引入一个重量级框架。自己封装一层调用OpenAI兼容协议的客户端三十行代码就搞定了。我分享一个判断标准只有当你需要同时对接多个模型、处理复杂的提示词模板、做函数调用和向量检索时才值得上框架。如果只是问一句答一句用原生SDK反而是最简单可靠的方式。5.4 实战经验上下文管理是应用开发的隐形坑本地API调用起来之后你很快会发现第二个问题模型忘记了之前说的话。这是因为你每次请求都只传了当次的问题没有传历史消息。解决方法是把历史对话拼进messages数组messages [ {role: system, content: 你是助手}, {role: user, content: 我的名字是小王}, {role: assistant, content: 好的小王。}, {role: user, content: 我叫什么}, ]但历史不能无限拼进去因为上下文窗口有限。实际开发中通常的策略是只保留最近的N轮对话或者用摘要模型把旧对话压缩成一段话塞到system消息里。这一步不做应用一上线就会被对话变长之后越聊越笨的问题拖垮。6. 微调不是玄学环境准备、数据整理、训练部署全流程6.1 环境配置GPU、CUDA、PyTorch缺哪个都不行微调和纯推理不一样推理可以用CPU慢慢跑微调则强烈依赖GPU。以LoRA微调7B模型为例你的环境至少要满足GPU显存LoRA微调7B模型16G显存够用24G更从容QLoRA4-bit量化的LoRA可以把需求压到8到12G。驱动和CUDANVIDIA用户建议先装好显卡驱动然后用nvidia-smi确认CUDA版本再按版本装对应PyTorch。Python环境管理强烈建议用conda创建独立环境避免系统Python被搞乱。conda create -n finetune python3.10 -y conda activate finetune # 根据你自己的CUDA版本安装PyTorch pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121这里我最想强调的是务必先确认CUDA可用再动手下一步。很多人环境装了一堆训练脚本一跑发现用的还是CPU速度慢得离谱就是因为在环境创建阶段没验证这行代码import torch print(torch.cuda.is_available()) # 输出True才说明GPU可用6.2 数据准备Alpaca格式与指令数据微调模型第一步是整理数据。目前开源微调工具里最通用的数据格式是Alpaca格式非常简单{ instruction: 判断下面句子的情感倾向。, input: 今天天气不错心情很好。, output: 正向 }有些数据只有instruction和output没有input也完全没问题。关键在于数据量LoRA微调起步500到1000条高质量数据就有效果到5000条以上模型的行为模式会有明显变化。质量重于数量宁要500条人工精修的数据不要5万条抓来的劣质数据。微调模型不像是往池子里加水更像是在用模板印章——它学的是你数据里的共性数据噪声也会被一并学进去。多样性覆盖尽可能多的提问方式避免模型把特定句式当成唯一答案模板。这里要提醒一下训练数据如果包含敏感内容或者第三方版权内容上线前要做合规审查和安全性测试。现在很多大模型应用上线前都会做提示注入攻击的防御测试——有人会恶意构造prompt套取模型的系统指令这在金融、医疗场景尤其重要。微调阶段就要通过数据清洗过滤掉这类风险内容不要等上线了再去补救。6.3 基于Qwen2.5-7B的LoRA微调实操我自己最常用的微调工具是LLaMA-Factory它对Qwen、Llama、DeepSeek等主流开源模型都做了适配而且提供WebUI界面对新手很友好。步骤非常简单# 1. 安装LLaMA-Factory pip install llama-factory # 2. 启动WebUI CUDA_VISIBLE_DEVICES0 llamafactory-cli webui然后在浏览器里打开的界面里模型名称选择Qwen2.5-7B微调方法选择LoRA数据集导入你准备好的Alpaca格式JSON文件学习率设为5e-5训练轮数设为3点开始训练。训练结束后会得到一个LoRA适配器权重文件通常只有几十MB。但我必须强调LoRA权重不能独立运行它必须配合底座模型一起用。部署时要把适配器合并回原模型或者用专门支持LoRA加载的推理服务来做。合并操作在LLaMA-Factory的Export标签页里就有合并后导出的是一个完整的、可直接部署的全量模型权重。6.4 用vLLM部署微调后的模型并评估效果微调完的模型如果要作为服务对外提供我强烈推荐vLLM。它专门为高并发推理优化显存管理效率高生产环境下普遍能达到或超过10倍于普通推理框架的吞吐量。# vLLM离线推理 from vllm import LLM, SamplingParams llm LLM(model/path/to/merged_model, gpu_memory_utilization0.9) params SamplingParams(temperature0.7, max_tokens512) outputs llm.generate([你好], params) print(outputs[0].outputs[0].text)vLLM也提供OpenAI兼容的API服务模式vllm serve /path/to/merged_model --port 8000启动之后同样用OpenAI SDK方式去调用它端口换成8000即可。部署之后要做的最后一步也是很多人忽略的一步评估。我见过太多人微调完模型随便问两个问题就宣布成功结果一上线就翻车。靠谱的做法是准备一份测试集对比微调前后的输出质量重点观察三条是否真的按新格式输出了原本的能力有没有退化比如普通问答是否变差对数据中没有覆盖的领域模型会不会给出错误但自信的回答6.5 微调中的常见坑以及怎么排查我把自己踩过和帮别人排查过的坑列个清单如果你刚好撞上按顺序排查就能省下大把时间现象可能原因解决思路训练时显存爆了批次太大、序列太长减小per_device_train_batch_size或启用QLoRALoss不下降学习率太高或数据格式错误先报错日志确认数据解析成功再把学习率降到1e-5试训练完模型胡言乱语学习率过高模型权重被破坏重训降低学习率并增加warmup微调后通用能力全丢数据太少且太过单一加入通用对话数据混合训练部署后输出乱码Tokenizer与模型权重不匹配迁移时确保带上了tokenizer配置这些坑的本质大多数都能追溯到数据质量和学习率设置上。新手最容易犯的错误是追求训练速度而把学习率调得过高结果模型还没学到新东西先把原来的知识忘了。7. 进阶方向Agent框架、多模态模型与知识抽取7.1 目前主流的Agent框架有哪些怎么选当你已经熟练掌握了API调用和上下文管理下一步自然会想能不能让大模型自己决定怎么完成任务这就是Agent智能体领域。主流的Agent框架我按使用场景分了四类LangChain / LlamaIndex通用开发框架适合在代码里精细控制Agent的每一个步骤。LangChain生态最全学它的时候要接受它的抽象层次较多入门曲线稍陡。AutoGen / MetaGPT多智能体协作类框架适合研究多个模型角色配合完成复杂任务的场景比如一个Agent负责分析需求另一个Agent负责写代码还有一个Agent负责质检。Dify / Coze低代码平台开发者可以通过拖拽配置Agent、知识库、工作流。如果你不想写太多代码又想快速搭一个带RAG、带工具调用的应用这两个平台是效率神器。自研Agent当一个Agent逻辑足够简单比如查一下数据库再根据结果回答问题直接用函数调用功能手写反而更可控。不推荐盲目引入框架。Agent的学习路线建议是先人工模拟Agent把任务拆成固定步骤再让模型做路由决策最后才上框架。很多人一上来就研究Agent框架结果被工具调用、状态记忆、多轮规划这些概念搅得头晕其实背后的核心思想很简单让模型在有限的几个工具之间做选择每个工具做好一件确定性的事。举个具体的例子用大模型做旅游推荐Agent核心逻辑就是先调用天气API查询目的地天气再调用景点知识库检索攻略最后让模型综合生成推荐方案。这里真正决定体验的不是模型有多聪明而是工具调用的容错和重试逻辑是否完善。7.2 多模态大模型从纯文本到看图说话多模态是当前大模型最热闹的进阶方向之一。对入门者来说最容易上手的做法是使用支持图像理解的大模型API或者部署Qwen-VL这类开源多模态模型。多模态模型的价值在于它把过去需要几套系统配合才能完成的工作压缩成了单个模型。比如一个文档里既有表格又有截图以前要做OCR、结构化解析、表格识别三个步骤现在直接把图片丢给多模态模型就能以结构化文字输出内容。我实际测试下来现在大模型对图表的理解能力已经相当可靠做数据分析的同学值得重点关注。如果你想远程体验多模态模型在自己电脑上部署一个VLM体验一下还是走Ollama或者Hugging Face的路径模型重量会比同规模纯文本模型大一截对硬件的要求也更高。7.3 知识抽取实践OneKE与信息结构化最后再聊一个很实用的细分方向知识抽取。在很多企业级场景里大模型不是用来聊天的而是用来把非结构化的文本变成结构化知识的——比如从合同里抽出关键条款、从病历里抽出诊断字段、从公告里抽出公司名和人名。开源领域值得关注的是OneKE这类知识抽取框架专门针对实体识别、关系抽取、事件抽取做了优化。原理上依然是微调或提示词驱动但它把抽取这个任务拆得很细并且提供了标准化的评测数据适合你在项目中直接参考。如果你不想深入学习框架知识抽取的入门姿势完全可以靠提示词搞定请从下面的文本中抽取所有公司名称、人名、金额和时间用JSON格式输出大模型抽取比传统NLP方案更鲁棒对口语化的表述指代省略有更好的容忍度而且不需要针对每个领域重新训练模型。你需要处理的是设计好输出的schema抽样验证准确率再用Pydantic或类似工具把结果强转成结构化数据。7.4 我的学习建议和资源清单最后分享一点个人心得。回头看我自己入门到现在最有用的学习方式不是刷论文而是一条倒逼式路线先跑通Ollama本地部署体验一个真实模型。写一个带SSE流式输出的聊天页面理解流式交互的完整链路。把一个业务文档做成RAG问答理解检索增强的实际价值。找一份小数据集做LoRA微调体验模型行为被数据改变的感觉。再带着问题去读技术博客、源码、论文这时候你会发现自己能看懂了。关于模型下载和资源获取我平时主要用ModelScope中文生态友好和Hugging Face全球生态最全。工具链方面本地部署用Ollama推理服务用vLLM微调用LLaMA-FactoryAgent应用搭建用Dify或LangChain这套组合足够覆盖从入门到生产的绝大部分需求。大模型这门技术的核心壁垒不在于读过多少最新论文而在于你能不能亲手把一个模型跑起来、调通、让它为你的业务产出价值。希望这篇系统性入门资料能帮你跨过从知道到做到的那道坎。等到你自己完成了第一个完整的部署和微调流程再回头看我前面提到的这些概念感受会很不一样。