我会直接从博文内容开始不做任何额外说明或元信息。下面是一篇围绕“LLM 学习笔记”展开的完整、充实、可直接发布的Markdown博文。1. 为什么要把LLM学习单独拎出来做笔记我在整理技术笔记时发现一个很普遍的问题LLM相关的文章、教程、帖子多到看不完但看完之后真正留下来的东西少得可怜。今天看到一个LangChain的调用示例明天刷到一个RAG的架构图后天又收藏一篇微调的实战帖结果真要自己动手搭一个应用时脑袋里全是碎片连模型选型都犹豫半天。所以我想把这段时间学习大语言模型LLM的过程整理成一套自己的笔记这篇就算第一版系统性的沉淀。这套笔记适合三类人刚开始接触LLM、对“模型怎么选”“提示词怎么写”“RAG和微调到底该先学哪个”感到混乱的入门者已经跑通过几个Demo、但总感觉落地时哪里不对劲的初级开发者以及想给团队做LLM技术分享、需要一条清晰讲解主线的技术布道者。我不会堆一堆概念名词而是把“学什么、为什么学、怎么上手、最容易踩什么坑”按一条实操路径串起来。按理说LLM学习最不缺的就是资料缺的是“主线”。这也是我反复强调要自己记笔记的原因。别人的博客是按照别人的知识结构组织的只有把内容打散、重新揉进自己脑子里的框架你才真正吸收了。这篇笔记的主线就是先建立认知地图再逐步深入核心概念然后连跑通工程链路最后回到智能体和可靠性的工程实践。2. 学习路径设计先搭认知骨架再填细节血肉2.1 我走过的弯路上来就啃源码和论文最初我犯了一个典型的错误刚知道Transformer是大模型的底座就直接打开《Attention Is All You Need》和PyTorch源码想从注意力机制的矩阵乘法开始一步步手推大模型原理。结果一周下来公式看了不少但GPT-4和开源模型之间怎么选、Prompt里temperature应该设多少、RAG的向量检索为什么会检索得不准这些问题一个也没解决。后来我才想明白LLM学习应该分三层顶层是“应用认知层”理解模型的能力边界、对话模式、上下文窗口、定价和延迟这些工程决策要素中层是“技术原理层”理解Token、注意力机制、微调、RAG、Function Calling这些技术的“为什么”和“适用条件”底层才是“算法实现层”梯度更新、分布式训练、量化推理、内核优化这一层只有当你需要训练模型或做极致性能优化时才必须深入。我建议绝大部分以应用落地为目标的人把70%的时间花在顶层和中层。底层不是不重要而是它的优先级应该由你当前问题和项目阶段决定。我见过有人花两周调FlashAttention的kernel结果自己的RAG系统连召回准确率都还没验证过这就是认知地图出了问题。2.2 学习闭环概念、实验、复盘三件套光看书和文档是不够的LLM的每个核心概念都应该配一个最小实验来验证。我在笔记里给自己立了一条规矩每个概念至少做一个“十行代码以内”的实验否则不算掌握。比如学“Temperature参数”就反复用不同的temperature值跑同一句Prompt记录输出的重复性、发散度和错误率学“上下文窗口”就故意把Prompt拉长到接近窗口极限观察模型是变笨了还是直接报错学“向量检索”就手写一个几十行的小工具从切块、向量化、存储到相似度检索全流程跑一遍。每次实验都记成“预期—实际—差异分析”的格式。比如你预期temperature从0调到1.2时输出会“更随机”但实际可能发现某些模型在1.2时开始出现完全离题的答案这个差异就是很有价值的经验沉淀。这套闭环最大的好处是三个月后你翻看笔记时能清楚看到自己当时的判断是否准确而不是记了一堆抽象概念。2.3 工具链地图越早梳理路径越清晰LLM的生态更新节奏非常快但工具链的“角色”是固定的。我把它们归纳为五类这样看到任何新项目都知道该放进哪个抽屉角色典型工具/服务核心解决的问题模型服务OpenAI、Anthropic、Google Gemini、开源模型本地部署提供推理能力开发框架LangChain、LlamaIndex、Semantic Kernel封装Prompt拼接、工具调用、记忆管理等流程向量数据库Milvus、Chroma、Qdrant、pgvector存向量、做相似度检索可观测性LangSmith、Langfuse、OpenTelemetry追踪调用链、评估质量部署与优化vLLM、Ollama、TensorRT-LLM、LM Studio提高吞吐、降低延迟这张表不需要背但需要经常拿出来对照。我每次看到一个RAG项目或者Agent项目第一件事就是问自己它在这张表的哪一格那种“什么东西都有但不知道放哪”的模糊感恰恰是学习LLM最大的杀手。3. 核心概念逐个拆解原理、例子和直观理解3.1 Token与上下文窗口大模型的地基单位Token是LLM处理文本的最小单位它可以是一个完整的单词、一个单词的一部分、甚至一个标点符号。用生活类比来说Token就像做寿司时切好的食材块模型一看“三文鱼”可能是一个Token也可能被切成“三文”和“鱼”两个Token这取决于模型使用的分词器预先怎么切。为什么Token理解这么重要因为它直接决定了实际业务的成本和效果。举例来说一个英文单词可能等于一个Token但中文里很多情况下一个汉字不止对应一个Token甚至一个常用词会被拆成两三个Token。这意味着用中文做LLM应用的Token消耗往往比英文更高。我实测过同一句业务提示词中英混合场景下Token开销比纯英文高30%到80%这会直接影响API账单和响应延迟。上下文窗口则决定了模型“一次能看见多少内容”。这里有个新手常有的误区认为窗口越大越好。其实窗口大不等于效果一定好因为模型对长上下文的注意力分布并不均匀很多开源模型在上下文超过一定长度后中间部分的信息利用率会明显下降——“Lost in the Middle”就是这个问题的经典描述。所以在搭建知识库问答系统时我宁可严格控制每个Prompt里只放最相关的2到4个文本块也不要把几万字的内容一股脑塞进去。3.2 温度、Top-p和最大长度一组必须亲手调过的参数在Prompt里配置参数时我最常被人问的两个问题就是温度到底调多少合适是不是越高越有创造性Top-p又是什么和temperature是什么关系这里我给一个直观理解temperature控制的是“概率分布的锐度”。设成0时模型每次几乎只选概率最高的词回答稳定、可复现性极高调到1.0甚至更高时低概率的词也有机会被选中回答更发散、更有“惊喜”。我常用的经验是做代码生成、数据提取、结构化输出temperature0.3甚至直接设0做头脑风暴、创意文案、故事生成temperature可以设0.8以上批量跑评测时温度固定为0否则同一测试集跑两次结果差异会干扰判断。Top-p可以理解为“累积概率截断”模型只在累计概率达到p的那些词里做选择。它的作用不是替代temperature而是和temperature叠加使用。我的习惯做法是先把temperature设低再用Top-p限制候选词范围如果顶层输出总不稳定再逐步提升temperature而不是一上来就调到1.5。最大输出长度max_tokens这个参数最容易被忽略。我曾经在做一个调用外部工具的项目时模型老是输出不完整JSON排查了半天发现就是max_tokens设得太小模型生成到一半就被截断了。至少给模型的输出预留比期望文本多20%的空间这是最低标准。3.3 幻觉问题大模型犯错的三种类型“幻觉”是LLM落地时绕不开的话题它不是简单的“胡说八道”四个字能概括的。我个人的归类方法是把幻觉分为三类事实性幻觉模型精准但错误地陈述一个事实比如把某产品的发布日期说错一个年份忠实性幻觉模型没有遵循用户提供的内容自己编造了额外信息比如你给它一份五条条款的文档它回答时自己脑补了第六条逻辑性幻觉模型给出的推断在上下文内无法成立比如“前三项都是A类所以第四项也是A类”但第四项实际是B类。这三类幻觉的应对策略完全不同。事实性幻觉要靠RAG和知识库约束忠实性幻觉要靠提示词里强调“只能基于给定内容回答”并且配合输出校验逻辑性幻觉则最棘手它需要模型具备更强的推理能力通常只能靠换更强模型或者让模型拆解步骤逐步“想清楚”。学LLM时如果只把幻觉当成一个名词记住那真正排查问题时一定会懵。3.4 Prompt不是咒语而是“对话协议”我踩过很长一段时间的坑以为Prompt就是魔法咒语写得越花哨效果越好。实际并非如此。Prompt是跟模型约定一种协作方式本质上是“对话协议”。你是任务发布方模型是协作者你需要说清楚背景信息、角色、目标、输出格式、边界和约束条件。我最常用的一套Prompt写作框架叫“R-T-F-C”四个字母依次代表Role角色、Task任务、Format格式、Constraint约束。参考模板是你是[角色]请针对[任务目标]给出结果。要求满足[具体输出格式]同时注意[约束条件例如只基于给定材料回答、不要编造、不确定时明确说不知道]。提示词工程的另一大原则是“示例优于说明”。与其告诉模型“请严格输出JSON”不如给它一个in/out示例这比一百句抽象规则都管用。自从我学会在每个关键Prompt里带1到2个few-shot示例后模型输出的稳定性和格式合法率有了质的提升。4. RAG、微调和评估工程落地的三块基石4.1 RAG的标准流程和常见性能瓶颈RAG检索增强生成是目前让LLM“说实话、说对事实”最流行的脚手架。它的核心思路是用外部知识库先检索出与问题最相关的文本片段再把这些片段放进Prompt里让模型基于它们作答而不是让模型凭空回忆训练数据。这个思路用一句话概括就是不要让模型上考场之前背书而是让它考试时自带资料。我的RAG实现流程一般分四步切块、向量化、入库、检索生成。切块时要注意块的大小和重叠度块太小语义不完整块太大检索不准还浪费Token向量化要选择与模型匹配的嵌入模型入库要选择合适的向量数据库检索生成时最重要的一个技巧是不要只做相似度检索最好做一下重排Reranking把第一次检索回来的候选片段用重排序模型精调一下顺序。我实测过加一轮重排通常能让最终回答质量提升10%到15%这个性价比非常高。但RAG最常见的坑也有几个特别提醒新手注意切块前必须先清洗文档格式比如PDF里的两栏排版、表格转文本、扫描件的OCR错字这些都直接影响向量质量不要把整个文档切成巨大块塞进向量库更好的是先按章节结构切再根据语义长度做二次拆分检索命中率不达标时先检查“嵌入质量”和“查询改写”而不是一味调向量库参数。4.2 微调要知道什么时候不该微调微调Fine-tuning是很多人一听就兴奋的方向总觉得“我要把模型变得更强”于是拿着几千条数据就微调。实际上微调的适用场景比大多数人想象中窄得多。我的判断标准很简单需要模型学习新知识不要微调应该用RAG。微调不适合更新模型记忆里的事实信息你今天微调进去明天新事实出来又要重新调成本极高需要模型改变格式、语气、交互风格适合微调比如把模型调成客服风格、让输出遵循固定表格格式需要模型学会调用工具的特定方式和规则适合微调特别是在函数调用场景里微调能显著提高参数提取的准确率需要模型推理能力大幅提升微调做不到根本性提升那是基础模型能力决定的不如换一个更大的模型。如果确认要微调我会推荐从参数高效微调PEFT/LoRA入手因为它的显存需求低、实验周期短。微调前要做的最重要准备工作是数据清洗重复样本、错别字、逻辑不一致的标签对这些都会让模型学坏。模型微调后还容易出现“灾难性遗忘”所以最好把原始通用数据也混入一部分来微调。4.3 LLM as Judge选型与评估陷阱评估模型输出质量是LLM应用工程里最容易被低估的环节。你可以人工标注一部分数据但线上每次都要人工评估是不现实的于是就有了“LLM as Judge”的做法用一个更聪明的模型当裁判来给目标模型的输出打分或做对比排序。使用LLM as Judge时有几个大坑实测中我全部踩过裁判模型对顺序敏感。同样的两个答案A在前和B在前评分结果可能不同。解决方法是多次交换顺序取平均裁判模型会被“更长更华丽的回答”带偏。输出明显更长时裁判往往给更高分这不代表质量更高。评估的标准里必须明确添加“忽略长度差异”裁判模型自身也受幻觉影响。如果判断标准含糊它会自己脑补一些需求来打分所以评价标准一定要尽量客观化、条目化。我现在的评估体系里其实不只用LLM作为唯一裁判还会混入一些确定性指标例如检索覆盖度、JSON格式合法率、回答是否包含确切来源引用。只有“确定性指标 LLM Judge 少量人工抽检”三者组合效果才稳定可靠。5. 从零搭建一个本地知识库问答应用的完整过程5.1 场景假设与整体方案设计为了让笔记不“飘”我决定用一个具体的项目来示范整条链路搭建一个面向私有文档的本地知识库问答助手用户提问后系统检索相关文档并生成带来源引用的答案。技术选型情况是方案偏向开源链路主要考虑成本可控和数据不出内网。嵌入模型使用bge-m3这类中文效果有保障的开源模型向量数据库使用轻量级的ChromaLLM推理通过Ollama加载Qwen2.5或Llama3系列模型。整体架构不算复杂核心意图是跑通一个最小可行版本后续再考虑更重型优化。为什么选Ollama而不是直接调用商业API两个原因一是数据敏感场景下私有化部署更有优势二是Ollama在macOS和Linux上对本地模型管理非常友好一条命令就能拉起一个GGUF格式的模型。GGUF是llama.cpp生态的量化模型格式体积小、推理快很适合个人在本地摸索学习。我这次选的是7B到8B量级的量化模型一台16GB显存或内存的消费级机器就能流畅跑起来。5.2 关键步骤切块、向量化、检索与生成整个流程的骨架代码并不复杂拆开看主要四步。第一步是文本切块我使用的策略是先将文档按Markdown标题结构分割再把单个块控制在512到1024个Token之间块之间保留64个Token的重叠这样能防止一句话被硬生生切成两半。切块的代码可以参考recursive character splitter来实现。第二步是向量化入库。把每一块文本通过嵌入模型转成向量连同原始文本和元数据来源、页码、章节名一起存到向量数据库。这里很容易犯的一个错误是忘记保存元数据。如果你不记录这一块来自哪个文档、哪一页后面回答里想加“来源引用”就非常困难。我第一版就吃过这个亏只好清空数据重新入库。第三步是检索。给定一个用户问题先把问题和文档切片都转成向量然后用余弦相似度找到最相近的Top-K块。K值的选取要平衡信息量和噪音我通常用K5到8。但检索方向的细节也值得说用户在自然语言里的问法和文档里的书面表述往往差异很大比如用户问“这个产品怎么保修”文档里可能写的是“售后服务条款”这种情况下仅凭余弦相似度可能召回不到所以往往需要多路由检索或者检索前做查询改写把问题改写成更贴近文档语体的表达。第四步是生成。把检索回来的文本块按顺序放进Prompt明确约束模型“只基于给定材料回答如果材料不足请直接说不知道引用来源时请标注块编号。”这样输出的答案既可靠又方便追溯。5.3 参数计算参考显存、并发与延迟本地部署时显存估算是个实操点。以7B参数模型为例如果做4比特量化模型的权重体积大概是4到5GB加上KV Cache和运行时开销16GB内存的机器能顺畅跑8GB内存就有点紧张。并发场景要另算因为每个并发推理都会占用额外的显存做KV Cache。我第一版想同时处理10路请求结果本地机器直接OOM后来才知道要做并发限制。如果要用商业API成本可以做一个简单估算公式单次请求成本约等于输入Token数乘以输入单价加上输出Token数乘以输出单价。实际调模型时可以把一条Prompt的实际Token算出来再估算而不是凭感觉觉得“太少了吧”。长期跑的话建议用日志把每个请求的Token用量记录下来不然月底账单出来会吓一跳。5.4 实战环节我的一次Debug全过程我说一个实操过程中的真实案例。知识库问答系统上线后有个用户提问“2024年Q3的销售数据是多少”系统检索回来的文本块实际上是“2023年Q3销售数据汇总”但回答里把年份写成了2024。原因分析是这样的切块时年份信息被分割得比较靠后检索时只看到了“Q3销售数据”语义相似度很高年份差异就没被模型注意到。解决办法其实很简单在每个文本块的开头强制以“【时间范围2023年Q3】【文档来源销售周报】”这种元数据前缀开头。然后把这个规则写进切块和入库的预处理流程。这个改动只花了一个小时但准确率提升非常明显。自那以后我所有的元数据信息比如日期、所属部门、版本号都会明确放进文本块顶部而不只是存在向量库的元数据字段里。6. 智能体与工具调用如何让模型真正动起来6.1 Function Calling的底层逻辑LLM的能力边界面着广大但有一类专项能力越来越重要让模型调用外部工具。当你跟模型说“帮我查一下今天天气并提醒我出门带伞”模型本身不会联网但它可以输出一个结构化的调用指令比如{function: get_weather, args: {city: 北京}}然后由外部的代码去真正执行这个请求。这种机制就叫Function Calling或者叫Tool Use。学Function Calling要理解一个关键点模型不是直接执行函数而是生成一个调用指令。你需要在代码里解析这段指令、校验参数、执行函数、把结果返回给模型。整个链路实际上是一个多轮对话模型出指令程序干活拿到结果后再给模型模型把结果组织成最终回答。这里最常见的Bug就是函数返回结果超过了上下文窗口限制或者返回结果是HTML表格但模型没理解它其实是结构化数据。6.2 自主容错与控制Agent工程里的可靠性问题用LLM做Agent是当前最热的方向但也是最容易翻车的方向。一个Agent往往需要计划Planning、工具调用、记忆和反思四大模块而每一步都可能出错。我自己的实践体会是Agent的可靠性工程不是“让模型更聪明”而是“让系统更容错”。常用的容错策略包括对Function Calling做严格参数校验。模型可能输出非法JSON、字段类型不对、甚至捏造不存在的函数名所以必须在进入实际执行前做一层Schema校验设置“最大尝试次数”。如果连续几次计划明显走入死胡同就停止而不是让模型无限循环对工具调用的结果做摘要和压缩。尤其是搜索结果或API返回大段JSON时全部塞回上下文不仅浪费Token还会让模型注意力涣散引入“安全护栏”Guardrail。对敏感操作做人工确认或规则检查防止模型在工具链里做出意外行为。如果是自然语言处理相对强度小的场景我会推荐Supervisor模式由一个“规划Agent”拆解任务多个“执行Agent”只负责单步工具调用最后再回到规划Agent汇总。分布式的控制让每一个环节都能被单独监控和恢复出问题时定位速度也快很多。6.3 智能体安全的现实风险记忆与知识库投毒提到Agent就不能不提安全问题。现在很多Agent都带了外部知识库或记忆模块系统一旦把外部内容直接当权威知识放进去就存在“投毒”风险。早年就有研究比如针对Agent记忆投毒的攻击论文证明通过对记忆库或知识库注入恶意内容能让Agent在执行任务时被诱导输出错误结果或执行异常操作。虽然现在我们接触的大多数Agent还不至于成为攻击目标但我在工程中明确要求自己不能盲目信任外部导入的知识库内容尤其是来自网页抓取或用户提交的文本要做来源分级和内容校验对于高风险动作如删除数据、发送邮件、支付操作必须设置二次确认定期检查Agent的记忆模块一旦发现干扰性内容要及时清理和隔离。这些设计和“LLM智能体自主容错控制构建可靠AI系统的工程实践”这个主题高度契合。可靠AI不是让模型永不犯错而是让系统在模型犯错时依然能保持可控、安全地降级。6.4 空间LLM与框架生态的一笔带过在热搜词里我看到“Spatial LLM”和“LLM框架”顺便在笔记里记录一下两个趋势。Spatial LLM是当前多模态空间理解的一个延伸方向目标是让模型理解空间关系和地理语义比如理解“超市在停车场的东北角”这类空间描述将来在具身智能、室内导航、GIS应用里都有想象空间目前还处于早期研究阶段。另一个更实用的就是“LLM框架”选型LangChain生态丰富但抽象层级略多LlamaIndex对RAG支持更专精Semantic Kernel更像微软系出身的跨语言框架。我的建议是至少先用裸代码跑通一次RAG再选择框架不要一上来就被框架的API文档牵着走否则底层原理会被完全遮蔽。7. 常见问题与排查技巧实录7.1 高频问题速查表把我在实践中反复遇到的典型问题整理成一张速查表方便排查时对号入座。现象可能原因排查方向模型输出JSON乱码或中间截断max_tokens太小、输出格式指令不清晰增大max_tokens加上few-shot JSON示例回答完全跑题Prompt缺少角色与背景、温度太高重写Prompt框架降低temperature知识库问答答非所问检索召回不准、问题与文档语体差异大检查嵌入模型、启用重排、查询改写同一问题答案不稳定temperature非0、Top-p太高评估场景下固定temperature为0Agent工具调来调去不干活计划逻辑太复杂、缺少最大步数限制减少单次任务拆解步骤增加终止条件本地部署推理非常慢模型过大、未量化、缺KV Cache优化切量化模型启用vLLM等推理框架上下文窗口爆了检索出来的块太多太大或者聊天历史过长控制检索块数量和大小对历史做摘要压缩7.2 高性价比的排查方法论跟LLM应用打交道这段时间我总结了三个线条简单但特别有效的方法。第一个是“最小复现法”。遇到问题先把Prompt单独拿出来换到最简单的模型和最少上下文中复现逐渐增加上下文和工具调用这样很容易定位是哪一层引入了干扰。第二个是“温度归零法”。把所有随机性参数归零把输出稳定下来再观察。很多“时好时坏”的问题归零后立刻暴露成了更明确的“固定错误”排查难度会骤降。第三个是“日志追踪法”。LLM应用跟传统软件不太一样不是报错就完事每轮对话里的Token用量、函数调用链、检索命中的文档块、模型耗时都要记下来。我刚开始学LLM时并没有怎么重视日志后面排查问题时才发现没数据可看只能抓瞎。现在毫无疑问加一个可观测性工具比如Langfuse或者自己写结构化日志是搭建LLM应用最值得的先期投入之一。7.3 我给新手的路线图建议结合这段时间的经验我会给初学LLM的人排一个十周路线图前三周打好Prompt和API调用基础学会自己写结构化输出并理解Token和上下文第四到六周跑通RAG最小系统重点吃透切块、嵌入、检索、重排第七到八周完整地做一个知识库问答应用并把评估指标建起来第九到十周再进入Agent和Function Calling重点是在工具调用中做参数校验和容错。这个路线里有一条原则每一步都先跑通一个最小系统再追求深度优化。很多人学LLM时喜欢大量收藏但收藏不等于学会。真正让我进步最快的永远是“自己亲手跑一个东西然后亲眼看到它出错”。8. 一点个人经验最后再以我自己的体会收个尾。整理“LLM学习笔记”这件事最大的收获不在于我记住了多少个名词而在于我学会了用工程思维看待LLM。LLM不是神谕也不是单纯的API它是一台“需要被约束、被验证、被观测”的推理引擎。每个项目最该问自己的问题不是“怎么让模型产出更惊艳的效果”而是“模型在这里会以什么方式犯错我能不能在设计上提前兜住”。我现在的笔记风格也在演进已经很少复制排版精美的原理图更多是用决策日志的方式记录——当时为什么选了某个模型、为什么这么切块、参数调的什么值、结果怎么样。回头翻的时候这些决策记录比任何教程都有用得多。如果看到这里的你也在学LLM建议不要把笔记做成知识百科试着把它做成你自己的实验记录。这样持续积累三个月后你会回来感谢自己当初的“麻烦”。 
长河君 · 2026/10/28 16:58:07 · 阅读 1.2k LLM学习笔记：从核心概念到RAG与智能体工程实践
我会直接从博文内容开始不做任何额外说明或元信息。下面是一篇围绕“LLM 学习笔记”展开的完整、充实、可直接发布的Markdown博文。1. 为什么要把LLM学习单独拎出来做笔记我在整理技术笔记时发现一个很普遍的问题LLM相关的文章、教程、帖子多到看不完但看完之后真正留下来的东西少得可怜。今天看到一个LangChain的调用示例明天刷到一个RAG的架构图后天又收藏一篇微调的实战帖结果真要自己动手搭一个应用时脑袋里全是碎片连模型选型都犹豫半天。所以我想把这段时间学习大语言模型LLM的过程整理成一套自己的笔记这篇就算第一版系统性的沉淀。这套笔记适合三类人刚开始接触LLM、对“模型怎么选”“提示词怎么写”“RAG和微调到底该先学哪个”感到混乱的入门者已经跑通过几个Demo、但总感觉落地时哪里不对劲的初级开发者以及想给团队做LLM技术分享、需要一条清晰讲解主线的技术布道者。我不会堆一堆概念名词而是把“学什么、为什么学、怎么上手、最容易踩什么坑”按一条实操路径串起来。按理说LLM学习最不缺的就是资料缺的是“主线”。这也是我反复强调要自己记笔记的原因。别人的博客是按照别人的知识结构组织的只有把内容打散、重新揉进自己脑子里的框架你才真正吸收了。这篇笔记的主线就是先建立认知地图再逐步深入核心概念然后连跑通工程链路最后回到智能体和可靠性的工程实践。2. 学习路径设计先搭认知骨架再填细节血肉2.1 我走过的弯路上来就啃源码和论文最初我犯了一个典型的错误刚知道Transformer是大模型的底座就直接打开《Attention Is All You Need》和PyTorch源码想从注意力机制的矩阵乘法开始一步步手推大模型原理。结果一周下来公式看了不少但GPT-4和开源模型之间怎么选、Prompt里temperature应该设多少、RAG的向量检索为什么会检索得不准这些问题一个也没解决。后来我才想明白LLM学习应该分三层顶层是“应用认知层”理解模型的能力边界、对话模式、上下文窗口、定价和延迟这些工程决策要素中层是“技术原理层”理解Token、注意力机制、微调、RAG、Function Calling这些技术的“为什么”和“适用条件”底层才是“算法实现层”梯度更新、分布式训练、量化推理、内核优化这一层只有当你需要训练模型或做极致性能优化时才必须深入。我建议绝大部分以应用落地为目标的人把70%的时间花在顶层和中层。底层不是不重要而是它的优先级应该由你当前问题和项目阶段决定。我见过有人花两周调FlashAttention的kernel结果自己的RAG系统连召回准确率都还没验证过这就是认知地图出了问题。2.2 学习闭环概念、实验、复盘三件套光看书和文档是不够的LLM的每个核心概念都应该配一个最小实验来验证。我在笔记里给自己立了一条规矩每个概念至少做一个“十行代码以内”的实验否则不算掌握。比如学“Temperature参数”就反复用不同的temperature值跑同一句Prompt记录输出的重复性、发散度和错误率学“上下文窗口”就故意把Prompt拉长到接近窗口极限观察模型是变笨了还是直接报错学“向量检索”就手写一个几十行的小工具从切块、向量化、存储到相似度检索全流程跑一遍。每次实验都记成“预期—实际—差异分析”的格式。比如你预期temperature从0调到1.2时输出会“更随机”但实际可能发现某些模型在1.2时开始出现完全离题的答案这个差异就是很有价值的经验沉淀。这套闭环最大的好处是三个月后你翻看笔记时能清楚看到自己当时的判断是否准确而不是记了一堆抽象概念。2.3 工具链地图越早梳理路径越清晰LLM的生态更新节奏非常快但工具链的“角色”是固定的。我把它们归纳为五类这样看到任何新项目都知道该放进哪个抽屉角色典型工具/服务核心解决的问题模型服务OpenAI、Anthropic、Google Gemini、开源模型本地部署提供推理能力开发框架LangChain、LlamaIndex、Semantic Kernel封装Prompt拼接、工具调用、记忆管理等流程向量数据库Milvus、Chroma、Qdrant、pgvector存向量、做相似度检索可观测性LangSmith、Langfuse、OpenTelemetry追踪调用链、评估质量部署与优化vLLM、Ollama、TensorRT-LLM、LM Studio提高吞吐、降低延迟这张表不需要背但需要经常拿出来对照。我每次看到一个RAG项目或者Agent项目第一件事就是问自己它在这张表的哪一格那种“什么东西都有但不知道放哪”的模糊感恰恰是学习LLM最大的杀手。3. 核心概念逐个拆解原理、例子和直观理解3.1 Token与上下文窗口大模型的地基单位Token是LLM处理文本的最小单位它可以是一个完整的单词、一个单词的一部分、甚至一个标点符号。用生活类比来说Token就像做寿司时切好的食材块模型一看“三文鱼”可能是一个Token也可能被切成“三文”和“鱼”两个Token这取决于模型使用的分词器预先怎么切。为什么Token理解这么重要因为它直接决定了实际业务的成本和效果。举例来说一个英文单词可能等于一个Token但中文里很多情况下一个汉字不止对应一个Token甚至一个常用词会被拆成两三个Token。这意味着用中文做LLM应用的Token消耗往往比英文更高。我实测过同一句业务提示词中英混合场景下Token开销比纯英文高30%到80%这会直接影响API账单和响应延迟。上下文窗口则决定了模型“一次能看见多少内容”。这里有个新手常有的误区认为窗口越大越好。其实窗口大不等于效果一定好因为模型对长上下文的注意力分布并不均匀很多开源模型在上下文超过一定长度后中间部分的信息利用率会明显下降——“Lost in the Middle”就是这个问题的经典描述。所以在搭建知识库问答系统时我宁可严格控制每个Prompt里只放最相关的2到4个文本块也不要把几万字的内容一股脑塞进去。3.2 温度、Top-p和最大长度一组必须亲手调过的参数在Prompt里配置参数时我最常被人问的两个问题就是温度到底调多少合适是不是越高越有创造性Top-p又是什么和temperature是什么关系这里我给一个直观理解temperature控制的是“概率分布的锐度”。设成0时模型每次几乎只选概率最高的词回答稳定、可复现性极高调到1.0甚至更高时低概率的词也有机会被选中回答更发散、更有“惊喜”。我常用的经验是做代码生成、数据提取、结构化输出temperature0.3甚至直接设0做头脑风暴、创意文案、故事生成temperature可以设0.8以上批量跑评测时温度固定为0否则同一测试集跑两次结果差异会干扰判断。Top-p可以理解为“累积概率截断”模型只在累计概率达到p的那些词里做选择。它的作用不是替代temperature而是和temperature叠加使用。我的习惯做法是先把temperature设低再用Top-p限制候选词范围如果顶层输出总不稳定再逐步提升temperature而不是一上来就调到1.5。最大输出长度max_tokens这个参数最容易被忽略。我曾经在做一个调用外部工具的项目时模型老是输出不完整JSON排查了半天发现就是max_tokens设得太小模型生成到一半就被截断了。至少给模型的输出预留比期望文本多20%的空间这是最低标准。3.3 幻觉问题大模型犯错的三种类型“幻觉”是LLM落地时绕不开的话题它不是简单的“胡说八道”四个字能概括的。我个人的归类方法是把幻觉分为三类事实性幻觉模型精准但错误地陈述一个事实比如把某产品的发布日期说错一个年份忠实性幻觉模型没有遵循用户提供的内容自己编造了额外信息比如你给它一份五条条款的文档它回答时自己脑补了第六条逻辑性幻觉模型给出的推断在上下文内无法成立比如“前三项都是A类所以第四项也是A类”但第四项实际是B类。这三类幻觉的应对策略完全不同。事实性幻觉要靠RAG和知识库约束忠实性幻觉要靠提示词里强调“只能基于给定内容回答”并且配合输出校验逻辑性幻觉则最棘手它需要模型具备更强的推理能力通常只能靠换更强模型或者让模型拆解步骤逐步“想清楚”。学LLM时如果只把幻觉当成一个名词记住那真正排查问题时一定会懵。3.4 Prompt不是咒语而是“对话协议”我踩过很长一段时间的坑以为Prompt就是魔法咒语写得越花哨效果越好。实际并非如此。Prompt是跟模型约定一种协作方式本质上是“对话协议”。你是任务发布方模型是协作者你需要说清楚背景信息、角色、目标、输出格式、边界和约束条件。我最常用的一套Prompt写作框架叫“R-T-F-C”四个字母依次代表Role角色、Task任务、Format格式、Constraint约束。参考模板是你是[角色]请针对[任务目标]给出结果。要求满足[具体输出格式]同时注意[约束条件例如只基于给定材料回答、不要编造、不确定时明确说不知道]。提示词工程的另一大原则是“示例优于说明”。与其告诉模型“请严格输出JSON”不如给它一个in/out示例这比一百句抽象规则都管用。自从我学会在每个关键Prompt里带1到2个few-shot示例后模型输出的稳定性和格式合法率有了质的提升。4. RAG、微调和评估工程落地的三块基石4.1 RAG的标准流程和常见性能瓶颈RAG检索增强生成是目前让LLM“说实话、说对事实”最流行的脚手架。它的核心思路是用外部知识库先检索出与问题最相关的文本片段再把这些片段放进Prompt里让模型基于它们作答而不是让模型凭空回忆训练数据。这个思路用一句话概括就是不要让模型上考场之前背书而是让它考试时自带资料。我的RAG实现流程一般分四步切块、向量化、入库、检索生成。切块时要注意块的大小和重叠度块太小语义不完整块太大检索不准还浪费Token向量化要选择与模型匹配的嵌入模型入库要选择合适的向量数据库检索生成时最重要的一个技巧是不要只做相似度检索最好做一下重排Reranking把第一次检索回来的候选片段用重排序模型精调一下顺序。我实测过加一轮重排通常能让最终回答质量提升10%到15%这个性价比非常高。但RAG最常见的坑也有几个特别提醒新手注意切块前必须先清洗文档格式比如PDF里的两栏排版、表格转文本、扫描件的OCR错字这些都直接影响向量质量不要把整个文档切成巨大块塞进向量库更好的是先按章节结构切再根据语义长度做二次拆分检索命中率不达标时先检查“嵌入质量”和“查询改写”而不是一味调向量库参数。4.2 微调要知道什么时候不该微调微调Fine-tuning是很多人一听就兴奋的方向总觉得“我要把模型变得更强”于是拿着几千条数据就微调。实际上微调的适用场景比大多数人想象中窄得多。我的判断标准很简单需要模型学习新知识不要微调应该用RAG。微调不适合更新模型记忆里的事实信息你今天微调进去明天新事实出来又要重新调成本极高需要模型改变格式、语气、交互风格适合微调比如把模型调成客服风格、让输出遵循固定表格格式需要模型学会调用工具的特定方式和规则适合微调特别是在函数调用场景里微调能显著提高参数提取的准确率需要模型推理能力大幅提升微调做不到根本性提升那是基础模型能力决定的不如换一个更大的模型。如果确认要微调我会推荐从参数高效微调PEFT/LoRA入手因为它的显存需求低、实验周期短。微调前要做的最重要准备工作是数据清洗重复样本、错别字、逻辑不一致的标签对这些都会让模型学坏。模型微调后还容易出现“灾难性遗忘”所以最好把原始通用数据也混入一部分来微调。4.3 LLM as Judge选型与评估陷阱评估模型输出质量是LLM应用工程里最容易被低估的环节。你可以人工标注一部分数据但线上每次都要人工评估是不现实的于是就有了“LLM as Judge”的做法用一个更聪明的模型当裁判来给目标模型的输出打分或做对比排序。使用LLM as Judge时有几个大坑实测中我全部踩过裁判模型对顺序敏感。同样的两个答案A在前和B在前评分结果可能不同。解决方法是多次交换顺序取平均裁判模型会被“更长更华丽的回答”带偏。输出明显更长时裁判往往给更高分这不代表质量更高。评估的标准里必须明确添加“忽略长度差异”裁判模型自身也受幻觉影响。如果判断标准含糊它会自己脑补一些需求来打分所以评价标准一定要尽量客观化、条目化。我现在的评估体系里其实不只用LLM作为唯一裁判还会混入一些确定性指标例如检索覆盖度、JSON格式合法率、回答是否包含确切来源引用。只有“确定性指标 LLM Judge 少量人工抽检”三者组合效果才稳定可靠。5. 从零搭建一个本地知识库问答应用的完整过程5.1 场景假设与整体方案设计为了让笔记不“飘”我决定用一个具体的项目来示范整条链路搭建一个面向私有文档的本地知识库问答助手用户提问后系统检索相关文档并生成带来源引用的答案。技术选型情况是方案偏向开源链路主要考虑成本可控和数据不出内网。嵌入模型使用bge-m3这类中文效果有保障的开源模型向量数据库使用轻量级的ChromaLLM推理通过Ollama加载Qwen2.5或Llama3系列模型。整体架构不算复杂核心意图是跑通一个最小可行版本后续再考虑更重型优化。为什么选Ollama而不是直接调用商业API两个原因一是数据敏感场景下私有化部署更有优势二是Ollama在macOS和Linux上对本地模型管理非常友好一条命令就能拉起一个GGUF格式的模型。GGUF是llama.cpp生态的量化模型格式体积小、推理快很适合个人在本地摸索学习。我这次选的是7B到8B量级的量化模型一台16GB显存或内存的消费级机器就能流畅跑起来。5.2 关键步骤切块、向量化、检索与生成整个流程的骨架代码并不复杂拆开看主要四步。第一步是文本切块我使用的策略是先将文档按Markdown标题结构分割再把单个块控制在512到1024个Token之间块之间保留64个Token的重叠这样能防止一句话被硬生生切成两半。切块的代码可以参考recursive character splitter来实现。第二步是向量化入库。把每一块文本通过嵌入模型转成向量连同原始文本和元数据来源、页码、章节名一起存到向量数据库。这里很容易犯的一个错误是忘记保存元数据。如果你不记录这一块来自哪个文档、哪一页后面回答里想加“来源引用”就非常困难。我第一版就吃过这个亏只好清空数据重新入库。第三步是检索。给定一个用户问题先把问题和文档切片都转成向量然后用余弦相似度找到最相近的Top-K块。K值的选取要平衡信息量和噪音我通常用K5到8。但检索方向的细节也值得说用户在自然语言里的问法和文档里的书面表述往往差异很大比如用户问“这个产品怎么保修”文档里可能写的是“售后服务条款”这种情况下仅凭余弦相似度可能召回不到所以往往需要多路由检索或者检索前做查询改写把问题改写成更贴近文档语体的表达。第四步是生成。把检索回来的文本块按顺序放进Prompt明确约束模型“只基于给定材料回答如果材料不足请直接说不知道引用来源时请标注块编号。”这样输出的答案既可靠又方便追溯。5.3 参数计算参考显存、并发与延迟本地部署时显存估算是个实操点。以7B参数模型为例如果做4比特量化模型的权重体积大概是4到5GB加上KV Cache和运行时开销16GB内存的机器能顺畅跑8GB内存就有点紧张。并发场景要另算因为每个并发推理都会占用额外的显存做KV Cache。我第一版想同时处理10路请求结果本地机器直接OOM后来才知道要做并发限制。如果要用商业API成本可以做一个简单估算公式单次请求成本约等于输入Token数乘以输入单价加上输出Token数乘以输出单价。实际调模型时可以把一条Prompt的实际Token算出来再估算而不是凭感觉觉得“太少了吧”。长期跑的话建议用日志把每个请求的Token用量记录下来不然月底账单出来会吓一跳。5.4 实战环节我的一次Debug全过程我说一个实操过程中的真实案例。知识库问答系统上线后有个用户提问“2024年Q3的销售数据是多少”系统检索回来的文本块实际上是“2023年Q3销售数据汇总”但回答里把年份写成了2024。原因分析是这样的切块时年份信息被分割得比较靠后检索时只看到了“Q3销售数据”语义相似度很高年份差异就没被模型注意到。解决办法其实很简单在每个文本块的开头强制以“【时间范围2023年Q3】【文档来源销售周报】”这种元数据前缀开头。然后把这个规则写进切块和入库的预处理流程。这个改动只花了一个小时但准确率提升非常明显。自那以后我所有的元数据信息比如日期、所属部门、版本号都会明确放进文本块顶部而不只是存在向量库的元数据字段里。6. 智能体与工具调用如何让模型真正动起来6.1 Function Calling的底层逻辑LLM的能力边界面着广大但有一类专项能力越来越重要让模型调用外部工具。当你跟模型说“帮我查一下今天天气并提醒我出门带伞”模型本身不会联网但它可以输出一个结构化的调用指令比如{function: get_weather, args: {city: 北京}}然后由外部的代码去真正执行这个请求。这种机制就叫Function Calling或者叫Tool Use。学Function Calling要理解一个关键点模型不是直接执行函数而是生成一个调用指令。你需要在代码里解析这段指令、校验参数、执行函数、把结果返回给模型。整个链路实际上是一个多轮对话模型出指令程序干活拿到结果后再给模型模型把结果组织成最终回答。这里最常见的Bug就是函数返回结果超过了上下文窗口限制或者返回结果是HTML表格但模型没理解它其实是结构化数据。6.2 自主容错与控制Agent工程里的可靠性问题用LLM做Agent是当前最热的方向但也是最容易翻车的方向。一个Agent往往需要计划Planning、工具调用、记忆和反思四大模块而每一步都可能出错。我自己的实践体会是Agent的可靠性工程不是“让模型更聪明”而是“让系统更容错”。常用的容错策略包括对Function Calling做严格参数校验。模型可能输出非法JSON、字段类型不对、甚至捏造不存在的函数名所以必须在进入实际执行前做一层Schema校验设置“最大尝试次数”。如果连续几次计划明显走入死胡同就停止而不是让模型无限循环对工具调用的结果做摘要和压缩。尤其是搜索结果或API返回大段JSON时全部塞回上下文不仅浪费Token还会让模型注意力涣散引入“安全护栏”Guardrail。对敏感操作做人工确认或规则检查防止模型在工具链里做出意外行为。如果是自然语言处理相对强度小的场景我会推荐Supervisor模式由一个“规划Agent”拆解任务多个“执行Agent”只负责单步工具调用最后再回到规划Agent汇总。分布式的控制让每一个环节都能被单独监控和恢复出问题时定位速度也快很多。6.3 智能体安全的现实风险记忆与知识库投毒提到Agent就不能不提安全问题。现在很多Agent都带了外部知识库或记忆模块系统一旦把外部内容直接当权威知识放进去就存在“投毒”风险。早年就有研究比如针对Agent记忆投毒的攻击论文证明通过对记忆库或知识库注入恶意内容能让Agent在执行任务时被诱导输出错误结果或执行异常操作。虽然现在我们接触的大多数Agent还不至于成为攻击目标但我在工程中明确要求自己不能盲目信任外部导入的知识库内容尤其是来自网页抓取或用户提交的文本要做来源分级和内容校验对于高风险动作如删除数据、发送邮件、支付操作必须设置二次确认定期检查Agent的记忆模块一旦发现干扰性内容要及时清理和隔离。这些设计和“LLM智能体自主容错控制构建可靠AI系统的工程实践”这个主题高度契合。可靠AI不是让模型永不犯错而是让系统在模型犯错时依然能保持可控、安全地降级。6.4 空间LLM与框架生态的一笔带过在热搜词里我看到“Spatial LLM”和“LLM框架”顺便在笔记里记录一下两个趋势。Spatial LLM是当前多模态空间理解的一个延伸方向目标是让模型理解空间关系和地理语义比如理解“超市在停车场的东北角”这类空间描述将来在具身智能、室内导航、GIS应用里都有想象空间目前还处于早期研究阶段。另一个更实用的就是“LLM框架”选型LangChain生态丰富但抽象层级略多LlamaIndex对RAG支持更专精Semantic Kernel更像微软系出身的跨语言框架。我的建议是至少先用裸代码跑通一次RAG再选择框架不要一上来就被框架的API文档牵着走否则底层原理会被完全遮蔽。7. 常见问题与排查技巧实录7.1 高频问题速查表把我在实践中反复遇到的典型问题整理成一张速查表方便排查时对号入座。现象可能原因排查方向模型输出JSON乱码或中间截断max_tokens太小、输出格式指令不清晰增大max_tokens加上few-shot JSON示例回答完全跑题Prompt缺少角色与背景、温度太高重写Prompt框架降低temperature知识库问答答非所问检索召回不准、问题与文档语体差异大检查嵌入模型、启用重排、查询改写同一问题答案不稳定temperature非0、Top-p太高评估场景下固定temperature为0Agent工具调来调去不干活计划逻辑太复杂、缺少最大步数限制减少单次任务拆解步骤增加终止条件本地部署推理非常慢模型过大、未量化、缺KV Cache优化切量化模型启用vLLM等推理框架上下文窗口爆了检索出来的块太多太大或者聊天历史过长控制检索块数量和大小对历史做摘要压缩7.2 高性价比的排查方法论跟LLM应用打交道这段时间我总结了三个线条简单但特别有效的方法。第一个是“最小复现法”。遇到问题先把Prompt单独拿出来换到最简单的模型和最少上下文中复现逐渐增加上下文和工具调用这样很容易定位是哪一层引入了干扰。第二个是“温度归零法”。把所有随机性参数归零把输出稳定下来再观察。很多“时好时坏”的问题归零后立刻暴露成了更明确的“固定错误”排查难度会骤降。第三个是“日志追踪法”。LLM应用跟传统软件不太一样不是报错就完事每轮对话里的Token用量、函数调用链、检索命中的文档块、模型耗时都要记下来。我刚开始学LLM时并没有怎么重视日志后面排查问题时才发现没数据可看只能抓瞎。现在毫无疑问加一个可观测性工具比如Langfuse或者自己写结构化日志是搭建LLM应用最值得的先期投入之一。7.3 我给新手的路线图建议结合这段时间的经验我会给初学LLM的人排一个十周路线图前三周打好Prompt和API调用基础学会自己写结构化输出并理解Token和上下文第四到六周跑通RAG最小系统重点吃透切块、嵌入、检索、重排第七到八周完整地做一个知识库问答应用并把评估指标建起来第九到十周再进入Agent和Function Calling重点是在工具调用中做参数校验和容错。这个路线里有一条原则每一步都先跑通一个最小系统再追求深度优化。很多人学LLM时喜欢大量收藏但收藏不等于学会。真正让我进步最快的永远是“自己亲手跑一个东西然后亲眼看到它出错”。8. 一点个人经验最后再以我自己的体会收个尾。整理“LLM学习笔记”这件事最大的收获不在于我记住了多少个名词而在于我学会了用工程思维看待LLM。LLM不是神谕也不是单纯的API它是一台“需要被约束、被验证、被观测”的推理引擎。每个项目最该问自己的问题不是“怎么让模型产出更惊艳的效果”而是“模型在这里会以什么方式犯错我能不能在设计上提前兜住”。我现在的笔记风格也在演进已经很少复制排版精美的原理图更多是用决策日志的方式记录——当时为什么选了某个模型、为什么这么切块、参数调的什么值、结果怎么样。回头翻的时候这些决策记录比任何教程都有用得多。如果看到这里的你也在学LLM建议不要把笔记做成知识百科试着把它做成你自己的实验记录。这样持续积累三个月后你会回来感谢自己当初的“麻烦”。