整理这份大语言模型学习笔记的时候我脑子里反复出现一个念头LLM比我们以为的强也比我们以为的蠢。它能在几秒内写出一篇像模像样的行业分析也能在一道小学四则运算上栽跟头它能记住你一周前对话里随口提过的细节也会在面对一个常识问题时脸不红心不跳地编出一个不存在的出处。这份笔记是我自己学习大语言模型大半年的沉淀从模型能力边界、底层机制、幻觉与注意力瓶颈到本地部署的参数选择、模型评估、RAG和智能体容错跨度比较大。适合三类人读刚入门想系统搞清LLM“能干什么、不能干什么”的学习者已经在用API或开源模型做项目、想减少翻车次数的工程师以及准备本地部署或微调模型、对手头技术选型犹豫不决的爱好者。我先说结论与其把LLM当成一个万能的大脑不如把它当成一个极其聪明但容易走神的实习生——你给它明确的流程、趁手的工具和及时的纠错机制它才能稳定产出高质量结果。这篇笔记从头到尾都在回答同一个问题这个“实习生”的边界在哪怎么管好它。1. 盘点LLM能稳定胜任的几类任务1.1 语言理解与生成Transformer带来的能力质变先搞清楚一件事LLM的本质并没有多么神秘。它本质上是一个基于上下文的概率模型做的事情是“预测下一个词”。训练时喂进去海量文本让模型根据前文预测后续内容预测得越准模型内部的参数就越接近某种“语言规律”的隐式表达。这个思路跟老式手机输入法的联想功能是一回事但数据量和模型规模大到一定程度后涌现出了一些输入法做梦都想不到的能力——概括、翻译、改写、情感分析、信息抽取、知识问答、创意写作。我在实际使用中最常用的能力其实是信息重组。比如给出一堆杂乱的公司年报材料让模型提取关键财务指标并生成结构化摘要或者给一段技术文档让它按“背景-方案-风险”拆成三个小节。这类任务LLM完成度非常高因为它的训练数据里包含了海量“从长文本到结构化摘要”的映射。相比之下那种“背百科知识”的问答反而没那么可靠因为这本质上是记忆问题而不是语言建模问题。这一点在第二章会展开讲。值得留意的是“会聊天”只是能力的副产品。真正支撑体验的是模型对词语之间关系、句子逻辑衔接、文体风格的统计建模能力。模型“知道”科技新闻和小说开头的接续方式不同所以能在不同场景下自动切换语气。这也是为什么越大的模型“情商”越高——它见过的语域更多切换更平滑。1.2 扩展的能力版图从文本到视觉的理解跨越现在的大语言模型早就不是只吃文字了。视觉大语言模型VLM的通用做法是给LLM装一个视觉编码器把图片切块并映射成一组向量序列然后像处理文本token一样交给语言模型处理。我试过用这类模型做截图理解、图表数据提取、发票信息录入整体体验是比纯OCR强得多因为它能理解“版面关系”知道标题下面是描述表格左侧是字段名。但这部分能力要理性看待。VLM的“看”和人的“看”是两回事它对图片里的精确位置、数量关系、密集小物体经常出错。我拿一张产品包装图去问模型“标签上有几个警示图标”它两次给出的答案都不一样一次说三个一次说四个。这种不稳定性典型地反映了LLM的统计本质它在“猜一个最像样的答案”而不是真的逐像素数数。把视觉理解当成辅助信息提取手段没问题把它当成精密视觉测量工具就会踩坑。多模态能力还有一个实用方向文档解析。把PDF转成图片后交给VLM做版面理解再抽取结构化字段这套流程在合同审查、表格处理、试卷批改等场景里已经很成熟。它解决的是传统OCR对复杂版面无能为力的问题是目前LLM落地价值最确定的方向之一。1.3 代码生成、结构化输出与工具调用的真实水平代码生成是另一个让我反复惊叹又反复警惕的领域。LLM训练语料中代码文本占比极高注释与代码的天然结构又让模型学到了很强的模式匹配能力。让它写一个“读取CSV文件并统计某列均值”的小函数几乎零失误让它给一个函数补单元测试、解释一段陌生代码的逻辑表现也非常稳定。专门的代码模型比如Qwen-Coder、CodeLlama系列在中等规模项目上甚至可以提供相当可用的补全建议。但它的代码能力有个明确天花板单文件、单模块级别很强跨文件、跨模块的系统设计很容易失控尤其是需要维护全局状态和模块间契约的时候模型会把大量精力花在局部正确上然后在接口处埋下隐患。工程上的应对是让LLM做“编码员”而不是“架构师”架构由人定模型负责实现具体的函数。更关键的是工具调用能力也就是常说的function calling。模型可以根据用户请求输出一段结构化的调用指令例如一个JSON{tool: calculator, expression: 356*897}由外部系统执行真实的计算再把结果返回给模型生成最终回答。这一步把LLM从“会说话的文字模型”变成了“能操作真实世界的接口模型”也是后面第四章智能体能成立的根基。从这个角度看LLM最强的能力不是写代码本身而是把自然语言翻译成程序可以执行的动作序列。2. 局限拆解为什么会一本正经地胡说八道2.1 幻觉问题自信的错误比沉默更致命幻觉是LLM最让工程团队头疼的问题没有之一。幻觉的根源不在于模型“不想说真话”而在于模型根本没有“真假”的概念。训练目标只是最小化下一个词的预测误差模型内部建立的不是数据库而是一个概率分布场。遇到训练数据里没有的知识点时它不会说“我不知道”而是根据语言惯性推演出一个听起来很合理的答案。举几个我真实踩过的例子让模型回答某篇特定论文的作者它写了一篇完全不存在的论文标题还配了栩栩如生的作者名让它介绍某条行业监管规定的最新修订日期它给出了一个看似精确、实际错误的时间。最坑的是如果追问一句“你确定吗”它可能会换一套说法重新编两个答案相互矛盾但每个都语气笃定。处理幻觉没有银弹。实践中比较有效的是“约束验证”组合要求模型只基于提供的上下文作答不补充训练记忆中可能过时的信息任何关键事实通过外部检索交叉验证涉及法律法规和金融数字时干脆把回答做成人类审核的辅助草案。记住一个心法在关键场景里LLM输出必须被当成“需要核验的初稿”而不是“可直接使用的结论”。2.2 上下文窗口记性好但窗口外的世界一片漆黑LLM的注意力机制本质上是O(n²)的运算输入越长计算量和显存消耗增长越快。这决定了每个模型都有上下文窗口上限例如4K、32K、128K。窗口之外的内容模型完全无感知每次对话都必须把相关信息塞进窗口里模型才能“想起来”。但窗口长不等于真能利用好。有个很著名的问题叫“lost in the middle”研究者把关键信息放在长文档的不同位置结果发现放在文档开头和结尾时模型回答准确率最高放在中间位置时准确率显著下降。背后的原因是注意力资源向开头和结尾倾斜中间内容被“敷衍”了。我做过一个测试把一个500页技术手册塞进128K上下文的模型问它第230页描述的参数默认值它开始胡编。这不是窗口不够长而是注意力根本没有覆盖到那个位置。工程上的应对方案有三板斧第一重要信息放开头关键词在Prompt前三段就点明第二不要一股脑塞全文先让模型做分章摘要再基于摘要问答第三用检索把最相关的几段内容抽出来喂给模型而不是让它自己在大海里捞针。这也是RAG在第四章会详细展开的原因——光有长窗口远远不够关键是让模型在哪里集中注意力。2.3 算数与精确计算的天然短板让LLM做精确计算是很多新手的第一个坑也是最容易劝退的场景。语言模型从机制上就和数学运算不兼容数学是精确的符号操作而LLM是概率化的文字接龙。一位数以内的加法靠训练记忆就能对一旦出现三位数以上的乘法、带小数的连乘、多位数字的大小比较错误率会急剧上升。我实测过让一个7B模型算“365×4923”它给出了“1796895”这个看似合理的答案实际差了一个数量级。这类问题在工程上非常好绕过不要用模型算数把数值计算交给代码解释器或计算器。很多智能体框架内置了Python执行环境正是出于这个原因——LLM负责写计算代码、解释计算结果真正的浮点运算由解释器完成准确率直接从“碰运气”变成100%。这给我们的启发是不要试图通过提示词把模型“变聪明”而是把不擅长的事外包给确定性工具让模型做人擅长的事。类似需要外包的还包括日期计算、时间差推算、单位换算等。凡是“有标准答案”的精确推理都建议走工具调用路线。凡是“没有唯一答案”的开放式推理LLM才有发挥空间。把这两类问题的边界刻在脑子里项目的翻车率会直线下降。2.4 训练数据决定边界的另一面知识截止、元评论残留与数据污染训练数据不仅决定了模型知道多少还决定了模型在输出风格上的“惯性”。一个很典型的现象就是我在项目里遇到的“元评论残留”因为训练语料里大量存在“作为AI语言模型我无法回答……”这样的句子模型学的不只是规则还学到了这句话的语言惯性。于是用户问一个正常问题时模型可能会先来一句“作为AI我……”然后才进入正题。更尴尬的是有些系统提示少、纯靠模型自由发挥的场景里它会在回答末尾自动补一句“我是一个AI助手不是人类”之类的废话。元评论残留会影响工程系统的稳定性。比如在做JSON结构化输出时模型偶尔会在JSON前面加一句“好的这是你要的结果”直接导致解析器报错。这个问题用提示词约束只能缓解更可靠的做法是在解析层做容错比如剥离包裹文本、提取第一个{到最后一个}之间的内容或者给模型出示一个先例示范告诉它“直接输出JSON不要其他内容”。训练数据的另一个副作用是知识截止和过时问题。模型的参数本质上是训练完成那一刻的快照之后发生的新闻、新版本软件接口、新出台的规则它一概不知道。有些在线版本会接入实时检索来缓解但很多本地部署的离线模型是完全没有这种能力的。设计产品时要把“知识时效”作为显式约束面向用户的介绍性内容可以用模型生成但涉及最新信息的页面必须走数据更新管线或标注“生成时间为训练截止日”。2.5 风格不稳定同一问题的输出可以千差万别很多用户对LLM还有一个误解以为同一个问题每次会得到同一份答案。实际上LLM的生成过程带有随机性解码时会在概率相近的token之间掷骰子。同一Prompt跑五次可能得到五份结构不同、详略不同的回答。好在工程上可以通过参数控制这种随机性这就是第三章要讲的temperature、top_p这些参数。对严格需要一致性的场景比如客服话术、报表文案建议把随机性调到极低甚至固定随机种子对需要发散灵感的场景比如头脑风暴、创意命名则要保留随机性否则答案会显得机械。3. 工程视角模型选型、本地部署与参数配置的权衡3.1 从API到本地部署GGUF格式与量化取舍先回答一个搜索关键词里带出来的问题大语言模型本地部署是不是用YAML提供配置参数。答案是肯定的而且YAML几乎成了开源LLM部署框架的事实标准像llama.cpp、LM Studio、Ollama这类工具都支持用YAML管理模型路径、上下文长度、采样参数和硬件配置。这个后面细说。先聊本地部署本身。很多人选择本地跑模型理由很实际数据隐私不外传、离线可用、长期使用没有按token计费的压力。本地部署的核心痛点是显存不够而GGUF格式就是为解决这个痛点而生的一套方案。GGUF把模型权重按量化级别压缩打包比如q2_k、q4_k_m、q5_k_m、q8_0数字越小压缩率越高精度损失越大。q2_k已经属于“重量级破坏”q4_k_m是社区公认的性价比之王一般7B模型量化为q4_k_m后大约4GB一张消费级显卡或16GB内存的笔记本就能跑起来。在安卓手机上跑量化模型这两年也成了热门玩法基于llama.cpp的App比如PocketPal、LM Studio的移动版可以在老手机上运行GGUF格式的小模型。我甚至在一台安卓8的旧设备上跑过3B模型速度在可接受范围内适合做摘要、分类、关键词提取这类“体力活”。但必须降低预期7B以下模型的语言智商和GPT-4这一档差距非常明显别指望小模型在复杂推理上给你惊喜。本地部署的真正价值不是省钱而是数据可控和离线可用。3.2 YAML参数配置文件每一项都影响输出结果开源框架用YAML统一管理参数给了我们一个精确控制模型行为的机会。下面这份配置是我平时跑Qwen2.5-7B的常用模板逐个参数说清楚含义和取值逻辑。model: name: qwen2.5-7b-instruct-q4_k_m.gguf context_length: 8192 max_tokens: 2048 sampling: temperature: 0.7 top_p: 0.9 top_k: 40 repeat_penalty: 1.1temperature是最容易理解的参数控制生成随机性0是贪心解码每次都选概率最高的词输出稳定但经常呆板越接近1越有创造性但更容易跑题高于1.2会开始语无伦次。写代码建议0.1到0.3做创意写作可以开到0.8到1.0。top_p控制候选词的累积概率范围比如0.9表示只从累积概率达到90%的那一批token里选相当于把离谱的低概率词排除了。top_k是另一个限制候选数的参数和top_p联用会让输出更稳。repeat_penalty是压制复读的如果发现模型开始“车轱辘话来回说”调高它是一个直接解法。context_length和max_tokens一看名字就懂但要注意它们直接影响显存占用和推理延迟不是越大越好。我个人的习惯是能跑8K就不跑16K因为实测下来长上下文对速度和显存的拖累明显而日常绝大多数Prompt根本用不到那么长。还有一个容易被忽略的技巧YAML里的system提示词不要压在底部尽量放在对话开头这跟2.2节说的“注意力集中在开头”是同一个原理。3.3 别只信榜单用评估框架验证模型边界选择模型的时候各家的宣传榜单都很好看但实际跑起来往往不一样。最靠谱的做法是拿开源评估框架这类工具社区习惯叫harness自己跑一遍标准benchmark。我用过lm-evaluation-harness跑过7B、13B、70B几个档位的模型四个维度最能反映日常真实水平MMLU多领域知识、GSM8K数学推理、HumanEval代码生成、HellaSwag常识推断。一个模型在MMLU上分数很高不等于数学能力好在HellaSwag上很强也不代表能输出合格的结构化JSON。我见过一个号称“全面碾压”的13B模型GSM8K准确率连30%都不到数学完全不可用。评估的价值就是量化这种边界告诉你哪个场景可以放心交给模型哪个场景必须加工具链兜底。评估跑完还要做业务验收测试这比公开benchmark更关键。我会把项目里最容易翻车的20条Prompt整理成一套回归集每次换模型、升级版本、调整量化级别之后都跑一遍。这套回归集才是真正属于自己业务的“能力边界地图”而不是依赖那些宣传材料里精心挑选的示例。4. 绕开局限的工程手段从RAG到智能体容错4.1 RAG把外挂知识变成模型的“临时记忆”RAG检索增强生成是目前绕开知识截止和幻觉问题最成熟的方案。思路很朴素不要指望模型记住一切而是在接到问题后先去外部知识库检索相关文档片段拼进Prompt的上下文里再让模型基于这些片段作答。相当于每次开卷考试试卷旁边放一本可以随时翻阅的参考资料。工程上RAG的链路是文档切块→向量化embedding→存入向量数据库→查询时把用户问题向量化→检索相似片段→拼进Prompt。我踩过几个坑很值得分享。首先是切块大小整段复制一整章会让向量表达不聚焦太小又会割裂上下文实践中512到1024字符的块比较稳妥中文建议偏小一些因为中文信息密度高。其次是检索返回的top-k我常用5到8条片段太少覆盖率不够太多会让模型被无关信息干扰。第三是嵌入模型选择中文场景不要直接用英文optimized的embedding模型效果会明显打折。RAG解决了一部分幻觉但没有根治。一个高频翻车点是检索结果本身含噪声时模型可能把不相关的片段也当作证据写进回答。所以我在Prompt里会加一句强约束“只基于提供的上下文回答如果上下文里没有对应信息就直接说不知道。”这句话虽然朴素但实测下来能显著减少模型“自己加戏”的概率。4.2 数据标注与微调修改能力边界的现实代价熱搜词里有人问“LLM怎么数据标注”这确实是一个很实际的问题。当你发现通用模型的行为跟业务需求有系统性偏差时微调是一条路径。但微调的目标要有清晰预期它适合改风格、改格式、学特定领域的术语和流程但它不能凭空增加模型的智力。一个GSM8K只有30%的小模型靠微调可能会涨到50%但不可能闭眼到90%。能把一个7B模型的能力真正提升的永远是更大的基座模型而不是微调本身。数据标注的质量比数量重要得多。我之前做客服场景微调时一开始收集了两万条对话标注标准不统一模型学出来的语气时好时坏。后来把标注规范改成“每个样本都必须包含完整的意图标签、情感标签、标准回答模板”样本缩减到三千条效果反而大幅提升。好的标注规范应该让标注员面对同一条输入时能给出几乎一致的标准答案这个“一致性”比答案内容本身更关键。技术路线上LoRA/QLoRA这类参数高效微调能在消费级显卡上跑小模型成本不高。我建议固定套路先拿几百条样本做一个实验性的LoRA跑通流程、看Tendency是否符合预期再投入资源完善数据。微调完成后必须跑一遍3.3节说的回归集特别要警惕“微调后模型在其他任务上回退”的灾难性遗忘现象。4.3 LLM智能体与自主容错把实习生管起来的工程实践LLM智能体Agent是这两年最热的方向核心思路是把LLM从“一问一答的聊天框”变成“能在循环中自主决策的行动者”给它一批工具搜索引擎、计算器、代码解释器、内部API让它在完成任务的过程中自己决定调哪个工具、怎么调、怎么解析结果。但Agent化的风险也随之放大——幻觉产生的一个虚假动作可能让整条流程在错误路径上狂奔。这就要靠容错控制。我在实际项目里总结了一套Agent容错的最低配置。第一是状态机约束不要让Agent自由发挥动作序列而是把它限制在预设的状态之间跳转比如“分析输入→选择工具→执行→校验→输出”每一步未通过校验就不能进入下一步。第二是重试与回退工具调用超时、返回异常、输出结构不对时自动降级重试比如第一次调搜索失败就换关键词再搜一次累计三次失败才转人工。第三是结构化校验对Agent的每一次输出做JSON Schema校验不满足格式直接“打回重做”绝不把未经校验的文本传给下游。第四是权限最小化Agent能调的工具权限只开放任务必需的最小集合避免它误触发高风险操作。这四点里最容易被人忽略的是“校验”这步。我见过很多团队花大力气调Prompt却让Agent的裸输出直接进数据库结果一个回车符都会导致入库失败。正确做法是让模型输出和业务逻辑之间隔一层“橡皮擦”——剥离多余文本、提取JSON、校验字段、类型转换全部由代码完成模型只负责生成内容。把Agent当成“实习生”来管理给它明确流程、预期输出和检查节点你才能真正享受它的效率红利。5. 避坑速查表与个人知识管理实践5.1 高频错误用法与处理速查表给完整份笔记我把平时最容易踩的坑整理成了一张速查表方便大家收藏后对照排查。常见错误用法现象推荐对策让LLM做精确计算乘法结果偶尔正确偶尔差数量级交给代码解释器或计算器工具让LLM回答训练截止后的事一本正经给出过时或编造信息接RAG或联网检索限定“只基于上下文回答”要求模型给出可信引用引用拼接得极其逼真但出处不存在不要依赖生成引用接检索验证来源长文档居中段信息关键信息在文档中间时准确率大跌核心信息放Prompt开头或用摘要分块所有任务用同一套采样参数代码生成随机满天飞创意写作呆板按任务调temperature和top_p参考3.2节不校验模型输出直接入库多一个回车符导致解析失败解析层剥离包裹文本做Schema校验后放行把Agent动作序列完全交给模型一个幻觉动作带偏全局状态机约束工具白名单失败重试除了表格里的坑还要再提一句幻觉高危场景的判断经验凡是问题涉及具体数字、日期、人名、出处、法条编号、版本号幻觉概率都会显著上升。反过来开放式观点总结、语言润色、结构整理幻觉风险就低得多。判断清楚手上任务属于哪类再决定要不要上验证手段比盲目加一堆“请确保准确”的提示词有效得多。5.2 用Obsidian整理LLM知识库从PARA到LLM Wiki的实践学习笔记写到最后顺便聊聊我的第二大脑重构经历。前几个月我把Obsidian笔记库的整理方式从传统的PARA结构Projects项目、Areas领域、Resources资源、Archives归档改造成了更适合LLM时代的“LLM Wiki”结构。核心出发点很简单以前笔记是给自己线性翻阅的现在笔记还要能成为RAG系统的语料库。改造后的规则是“一主题一笔记”每篇笔记围绕一个核心概念比如“幻觉”“RAG”“top_p参数”笔记之间用双链建立关系。同时给每篇笔记加上统一的Front Matter标签和别名方便检索。然后是建MOC内容地图索引把零散笔记汇总成主题入口比如“LLM能力边界总览”“本地部署清单”“Agent工程模式”这让笔记库有了门户和导航。最后一步是把这些Markdown文件定期导出为一个纯文本目录用来做RAG的本地语料让笔记既能给人看也能给机器检索。这个实践最直接的收益是当我在项目里需要快速确认“某个模型的量化级别是否够用”“容错设计有没有漏掉校验环节”时我不用重新翻几十篇零散笔记用Obsidian的图谱视觉化能力扫一眼MOC就能定位。这种知识组织的思路也值得推荐给所有做LLM学习的人——因为这个领域信息更新太快没有一套结构化的个人知识库你攒的经验会很容易散落、过时、甚至被遗忘。如果你现在正打算给自己规划一条LLM学习路线我最后的建议很朴素第一步先画出“能力与局限”的边界地图别一头扎进调参和跑分第二步老老实实拿业务场景里的20条真实Prompt做回归测试让数据告诉你该在哪个环节加工具链兜底第三步无论用什么花哨的框架始终把输出校验和容错机制放在系统设计的第一优先级。大语言模型这个工具真正变得好用是从你不再盲信它的输出那一刻开始的。