★ FEATURED ARTICLE 最近在给团队做一次内部分享主题就是“大语言模型的能力和局限”。说实话准备这堂课时我翻了不少资料也顺手整理了一份学习笔记。结果越整理越发现外面铺天盖地的讨论要么把LLM说得神乎其神要么把它贬得一文不值。这两种视角都容易误导人——尤其是对刚入门、想在实际项目里用上LLM的朋友来说。我更愿意把大语言模型理解成一个“能力很强、但你得知道它哪儿不行”的工具。它能写文案、能改代码、能总结文档、能当聊天机器人但它在数学计算、事实核查、长文本推理这些地方又会突然“翻车”。这套笔记不是教科书式的科普而是结合我这几年做AI应用落地、跑本地模型、做数据标注的实际经验把LLM的能力边界、典型局限、工程上的规避手段一次讲清楚。如果你正在纠结“要不要用LLM”“怎么用才能少踩坑”“本地部署到底靠不靠谱”那这篇笔记应该能帮你省不少时间。1. 能力边界LLM到底强在哪又为什么强1.1 本质是“下一token预测”强能力源于统计规律很多人第一次接触大语言模型时都会被它的“智能”震撼。但你真去读它的技术原理会发现核心机制朴素到让人惊讶给定前面一段文本预测下一个token可以粗略理解为“下一个词”是什么。GPT、LLaMA、Qwen、DeepSeek这些模型底层干的全是这件事。那为什么一个“猜词游戏”能写出像样的文章、能回答复杂问题关键在“规模”二字。模型在海量互联网文本上训练参数从几十亿到几千亿不等。为了预测准下一个token它被迫学会了语法、事实、逻辑关系、情感表达、代码结构……这些知识不是有人手工写进去的而是模型从数据里自己“领悟”出来的统计规律。我用一个生活化的类比来理解这件事LLM像一个读过海量书籍的图书管理员。你问他某个冷门知识点他未必记得原文但因为他“读得够多”他能根据各种相关书籍中出现过的表达模式拼出一个看起来非常合理的回答。这个类比后面还会用到——因为它同时解释了LLM为什么强知识覆盖面广也解释了它为什么会产生幻觉拼错了或者记忆混淆。实际应用中这种能力体现在几个方面文本生成与改写写邮件、写文案、总结会议纪要这是最成熟的应用场景。代码理解与生成补全代码、解释代码、做单元测试模型在代码语料上的表现往往比通用文本更强。翻译与润色多语言互译的质量已经接近甚至超过传统机器翻译。对话与问答理解用户意图给出有上下文连贯性的回复。初级推理比如“A比B高B比C高谁最高”这类简单逻辑LLM能处理但一旦步骤变多就容易出错。这些能力不是“一键获得”的。在我实际使用中感受最深的一点是LLM在生成“常见任务”时质量极高比如写周报、写Python函数、翻译产品说明但在生成“罕见任务”时质量就断崖式下跌。你让它写一份符合某个冷门行业规范的合同或者按照某家公司的内部编码风格写代码它往往会一本正经地自由发挥。这就是统计规律的底层逻辑决定的。1.2 从纯文本到多模态视觉大语言模型带来了什么如果你以为大语言模型只能处理文字那就落后了。现在的视觉大语言模型VLMVision-Language Model已经把“看图说话”整合进来了。典型架构是“视觉编码器 语言模型”先用视觉编码器比如CLIP、SigLIP这类把图片转成特征向量再映射到语言模型的输入空间让模型能“看懂图”并基于图像内容进行对话。这类模型在实际项目里非常有用。我之前做一个设备故障检测的辅助系统传统做法是用一个图像分类模型判断“设备是否异常”但分类模型只能给出一个标签给不出解释。换成视觉大语言模型后操作人员可以直接问“图片里哪个部件有划痕严重程度如何”模型不仅能指出位置还能给出文字判断依据。这种“可解释性”在工业场景里价值极大。多模态能力也在快速扩展文档理解把PDF、扫描件里的表格提取成结构化数据、截图转代码把UI设计图变成HTML、视频理解逐帧分析内容并总结。不过要提醒一句VLM对“清晰图像”的依赖很高模糊图片、反光、遮挡严重的图像它的理解准确率会明显下降。而且VLM同样有幻觉问题——你给它一张根本没有红绿灯的街道照片它也可能根据“街道场景”的统计先验描述出一个不存在的红绿灯。这本质上还是“统计规律”在起作用。1.3 能力全景一张表看清LLM擅长的场景为了让自己和团队在项目选型时快速判断“这个任务适不适合用LLM”我做了一张清单按成熟度分层能力领域具体任务成熟度典型应用文本生成文案创作、邮件撰写、故事改写高营销内容、客服话术文本理解摘要、情感分析、实体提取高舆情监控、文档归档代码任务生成、解释、测试、重构高开发辅助、教学翻译润色多语言翻译、学术润色高本地化、出版知识问答常识问答、百科式回复中高客服机器人、内部知识库数学计算算术、方程求解低不建议直接用交给计算器/代码事实核查时效性信息、精确引用来源低必须配合检索和人工审核多步推理复杂逻辑链、规划中需要配合Agent和工具链这张表基本就是我判断“要不要用LLM”的决策依据凡是对语言表达、总结归纳、创意生成有要求的任务LLM是首选凡是要求绝对精确、实时更新、可验证的任务必须给LLM“配上外部工具”才能用。记住这一点能帮你避开后面将要讲到的绝大多数坑。2. 局限盘点看似聪明实际翻车的典型场景2.1 幻觉一本正经地编答案幻觉Hallucination可以说是LLM最知名、也最让人头疼的问题。简单说模型会生成一段语法完全正确、逻辑看似通顺、但内容完全错误或者凭空捏造的文字。你问它某个公司年报里的具体数字它可能给你一个看着很像样的答案但那个数字根本不存在。为什么会产生幻觉回到那个“图书管理员”类比。模型在预测下一个token时并不是在“查数据库”而是在“根据统计规律临时编”。当它遇到训练语料里信息不足、或者问题过于冷门时就会激活一些相邻概念把“可能相关”的内容拼凑出来。这个过程在概率空间里是合法的——因为从语言模型的角度看编出来的token序列“概率很高”符合语言习惯但从事实角度看就是错的。我在实际项目中遇到过非常典型的案例。一次让LLM帮我们整理一个开源项目的贡献者名单结果它列出了几个从未参与过该项目的人名甚至杜撰了某位开发者的GitHub主页。看起来特别专业但一查全是假的。从那以后我们团队定了一条铁律凡是LLM输出的关键事实信息必须经过源头验证默认按“存疑”处理。降低幻觉有几个工程手段后面会详细讲这里先提几个方向一是用RAG检索增强生成把模型生成过程和真实知识库绑定二是用“引用溯源”的提示词技巧强制模型输出时标注信息来源三是用更小、更垂直的微调模型减少模型在不相关领域的“自由发挥空间”。2.2 上下文窗口的错觉记得住不等于用得好大模型现在动辄几十万token的上下文窗口看起来好像能“装下”一本长篇小说。但这里有个关键误区上下文窗口大只代表模型能“看到”这么多内容不代表它能“用好”这些内容。业界有一个专门描述这个问题的概念叫“迷失在中间”Lost in the Middle。研究发现模型对输入内容的注意力分布并不均匀——它对开头和结尾的内容利用得最好对中间部分的内容利用率明显下降。换句话说你把一个500页的文档塞进上下文模型大概率只能精准引用前50页和后50页的信息中间400页的内容要么遗漏、要么混淆。另一个与之相关的问题是“越界遗忘”。当对话历史超过一定长度后模型会忘记前文的约定。比如你在一开始要求“请用繁体中文回答”聊了50轮之后它可能突然切回简体中文。这不是模型“变笨了”而是早期内容在注意力机制中逐渐被稀释了。针对这两个问题我在实操中养成了几个习惯。第一重要信息放在提示词的末尾次重要信息放在开头最不重要的放中间第二不要无限延长对话聊到一定轮数后开启新会话把关键上下文浓缩成一段摘要带过去第三涉及大量文档时优先做“检索后拼接”而不是把全部文档一股脑塞进去。这些方法不能根治问题但实测下来能明显提升输出质量。2.3 数学和精确推理计算器才是真实生产力LLM在数学和精确计算上的表现是很多人从“惊艳”转“失望”的第一站。你让它算“17乘以23”它可能能答对但让它算“347乘以892”就未必了因为它不是在“算”而是在“背诵”类似的算术模式。一旦数字稍微复杂一点统计规律就不够用了。更典型的翻车场景是多步骤推理。比如一个逻辑题“甲有5个苹果给了乙2个又从丙那里拿到3个丙原来有4个梨请问甲现在有几个苹果”这题的答案是6个但LLM可能会在步骤中绕晕给出7个、9个之类的答案。问题不在于它不懂“加减法”而在于它在一步步生成文本时中间任何一步出错都会被后续步骤放大——它没有一个“内部计算器”来保证每一步都精确。我现在的处理原则非常简单数学计算和精确逻辑一律交给外部工具。在提示词里明确要求模型“遇到计算类需求只写计算表达式不要直接给出答案”然后把计算表达式用代码解释器或内置工具去执行。这样既利用了LLM的“理解能力”来把自然语言问题转成计算程序又避免了它直接算错的硬伤。很多主流的Agent框架里都有“计算器工具”或“代码执行沙箱”本质就是在补这个短板。2.4 知识截止、安全对齐与Agent攻击面LLM还有一个天然硬伤它的知识截止于训练数据。模型不会因为发布了新版本就自动知道最新事件你在2026年问它“2025年某行业发生了哪些重大变化”它在没有外部检索的情况下只能靠推理猜测。解决这个问题同样要引入外部检索或工具让模型按需获取新信息。安全对齐的问题也不可忽视。预训练模型的目标是“预测下一个token”不是“安全回答问题”。所以现在的主流模型都要做对齐训练RLHF等让模型学会拒绝有害请求。但对齐并不完美有心人可以用提示注入、越狱等方式绕过限制。更值得注意的是当LLM被包装成Agent智能体时攻击面会进一步扩大。业界已经有不少研究展示了这类风险。比如AgentPoison这样的工作就指出只要往Agent的记忆库或知识库里投毒一小撮恶意内容就能在Agent调用记忆时改写其行为让它执行攻击者预设的指令。这提醒我们当LLM从“聊天玩具”变成“执行任务的智能体”时对输入内容的信任级别必须降级底层记忆、外部数据、工具调用都要当成“不可信输入”来设计防护。我在和团队做Agent类项目时优先级最高的不是“功能做得多炫”而是“哪些输入可能被恶意利用边界设在哪里”。这个问题想不清楚Agent越强大风险越大。3. 工程实践主流方案如何绕开局限3.1 RAG把检索挂在外面的知识库既然LLM最大的问题是“记不牢、记不全、容易编”最直接的解法就是别让它“凭记忆回答”而是让它“看着资料回答”。这正是检索增强生成Retrieval-Augmented GenerationRAG的核心思路。一个典型的RAG流程分四步离线阶段把你的私有文档切分成小块chunk每块用embedding模型转成向量存入向量数据库。在线查询用户提问后把问题也转成向量在向量库里做相似度检索取出最相关的若干块。上下文拼装把检索到的文档块和用户问题一起组织成提示词。生成回答LLM根据提供的上下文生成答案同时可以要求它标注引用来源。这个方案的工程价值在于你不需要重新训练模型只需要维护一个外部知识库。当文档更新时只要重新做索引问答内容就随之更新完美解决知识截止问题。实操中有几个参数值得认真调。第一是chunk大小我常用的是300到500字左右太小会丢失上下文太大又会让检索精度下降。第二是检索的top-k一般取3到5条即可取太多反而会引入噪声。第三是embedding模型的选择中文场景建议用专门针对中文优化的模型否则检索效果会明显打折。第四是重排序rerank粗排取回20条再用重排序模型精排只把最相关的5条交给LLM这个组合我在实际项目里效果最稳。RAG不是万能的。如果原始文档本身信息就不完整或者检索阶段取错了文档那LLM照样会基于错误材料生成错误答案。所以我在RAG系统里都会加一道“可溯源审查”要求模型在回答中标注引用的是哪个文档块这样即使答错了也能快速定位是检索问题还是生成问题。3.2 Agent与工具调用让模型“动手”而不是硬想上一节讲到LLM在数学、多步推理上的短板另一个主流的规避思路是“工具调用”。与其让模型硬想答案不如给它配一堆工具让它把复杂任务拆解成操作步骤然后一步步调用工具执行。这就是Agent智能体的核心模式。典型场景是让Agent查询天气、查数据库、调用API、执行代码。模型本身不需要知道确切的答案它只需要理解任务目标调用正确的工具再把工具返回的结果组织成自然语言回答。这种方式把“LLM的强项”理解意图、规划步骤、组织表达和“工具强项”精确计算、实时数据、确定的逻辑做了分工。工程上做Agent有几种路线。如果你用现成框架比如LangChain、LlamaIndex这类关键是设计好“工具描述”。模型是靠工具描述来决定调用哪个工具的描述写得含糊它就会乱调。我见过一个项目工具是“查询用户订单信息”描述写得太像“获取用户数据”结果模型在回答无关问题时也会误调用这个工具白白消耗资源。工具描述要写清楚“什么时候用、传什么参数、返回什么结构”。自主容错控制也是Agent落地时逃不开的问题。模型写的工具参数偶尔就是错的或者工具内部报错。你在设计Agent时一定要让Agent具备“失败了能根据错误信息自己换一种方式再试”的能力。我在实际项目里会给每一步工具调用加一个超时限制并让模型在看到报错后输出“重新规划步骤”而不是把报错信息原封不动丢给用户。这听着简单做起来很考验系统的工程细节。还有一个安全层面的提醒Agent的工具调用权限要按照“最小权限原则”来设计。有些人在验证阶段图方便给了Agent一个不限权限的数据库账号结果它执行了一个危险的删除语句把测试数据清空了。这种事故在真实团队里反复发生。工具能做什么、不能做什么必须在系统层面写死不能指望模型的“自觉”。3.3 结构化输出YAML/JSON配置驱动的LLM应用很多人问“大语言模型是不是主流用YAML提供配置参数”。我的回答是YAML本身是配置文件格式确实在LLM应用开发中大量使用比如Prompt模板、模型参数、Agent工具配置、工作流定义几乎都能看到YAML的影子。但大家真正关心的其实是另一件事怎么让LLM输出“结构化数据”而不是一段自由文本。因为下游系统要拿LLM的输出去做逻辑判断自由文本没法直接解析。让LLM输出结构化结果的常见做法有这么几种第一用提示词约定格式。说白了就是告诉模型“请以JSON格式输出包含以下字段”。这种方式最灵活但偶尔会格式损坏尤其是模型输出夹杂解释文字时。第二用工具调用机制。OpenAI的function calling、各家模型的tool-use接口本质上是先让模型从预定义的函数列表里选一个然后按那个函数的参数JSON schema来生成结构化参数。这种方式的稳定性比我之前用提示词约定高很多。第三用受限解码。在生成时从概率层面约束模型只能输出符合既定语法格式的token。比如说定了JSON Schema解码时就按Schema要求逐个token生成不允许跳出结构。这种方式最稳定但对推理框架的要求更高。在实际项目中我通常用YAML来管理这些约束和配置。做一个LLM应用时我会建一个YAML文件把下面这些东西全放进去model: provider: openai-compatible name: qwen2.5-14b-instruct temperature: 0.3 max_tokens: 2048 prompt: system: templates/system.md user: templates/user.md retrieval: top_k: 5 chunk_size: 400 rerank_enabled: true tools: - name: calculator description: 用于执行数学计算输入必须是算术表达式 - name: search_news description: 用于查询最新新闻当用户问题涉及近期事件时必须调用这样做的好处是提示词、参数、工具定义都可以独立修改不用改动代码。比如同一个服务要服务不同业务线只要切换YAML配置就行。我在团队里推广这套模式之后开发和联调效率明显提升大家不用为一个参数改来改去反复发版。这应该就是你说的“用YAML提供配置参数”的落地形态。3.4 本地部署实践GGUF、量化模型与端侧运行热词里多次出现“本地部署大语言模型”“安卓本地运行GGUF格式LLM”这块我也聊些实际经验。为什么有人非要在本地跑LLM三个原因最常见隐私敏感数据不能出内网、成本控制API调用量大长期费用可观、离线场景没有网络环境。本地部署的技术栈现在很成熟。模型权重常见的格式是GGUFGGML Unified Format这个格式的核心价值在于量化把原本需要几十GB显存的模型压缩到几GB同时保持大部分能力。量化等级上“Q4_K_M”是目前比较推荐的性价比选择Q8的精度更高但体积更大Q2会感觉模型明显“变蠢”。我做选型时的经验是7B到14B参数的模型用Q4_K_M量化日常办公机器就能跑如果追求更高精度再往Q8走但显存和内存都要跟上。跑GGUF模型的主流工具是llama.cpp以及基于它的各种封装。个人电脑上用Ollama就够了一条命令就能拉模型、起服务、暴露OpenAI兼容接口。如果想要更精细的控制比如调整KV cache策略、绑定特定GPU层数就用llama.cpp直接编译运行。在安卓端目前也有不少支持GGUF的App实测下来中端手机跑7B模型的速度大概不到10 token/s能用但谈不上流畅适合做离线演示或轻量问答。本地部署的实际难点不在“跑起来”而在“跑得好”。首先是显存和内存的分配问题模型权重只是基础推理时的KV cache同样吃显存你把权重塞进去了、KV cache放不下推理速度会断崖式下降。其次是并发能力本地模型一般同时只能处理少量请求远不如云端的弹性扩容。最后是硬件选型CPU推理适合7B以下模型14B以上建议使用支持大容量显存的GPU。我自己测试的感觉是在纯CPU上跑7B Q4模型速度大概在5到10 token/s之间查资料还行多轮对话就会明显感到“卡”。如果你只是想在本地验证某个想法我建议直接从Ollama开始选7B或14B的中文优化模型比如Qwen系列量化等级用Q4_K_M。等你确定模型效果满足需求再考虑要不要上专业推理服务框架。没有必要一上来就搭一套复杂的推理系统——大炮打蚊子纯属给自己添乱。4. 数据、精调与评测让模型更懂你的业务4.1 数据标注在LLM链路里的位置热词里有一条“llm怎么数据标注”这也是很多团队实际困惑的地方。数据标注不是一个孤立的环节它在LLM生命周期的多个阶段都存在但每个阶段对数据的要求完全不同。预训练阶段需要的是海量、多元、高质量的自然文本通常以“按token付费”的外包方式完成清洗、去重、过滤。这个阶段和绝大多数应用团队无关跑一次预训练的成本普通人根本扛不住。真正和大多数团队相关的是后面两步。指令微调SFT阶段需要的是“指令-回复”对。每条数据包含一条用户指令和一条期望模型输出的标准答案。这里对数据质量的要求极高指令要覆盖目标场景的主要类型回复要准确、格式规范、符合业务风格。做过数据的同学都知道构造一万条低质量数据效果往往不如一千条精心设计的优质数据。人类反馈对齐RLHF/DPO阶段需要的是“偏好数据”。同一句指令让模型生成多版回复由标注员排序标出哪个更好、好在哪里。这类数据的标注主观性最强需要标注员对任务目标有深刻理解。我在团队内部做过一次面向业务客服的对话模型精调当时最有价值的不是让外包标注员凭空写指令数据而是把真实客服对话记录脱敏后改写成“指令-DSL”再由业务专家校验。这种做法能保证数据里包含真实业务的语气、高频问题和解决方案模型学完之后在实际场景的代入感远好于通用数据训练的模型。这也是为什么很多团队热衷于“用聊天记录精调LLM”——聊天记录里藏着只有一线业务才有的真实语境。4.2 用聊天记录精调模型的可行路线“用聊天记录模型精调LLM”这个思路操作上核心是三步第一步清洗。原始聊天记录里大量内容是寒暄、语气词、重复确认要过滤掉。同时必须做隐私脱敏姓名、电话、地址等敏感信息一律替换成占位符。第二步改写成指令数据。一条聊天记录往往是多轮对话不能直接拿来做SFT。要把核心问答对抽取出来转成“如果用户说X我们应该回复Y”的结构。建议让业务专家参与这一步因为只有他们知道标准答案之外的策略意图。第三步少量人工校验后做全量精调。用开源框架LLaMA-Factory、Unsloth、Axolotl等对基座模型跑LoRA或QLoRA。LoRA的意义在于你不需要微调全部参数只需要训练一小部分适配器权重显存要求低调完之后的权重文件也不大部署方便。一个容易被忽略的细节是微调后的模型会出现“能力遗忘”现象。模型在业务数据上表现变好的同时通用对话能力、代码能力可能有轻微下降。缓解办法是混合一定比例的通用指令数据再调。我常用的比例是业务数据占八成、通用数据占两成实测保底效果不错。还有一点很难接受但必须接受微调不能凭空给模型增加知识。如果聊天记录里“正确做法”本身有误模型只是把错误背得更熟了而已。数据是决策不是附件。4.3 系统化评测别靠感觉判断模型好坏团队里经常出现这样的场景换了新模型几个人聊了一会儿有人说“感觉这个聪明一点”有人说“我觉得没差别”。这种靠感觉下结论的方式在技术选型时非常危险。系统化评测的意义在于拿客观指标说话。我一般把评测分成两层。第一层是自动化指标先准备一批高频场景测试集跑模型输出用BLEU、ROUGE、回答准确率以及LLM-as-a-Judge用强模型给弱模型打分来评估。第二层是人工抽检自动化指标只能覆盖格式、关键词、一致性这类可计算维度真正的内容合理性、上下文连贯性、业务合规性还得靠人在小样本上做深度评估。评测集的建设需要贴近真实使用场景。我见过太多团队用通用评测集测业务模型得出的结论对实际场景毫无参考价值。正确做法是定期从线上日志里抽一批用户真实问题脱敏后攒成评测集并持续更新。同时把“幻觉率”单独作为一个指标来统计——人工检查模型回答里有没有事实性错误。在业务应用里幻觉率比BLEU这类指标重要得多因为一个漂亮但编造答案的回答造成的信任损失可能是一票否决的。5. 避坑清单从踩坑到形成自己的判断5.1 配置参数与提示词管理的经验系统化地做完几个LLM项目后我积累了一些“常规文档里不写”的经验。温度参数不是越高越有创意。很多人把temperature调到0.8、0.9想换“更有创意”的输出结果换来的是逻辑崩坏。我的建议是知识问答、代码生成、文档总结这类任务用0.1到0.3头脑风暴、文案创作最多调到0.7再高基本失控。你需要创意的时候依靠的是提示词里给模型的“角色设定和约束”而不是简单调温度。提示词模板要用版本管理。不要觉得提示词就是几句自然语言改一下无所谓。实际项目里提示词就是代码它的质量直接影响输出质量。我们把所有提示词文件纳入Git管理修改必须走评审升级必须回归测试。一开始团队觉得“小题大做”直到有一次有人偷偷在系统提示词里加了一句“如果用户不满意可以同意退款”客服系统就真的自己放行了一堆退款请求。结构化输出的路线选择上我的优先级是能用工具调用就用工具调用其次受限解码把希望押在“提示词解析器”上是最后的兜底方案。不要盲目信任“提示词写清楚就能完美输出JSON”迭代过几个项目你会发现用户随便一句话就能把模型带偏。5.2 小模型与大模型的选型建议本地部署时怎么选模型也是一个高频问题。通用口语“小模型省钱、大模型聪明”但要落到具体场景。7B级模型如Qwen2.5-7B、Llama-3.1-8B适合常见问答、文本分类、意图识别、简单的结构化抽取。在CPU上就能跑部署成本低适合个人项目和轻量业务。14B到32B级模型如Qwen2.5-14B、GLM-4-9B适合有一定复杂度的问题包括代码生成、多轮对话、中等难度的推理。需要一块24GB显存的GPU或者足够的内存跑量化版本。这个档位是本地部署里性价比最均衡的。70B及以上适合复杂推理、长文本深度理解、高质量创意生成。需要多张高显存GPU或服务器级配置一般团队没必要自建直接走API反而更划算。我个人对中小团队的建议是能用API就用API需要本地部署时优先7B和14B档位。因为市面上多数业务场景并不需要顶配模型14B量化后在大多数任务上已经能扛住成本却只有70B的十分之一。真正聪明的是把不同难度的任务路由到不同规模的模型而不是一个模型包打天下。5.3 从“会用”到“会判断”的学习路线如果你刚接触LLM想要系统建立自己的判断力我给一条学习路径。先花两周时间熟练使用API。把模型接入自己的代码跑通文本生成、对话、结构化输出这几个基础功能。这个阶段的目标不是做产品而是感受“输入对输出的影响”。第二个月开始做RAG。选一个自己熟悉的文档集比如公司制度文档、产品手册把它变成可问答的知识库。你会深刻体会到检索质量对答案质量的影响也会第一次直面“模型为什么答错了”。第三个月尝试Agent。给模型接上两三个外部工具查天气、查数据库、执行代码让它完成一个多步骤任务。这个阶段你会对“可控性”产生敬畏原来让模型主动做对一件事比让它被动答对一道题难得多。第四个月如果还有精力再考虑微调。从一个小的垂直场景开始收集数据、整理指令集、跑LoRA。微调完之后你会发现数据质量决定模型质量这句话怎么强调都不过分。当你把这几个阶段都走完你对LLM的认知就会从“什么都能干”变成“什么能干好、什么干不好、怎么搭配工具才能干好”。这才是工程上真正有用的判断力。最后说一点个人体会。大语言模型确实是我这些年接触过“上限最高、下限也最不可控”的技术。它的强项在于语言理解和生成它提供的不是一个“稳定的计算引擎”而是一个“概率性的语义引擎”。你用它的正确姿势不是我全都要而是在理解边界的前提下把它的能力嵌入到合适的工程链路里。需要绝对的确定性时就去调用计算器、检索系统、API、数据库。把LLM当大脑而不是当数据库把它当协作者而不是当权威项目踩坑的概率会小很多。这套笔记希望能帮你少走几步弯路。
阅读完成 · 觉得有帮助？
