Gemini said动手学大模型第二篇学习总结：从“调参”到“调教”

学习地址https://github.com/Lordog/dive-into-llms/blob/main/README.md第一部分理论与日常开发的“破壁”映射PDF 里讲的四个提示词概念以前我觉得像文科生的文字游戏现在我把它们直接等价到了我的运维和代码逻辑中1. 提示学习 (Prompt Learning)我的“声明式编程”我意识到随着模型参数越来越大到了 70B 这个级别我根本不需要像第一章那样去痛苦地挂 LoRA 补丁微调了。只要用对提示词就能激发它的潜能。写 Prompt 本质上就是在写一种极度高级的“声明式代码”我只定义目标和格式大模型自己去补全中间的计算逻辑。2. 零样本提示 (Zero-shot)靠不住的“裸奔测试”我的理解就是不给任何前置示例直接扔任务。业务映射在做 Agent 开发时我发现绝不能在核心业务链路上使用 Zero-shot。让它“裸考”翻译或者闲聊还可以但如果让它做“提取故障日志 IP 并输出 JSON”它极大概率会漏掉字段或者格式错乱。Zero-shot 只能用来做最基础的能力摸底。3. 少样本提示 (Few-shot)规范 API 输出的“金标准”我的理解在提问前先给它举 2-3 个标准的输入 - 输出例子。业务映射这是我现在写 Agent 的救命稻草当我的 Agent 频繁调用工具Function Calling失败或者吐出的 JSON 格式总是少个括号时我就会在 System Prompt 里硬编码几个标准的示例。示例模板比如当遇到数据库报错时你必须这样输出{tool: query_db, args: {sql: SELECT *...}}感悟大模型本质上是个“接龙高手”。Few-shot 就是给它设定了一个不可违背的接龙模板Schema极大降低了它胡言乱语的概率。4. 思维链 (CoT)Agent (智能体) 的真正灵魂我的理解在 Prompt 里加一句“请一步步思考并给出推导过程”。业务映射这一节解开了我心中最大的疑惑——为什么现在的 Agent比如 ReAct 框架能自己规划任务原来底层全靠 CoTAgent 能实现自主循环思考 - 行动 - 观察本质上就是因为我们在底层 Prompt 里强迫它进行思维链拆解。不让它秒给结论而是逼它把“打草稿”的过程打印出来它的智商逻辑推理能力就能直线上升。第二部分代码实操的降维反思 (README Notebook)第二章的实操代码其实非常薄就是教你怎么配置API_KEY然后拼接一串字符串发给大模型。虽然这部分我不用再练了但我对这套机制有了更深的工程视角从“微调”到“API”的边界分明第一章的微调SFT是在改模型的长期记忆成本极高。第二章的提示词Prompt是在改模型的短期记忆上下文成本极低见效极快。我的架构原则以后在公司落地 AIOps能用 Prompt配合 Few-shot 和 RAG解决的问题绝不去动微调。只有当模型的“语气”或“行业黑话”怎么都纠正不过来时再去用第一章的 LoRA 方案。Prompt 工程其实是个字符串拼接游戏 其实底层的代码逻辑就是我在 Python 里写一大堆的f-string。把用户的实时问题、数据库查出来的背景知识Context、以及我写好的 Few-shot 模板拼接成一个巨大的长文本一股脑塞给大模型的 API。这考验的不是算法能力而是我对业务逻辑的抽象能力。我的第二章全总结如果说第一章是教我“怎么把服务器点亮”那第二章就是教我“怎么写 Shell 脚本去控制系统”。对我这个有 Agent 开发经验的人来说第二章最大的价值是帮我把碎片化的经验理论化了。我以前只知道“这样写它听得懂”现在我知道了“这叫 Few-shot这叫 CoT”。有了这套标准化的黑话体系和底层理论以后我再去调优我的 Agent 故障排查助手时就知道该从哪个维度去修改系统提示词System Prompt了。