大语言模型的能力与局限：工程避坑与实践指南

最近在给团队做一次内部分享，主题就是“大语言模型的能力和局限”。说实话，准备这堂课时我翻了不少资料，也顺手整理了一份学习笔记。结果越整理越发现，外面铺天盖地的讨论要么把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 从纯文本到多模态，视觉大语言模型带来了什么

如果你以为大语言模型只能处理文字，那就落后了。现在的视觉大语言模型（VLM，Vision-Language Model）已经把“看图说话”整合进来了。典型架构是“视觉编码器 + 语言模型”：先用视觉编码器（比如CLIP、SigLIP这类）把图片转成特征向量，再映射到语言模型的输入空间，让模型能“看懂图”并基于图像内容进行对话。

这类模型在实际项目里非常有用。我之前做一个设备故障检测的辅助系统，传统做法是用一个图像分类模型判断“设备是否异常”，但分类模型只能给出一个标签，给不出解释。换成视觉大语言模型后，操作人员可以直接问：“图片里哪个部件有划痕？严重程度如何？”模型不仅能指出位置，还能给出文字判断依据。这种“可解释性”在工业场景里价值极大。

多模态能力也在快速扩展：文档理解（把PDF、扫描件里的表格提取成结构化数据）、截图转代码（把UI设计图变成HTML）、视频理解（逐帧分析内容并总结）。不过要提醒一句：VLM对“清晰图像”的依赖很高，模糊图片、反光、遮挡严重的图像，它的理解准确率会明显下降。而且VLM同样有幻觉问题——你给它一张根本没有红绿灯的街道照片，它也可能根据“街道场景”的统计先验，描述出一个不存在的红绿灯。这本质上还是“统计规律”在起作用。

1.3 能力全景：一张表看清LLM擅长的场景

为了让自己和团队在项目选型时快速判断“这个任务适不适合用LLM”，我做了一张清单，按成熟度分层：

这张表基本就是我判断“要不要用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 Generation，RAG）的核心思路。

一个典型的RAG流程分四步：

1. 离线阶段：把你的私有文档切分成小块（chunk），每块用embedding模型转成向量，存入向量数据库。
2. 在线查询：用户提问后，把问题也转成向量，在向量库里做相似度检索，取出最相关的若干块。
3. 上下文拼装：把检索到的文档块和用户问题一起组织成提示词。
4. 生成回答：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调用量大，长期费用可观）、离线场景（没有网络环境）。

本地部署的技术栈现在很成熟。模型权重常见的格式是GGUF（GGML 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当大脑而不是当数据库，把它当协作者而不是当权威，项目踩坑的概率会小很多。这套笔记希望能帮你少走几步弯路。