尧图建网站 尧图建网站 YAOTU WEB BUILD 免费咨询
ARTICLE DETAIL

资讯详情

深耕网站建设与建站编程的一线实战洞察。

零基础学AI大模型:一周掌握Token、API、RAG与微调

零基础学AI大模型:一周掌握Token、API、RAG与微调 零基础学 AI 大模型最大的问题不是找不到资料而是资料太多且多数默认你已经会了 Python、懂深度学习、见过 transformer 结构。实际入门的重点是另一件事先搞清楚大模型工作链路中的几个核心概念再一周内完成“调用 API、本地推理、提示词结构化、RAG 和微调对比”这条主线。下面这份学习路线按一周时间设计每天都能跑通一个可验证的结果。无论你是不是从 8 月 12 号开始这套节奏都可以直接照用。1. 零基础学 AI 大模型先理解模型、参数、Token、上下文1.1 大模型到底是个什么东西大模型在技术上的学名是“大规模语言模型”本质是一个接收文字输入、预测下一个最可能文字的程序。它通过学习海量文本把词语之间的规律压缩成数学参数。所以当你输入“今天天气很”模型会计算“好”“差”“热”等词出现的概率然后选择一个输出。这里要放下一种错觉大模型不是在“查资料”也不是在“搜索答案”而是在做概率生成。它输出的每个字都是基于前面所有字计算出来的。理解这一点后后续很多问题都能解释比如回答可能不准确、同一个问题换种问法结果不同、长对话容易忘掉开头的内容。1.2 四个必须记牢的核心术语术语一句话解释对应到实际使用模型训练好的程序文件包括参数结构和权重你选择不同模型效果不同参数模型学习到的数字规模决定智能程度7B 表示 70 亿参数350B 表示 3500 亿参数Token模型处理文字的最小单位不等同于汉字或单词1 个汉字可能占 1 到 2 个 Token上下文窗口模型一次能看到的文本长度8K 表示约 8000 个 Token超过则系统截断这四项是面试和实际开发中最高频的概念。理解 Token 尤其重要因为 API 计费按 Token 算长文档处理限制也按 Token 算。一个中文字符在多数模型中占用 1 到 2 个 Token英文单词平均约 1.3 个 Token。实际项目里估算成本、设计截断策略都离不开这个粒度。1.3 零基础最容易误解的三个地方第一把大模型当成数据库。提问“鲁迅为什么打周树人”模型可能回答得很自然但这是训练语料里的重复表达不是事实查询。要用大模型做事实类任务必须配合检索增强。第二认为本地部署一定比 API 好。API 的优势是免部署、免维护、模型更大本地部署的优势是数据不出内网、可定制、按需加载。哪个好取决于场景不是越“本地”越高级。第三认为微调能教会模型新知识。微调主要调整的是回答格式、语气、领域风格很难让模型记住某个具体事实。真正补充私有知识的是 RAG也就是把资料检索出来拼进上下文。2. 准备学习环境Python、Conda、依赖库和 API Key2.1 为什么建议用 Conda 而不是直接装 Python学习大模型需要多个依赖常见组合是 Python、PyTorch、Transformers、Jupyter。如果没有环境隔离一次 pip 安装失败或版本冲突就可能把系统 Python 搞坏。Conda 可以创建独立环境每个环境有各自的 Python 版本和包依赖互相不干扰。Windows、macOS、Linux 都可以安装 Miniconda。安装完成后建议创建一个名为 llm 的环境Python 版本选择 3.10 或 3.11这两个版本对 Transformers 和 PyTorch 兼容性最稳定。conda create -n llm python3.10 -y conda activate llm这里要注意所有后续操作都在 llm 环境下进行。终端提示符前面出现(llm)才算激活成功。如果运行 Python 时发现找不到库第一步先检查是否激活了对应环境。2.2 安装两个核心依赖库调用云端模型需要openai库因为大多数大模型平台都提供 OpenAI 兼容接口。本地推理需要transformers和torch前者负责加载和处理模型后者提供底层计算能力。pip install openai pip install transformers torch安装完成后验证一下版本避免后续出现莫名错误。python -c import openai; print(openai.__version__) python -c import transformers; print(transformers.__version__)如果torch安装过慢可以去 PyTorch 官网选择对应当前系统的安装命令。不需要在一开始就追求 GPU学习阶段 CPU 跑小模型完全够用只是生成速度慢一些。2.3 准备一个可调用的 API调用大模型 API 几乎都可以归纳为一个结构base_url指定接口地址api_key标识调用者身份model指定模型名称。不同平台的区别只在这三项上。注册平台后通常会在控制台创建 API Key。这个 Key 是敏感信息不要直接写死在代码里。学习阶段可以存成环境变量export LLM_API_KEYyour-api-key export LLM_BASE_URLhttps://your-platform-endpoint实践里建议把 API Key 写入项目根目录的.env文件再用python-dotenv读取。这样代码仓库不会泄露密钥也方便切换不同平台。2.4 环境准备完成后的检查点每次启动新电脑或新项目都需要做一次环境自检Python 版本是否大于 3.8推荐 3.10 或 3.11。当前终端是否处于llm环境。openai和transformers能否正常导入。是否已设置LLM_API_KEY环境变量。是否能访问模型平台的接口地址。检查环境只需要一分钟但能减少后面大部分“代码没问题但跑不通”的挫败感。3. 一份可以直接照用的一周学习路线3.1 一周目标与验收标准这份路线导向的结果不是“看过一遍概念”而是完成三个可运行的东西一个 API 调用脚本、一个本地推理脚本、一个最简单的 RAG 示例。每天有明确验收标准避免“学了一天只看了收藏夹”。天数学习主题验收标准第 1 天大模型概念与提问方式能解释 Token、上下文、参数第 2 天提示词结构化能写出系统提示词 用户提示词第 3 天API 调用跑通第一个 ChatCompletion 脚本第 4 天参数调优对比不同 temperature 的输出第 5 天本地部署用 Transformers 跑通小模型第 6 天RAG 入门能从文档中抽取片段并生成回答第 7 天项目拼接完成一个问答脚本并整理笔记3.2 前两天把提示词当成“给实习生写需求”前两天的核心不是写代码而是练提示词。零基础最容易犯的错是把问题写得过于零散。提示词的基本结构包含四部分角色、任务、要求、示例。你是一名电商运营助理。 请根据下面这句话判断用户意图。 要求只输出“咨询”“退换货”“投诉”三种分类不要解释。 示例 用户说这个衣服能给我换大一号吗 输出退换货 用户说这个商品什么时候发货 输出咨询这里的关键是“角色 任务 要求 示例”。没有示例模型要猜你的输出格式没有角色模型没有回答风格约束没有要求模型会把一句话解释成一大段。写提示词时可以反复调整多对比几次输出就能建立感觉。3.3 第三天到第四天用代码完成调用和参数实验第三天的目标是最小可行代码。不要一开始就写复杂封装先调用一个最简单的接口打印输出观察结构再逐步加参数。第四天重点比较参数差异。同一个问题temperature 设成 0 时输出偏稳定设成 1.5 时输出偏随机。实践里要记住一个判断规律需要事实回答的temperature 调低需要创意写作的可以适度调高。max_tokens 控制生成长度设太小会看到回答被截断设太大会增加计费。3.4 第五天到第七天从“会用别人的模型”到“跑自己的模型”第五天开始本地部署学习曲线会突然变陡。因为本地部署要处理模型下载、缓存路径、内存占用、设备选择等问题。建议从 0.5B 到 1B 的小模型开始先看效果再思考优化。第六天做 RAG 时不要一开始就搭建完整向量数据库。先用最简单的方式把文档按句子切分用关键词匹配找出相关段落再把段落拼进提示词。跑通后再替换成向量检索。第七天把这些能力拼成一个项目读入一个文档检索相关内容调用大模型生成回答。这个项目完成后你就已经具备了大模型应用开发的骨架。4. 用最少代码跑通第一个大模型 API 调用4.1 示例代码ChatCompletion 最小调用现在多数大模型平台提供 OpenAI 兼容接口因此代码结构非常统一。下面这个脚本是学习阶段的标准起点。import os from openai import OpenAI client OpenAI( api_keyos.environ.get(LLM_API_KEY), base_urlos.environ.get(LLM_BASE_URL), ) response client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: 你是一名耐心的大模型助教。}, {role: user, content: 用三句话解释什么是大模型}, ], temperature0.7, max_tokens200, ) print(response.choices[0].message.content)这段代码解决的是大多数入门者问的第一个问题项目从哪开始。它建立了“构造客户端、拼接消息、调用接口、读取结果”的完整链路。4.2 messages 结构和 model 的含义messages 是请求模型问答的核心结构一般包含三类角色角色含义典型场景system系统提示词规定模型角色“你是客服” “你只输出 JSON”user用户输入具体问题或任务assistant模型之前的回答保存多轮对话历史多轮对话就是在 messages 里不断追加 user 和 assistant 内容。模型本身没有记忆下一次请求如果你不把历史消息传进去它就不知道之前聊过什么。这一条对后面做聊天助手非常重要也是新手最容易漏掉的地方。model 参数直接决定输出质量但不要只看“哪个模型排名最高”。不同模型的上下文窗口、价格、推理速度差异很大。学习阶段选一个你所用平台里文档推荐的小模型即可先跑通链路再横向对比。4.3 关键参数速查参数含义建议值设置过小的影响设置过大的影响temperature随机性0.1 到 0.8回答过于机械回答可能跑题top_p候选词范围0.8 到 1.0表达单一表达混乱max_tokens最大生成长度根据任务定回答被截断浪费计费资源n返回候选数1无可选结果消耗成倍 Token注意temperature 和 top_p 推荐只调一个不要同时大幅调整。很多平台的行为是同时控制随机性如果两个都调高输出会变得无法预测。4.4 调用 API 最常见的两个错误第一个错误是没设置 base_url。默认 SDK 会连接官方地址如果你的模型平台不兼容或网络路径不同会报连接错误。第二个错误是 messages 角色拼错。写成user: 问题这种格式会导致请求报文不合法。正确的结构必须是messages[{role: user, content: 问题}]。跑通接口后建议做一个小实验把同一个问题连续问五次观察结果差异。这个实验能直观理解 temperature 的作用也适合作为学习笔记素材。5. 本地部署用 Transformers 跑一个小模型5.1 为什么学习阶段一定要尝试本地部署本地部署是区分“会用 API”和“理解模型原理”的关键一步。通过本地加载模型你会接触到 tokenizer、输入张量、生成参数、显存占用这些概念这些内容在纯 API 调用中会被完全隐藏起来。本地部署更适合的数据敏感场景是真实的但不要因此神化它。对大多数个人项目来说服务器端调用才是成本更低的选择。本地部署的真正价值是学习模型链路以及为离线或内网场景保留一种可选方案。5.2 最小本地推理代码下面这段代码用 Transformers 加载一个 0.5B 级别的对话模型。示例中的模型名称需要根据当前 Hugging Face 或模型镜像平台可用的模型调整。from transformers import AutoTokenizer, AutoModelForCausalLM model_name Qwen/Qwen2.5-0.5B-Instruct tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name) messages [{role: user, content: 你好请简单介绍一下你自己。}] text tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue ) inputs tokenizer(text, return_tensorspt) output model.generate( **inputs, max_new_tokens128, do_sampleTrue, temperature0.7, ) print(tokenizer.decode(output[0], skip_special_tokensTrue))这段代码的核心是三步tokenizer 把文本变成模型能理解的数字模型生成新的 Token 序列tokenizer 再把它解码回文字。很多入门教程会忽略 tokenizer 的重要性但 tokenize 和 decode 才是本地推理绕不开的环节。5.3 CPU 和 GPU 的区别上面的代码默认在 CPU 上运行。0.5B 模型在 CPU 上也能跑只是生成几十个 Token 就需要十几秒。如果想让模型加载到 GPU推荐加入设备管理import torch device cuda if torch.cuda.is_available() else cpu model AutoModelForCausalLM.from_pretrained(model_name).to(device) inputs tokenizer(text, return_tensorspt).to(device)生产环境还需要关注显存大小。经验参考7B 模型加载到 16 位需要约 14GB 显存4 位量化后可降到约 4GB 到 5GB。个人电脑跑 7B 很吃力所以学习阶段用小模型生产中再根据硬件决定本地部署还是 API。5.4 本地部署验收建议跑通上面的代码后可以继续做三件事换一个不同规模的模型对比生成速度调整 max_new_tokens观察输出变化查看模型下载缓存目录理解 Transformers 如何管理权重文件。这组实践比单纯“跑通就结束”更有价值。注意本地部署最容易遇到的问题不是代码逻辑而是模型下载失败、网络超时、内存不足。建议先把 model_name 换成一个已有缓存或明确可访问的模型再去追求更复杂的流式输出和推理加速。6. 从入门到可落地的三个进阶模块提示词、RAG、微调6.1 提示词工程要做到结构化提示词不是随便写几句话它的核心目标是“降低模型的猜测空间”。好的提示词包含具体输出格式、边界约束、示例输入输出。请根据商品评价文本判断情感倾向。 要求只输出“正面”“负面”“中性”三个词。 评价如下 “物流很快但包装破损比较严重。”这里模型被约束为三选一。你可以在代码里加max_tokens10防止模型输出太多无关内容。提示词工程的价值是见效快、成本低适合作为第一个必须掌握的技能。6.2 RAG 的最小工作流程RAG 的场景是“让模型回答自己数据里的内容”。最小流程可以简化成四步把文档按固定长度切块。对每个块做文本清洗。用户提问时在文档块中检索相关片段。把片段拼到 messages 中作为参考。下面是一个基于关键词匹配的最小示例它不依赖向量数据库足够用来理解 RAG 的核心链路。def search_chunks(query, chunks, top_k3): query_keywords set(query.lower().split()) scored [] for index, chunk in enumerate(chunks): chunk_keywords set(chunk.lower().split()) score len(query_keywords chunk_keywords) scored.append((score, index, chunk)) scored.sort(reverseTrue) return [item[2] for item in scored[:top_k]]实际项目会使用向量检索计算语义相似度但这段代码证明了一个关键结论RAG 的本质是“检索内容 拼接上下文 让模型生成”不是必须一开始就用复杂组件。6.3 微调什么时候才需要微调是用一批结构化的“输入-期望输出”数据继续训练模型让模型适应用特定格式回答。最典型的应用场景是让模型稳定输出 JSON 或模仿某种语气。它不能解决事实错误问题数据要求较高训练成本也更大。对比三种技术手段手段解决什么问题成本学习优先级提示词工程规范格式、风格、任务边界低高RAG补充私有知识和最新知识中高微调规范输出格式、领域表达高低零基础第一阶段应把重心放在提示词和 RAG 上。微调了解概念和流程即可不要一开始就准备数据集、训练几十小时。7. 常见问题排查从报错现象倒推原因7.1 API 调用问题速查表现象常见原因检查方式处理建议提示401或认证失败API Key 错误、未读取环境变量打印os.environ对应值检查环境变量名和 Key 是否正确提示404base_url 或 model 名称错误查看平台文档的接口路径确认 base_url 是否含/v1模型名是否完整输出为空max_tokens 太小或内容被拦截设置max_tokens1000重试调大 max_tokens 或检查内容安全策略请求超时网络问题或模型推理慢配置timeout60重试确认网络连通性换小模型测试中文乱码终端编码问题打印字符看原始值终端切换 UTF-8 编码7.2 本地部署问题速查表现象常见原因检查方式处理建议模型下载失败网络无法访问模型仓库检查下载日志更换模型镜像或使用离线权重显存不足模型太大、输入过长查看报错中的CUDA out of memory换小模型或降低 max length生成速度慢CPU 推理、模型大看生成耗时换小模型、减少 Token 数输出语义差小模型能力有限对比大模型回答降低预期小模型只用于流程验证输入长度超限上下文窗口不足看错误中的长度数字截断输入或增大上下文窗口7.3 通用的排查链路遇到问题按下述顺序排查不要直接改代码先确认输入内容是否合理再看代码路径和模型名是否正确然后检查依赖版本接着确认环境变量和密钥是否生效再检查网络允许范围、端口、数据存储路径最后根据日志定位具体异常。大部分“昨天还能跑今天就不能跑”的问题都出在环境切换、模型改名、接口升级而不是代码本身。8. 一周之后怎么继续进阶8.1 入门完成后的检查清单一周学习完成后可以用以下清单自测能解释 Token、参数、上下文窗口三个术语。能用 System 提示词和用户提示词完成一次带格式要求的回答。能用 API 调用大模型并调整 temperature 和 max_tokens。能用 Transformers 跑通一个小模型。能理解 RAG 的四步流程并能写一个简单的关键词检索。能区分提示词、RAG、微调各自的适用场景。如果以上六项都能做到说明你已经具备了自己阅读项目文档、调试报错、继续深入的能力。8.2 下一步的学习方向一周时间只够建立主干真正深入还需要继续扩展把 RAG 里的关键词检索替换成向量检索理解 Embedding 的意义学习如何评估回答质量建立自己的测试集为项目增加多轮对话、流式输出、历史记录持久化尝试用 4 位量化在有限显存下跑更大的模型接触 Agent 相关概念让大模型学会调用外部工具。每一条路都可以单独学上一两个月。建议盯住其中一个方向做成一个小项目而不是继续横向收集资料。8.3 生产环境需要额外考虑的事情开发环境跑通和上线是两个阶段。生产环境至少要补充密钥管理不把 API Key 暴露在代码中日志与监控记录每次调用的耗时、Token 消耗和错误类型成本控制为每个请求配额设置上限异常处理服务超时时要能自动降级敏感信息过滤避免把用户的隐私内容直接送入外部模型接口。对零基础学习者不要刚开始就追求这些工程能力。先跑通最小闭环再逐步把“能运行”变成“可维护、可监控、成本可控”这才是真正有意义的学习路径。
返回列表