1. 这不是技术名词堆砌，而是一张LLM落地的实操路线图
你有没有过这种感觉：刚看完一篇讲RAG的文章，转身就被同事问“那和函数调用有啥区别”；学完提示词工程，发现上线后效果飘忽不定，用户反馈“它好像懂，又好像完全没听懂”；听说微调很厉害，一查成本清单——GPU小时费、数据清洗人力、验证周期……直接劝退。我去年也卡在这个状态里，手头有个企业知识库问答项目，老板问“到底该用哪个方案”，我翻了二十多篇论文、八份开源文档、三场线上分享，最后在Zhigang Sun教授的ChatAll培训里才真正理清脉络： Prompt Engineering、Function Calling、RAG、Fine-tuning根本不是并列选项，而是同一问题在不同约束条件下的四层解法 。它们像地质断层一样层层叠压——最表层是纯提示词，动动嘴就能试；往下是函数调用，需要你写几行代码把LLM和业务系统连起来；再深是RAG，得搭起向量数据库、做chunk切分、调embedding模型；最底层是微调，要动模型参数本身。这篇文章不讲抽象定义，只说我在三个真实项目里怎么选、怎么踩坑、怎么收口：一个给律所做的合同审查助手（最终选RAG+轻量函数调用），一个给制造厂做的设备故障诊断系统（微调+RAG混合），还有一个给教育机构做的个性化习题生成器（纯提示词+动态模板）。我会把每个方案的决策树拆到螺丝钉级别——比如为什么RAG里我们放弃OpenAI的text-embedding-ada-002，改用BGE-M3？因为客户要求中文法律条文检索时，必须支持“同义替换”和“法条引用链追溯”，而ada-002对“过失致人死亡罪”和“交通肇事罪”的向量距离偏差高达0.42，BGE-M3能压到0.18以下。这些细节，才是决定项目成败的关键。
2. 四层策略的本质：从“借力”到“铸剑”的演进逻辑
2.1 纯提示词工程：用语言当杠杆撬动预训练知识
很多人把提示词当成“咒语”，输入越长越灵验，其实完全反了。我经手的第一个失败案例就是某电商客服机器人——团队写了800字系统提示，要求LLM“扮演资深客服，语气亲切，先共情再解决，引用最新售后政策第3.2条”。上线后90%回复开头都是“亲亲~”，但政策引用错误率高达67%。复盘发现： LLM不是在执行指令，而是在预测下一个token的概率分布 。当提示词过长，模型注意力机制会衰减，关键约束（如“必须引用第3.2条”）被淹没在冗余描述中。真正有效的提示词设计，核心是控制信息熵。举个实操例子：我们给某银行做的信用卡额度查询助手，最终提示词只有三段：
【角色】你是一名严格遵守《商业银行信用卡业务监督管理办法》的智能客服，仅回答与信用卡额度相关的合法合规问题。
【约束】若用户询问“为什么额度被降”，必须引用具体条款：“根据《办法》第三十二条，发卡银行可基于持卡人信用状况变化调整授信额度。”
【输出】仅返回JSON格式：{"reason": "条款原文", "action": "用户可采取的操作"}，禁止任何解释性文字。
为什么这样设计？因为银行场景下， 合规性比流畅度重要十倍 。我们测试过，当把“禁止任何解释性文字”改成“请尽量简洁”，模型开始生成“温馨提示：您可拨打955XX转人工”这类超纲内容。这里的关键认知是：纯提示词的本质是“在不改变模型权重的前提下，用语言规则框定其概率采样空间”。它像给野马套上缰绳，而不是给马换腿。所以适用场景非常明确：需求简单、领域知识已内化于基础模型（如通用法律常识）、结果可验证（如JSON结构化输出）、且允许一定容错率。一旦涉及私有数据、强一致性要求或复杂逻辑链，纯提示词就到了物理极限。
2.2 函数调用：让LLM成为业务系统的“智能调度员”
函数调用常被误解为“给LLM加插件”，实际它是 把确定性逻辑交给代码，把不确定性决策交给模型 。我参与的制造厂设备诊断项目里，最初用纯提示词让LLM分析维修日志，结果模型把“轴承温度异常升高”和“冷却液压力不足”强行关联，而现场工程师确认这是两个独立故障。问题出在：LLM在训练数据里见过太多“温度高→冷却失效”的共现，却没见过这家工厂特有的设备拓扑。解决方案是引入函数调用：我们预置了三个函数—— get_sensor_data(device_id, time_range) 、 check_maintenance_history(device_id) 、 query_part_replacement_records(part_code) 。当用户问“X12产线空压机异响原因”，LLM不再自己编造，而是返回：
{
"function": "get_sensor_data",
"parameters": {"device_id": "X12-AIR-001", "time_range": "last_24h"}
}
系统调用后拿到温度、振动、电流数据，再喂给LLM，它才结合数据判断“振动频谱在12kHz出现尖峰，符合轴承内圈缺陷特征”。这里的关键跃迁在于： 函数调用把LLM从“答案生成者”变成“问题分解者” 。它不需要知道轴承故障原理，只需要学会在什么条件下调用哪个函数。我们统计过，在200次真实工单分析中，LLM调用函数的准确率达92.3%，远高于其直接生成结论的61.7%。但要注意陷阱：函数签名设计必须极度克制。曾有个团队写了 get_device_status(device_id, incl
430
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
