用 Lamini 示例仓库跑通 LLM 微调全流程：从 Llama3 生成到 Memory Tuning

Lamini 的示例仓库是一套按难度递进排列的 LLM 工程练习集，目标不是展示某个单点 API，而是把「构建一个属于自己的语言模型」拆成若干可独立运行的模块：文本生成、质量评估、提示词调优、检索增强调优、数据管道、记忆微调，以及结构化输出与聊天机器人两个扩展场景。它适合已经会用 Python 调用模型接口、想系统了解 LLM 定制各环节分别做什么的开发者。如果你只是想快速调用一次模型，这个仓库偏重；如果你想搞清楚「微调之前到底该先做哪一步」，它的顺序安排本身就是答案。仓库代码以 Apache 2.0 许可发布，可用于包括商业应用在内的任意用途。站内可先参考 Lamini 工具条目了解平台定位，再按本文顺序动手。

准备工作

账号与 API Key

开始之前需要先在 Lamini 的账户页面获取一个 API Key。这个 Key 是后续所有示例脚本的凭据，缺失时任何模块都无法运行。获取入口在账户设置页，具体路径与配额、计费方式以官网当前信息为准。

写入持久化配置文件

仓库约定从用户主目录下的配置文件读取凭据，因此需要创建 ~/.lamini/configure.yaml，内容形如：

production:
  key: <YOUR-LAMINI-API-KEY>

把尖括号部分替换成上一步拿到的真实 Key。写成文件而不是每次在命令行里传参，好处是后续所有示例脚本无需改动即可共用同一份凭据。注意这个文件里是明文密钥，不要提交进版本库；仓库的 .gitignore 已覆盖常见忽略项，但主目录下的文件本身不在仓库范围内，需要自己保证权限。

安装 Python 依赖

仓库根目录提供了 requirements.txt，在克隆下来的仓库目录中执行：

pip3 install -r ./lamini-examples/requirements.txt

建议在虚拟环境中安装，避免与系统里已有的包版本冲突。依赖装完后，各模块目录下的脚本即可直接运行。

目录结构速览

仓库按主题分目录，每个目录对应一个学习阶段：

01_llama3：用 Llama3 生成文本
02_eval：评估模型输出质量
03_prompt_tuning：提示词调优
04_rag_tuning：检索增强生成（RAG）的检索组件调优
05_data_pipeline：为训练准备数据
06_memory_tuning：在自有数据上做记忆微调
classify、json_output、slackbot、data、scripts、utils：分类、结构化输出、聊天机器人等扩展示例与公共工具

仓库明确建议按顺序学习，因为后面的概念建立在前面的基础上。跳过评估直接做微调，通常会导致无法判断微调是否真的带来了改善。

操作步骤

第一步：用 Llama3 生成文本

从 01_llama3 开始。这一步的目的不是调参，而是先确认凭据、依赖、网络三者都通，能拿到模型返回的文本。运行该目录下的示例脚本，观察输出是否正常。如果这一步报鉴权错误，回到配置文件检查 Key 与缩进；如果报导入错误，说明依赖没有装全。

把这一步当作基线：后面所有「调优」的效果，都是相对这个基线输出而言的。建议把基线输出保存下来，作为评估阶段的对照样本。

第二步：评估输出质量

02_eval 解决的是「怎么知道模型变好了」这个问题。评估模块提供了一套衡量 LLM 输出质量的方法，让你在改动提示词、检索或权重之后，有一个可比较的数值或判断依据，而不是凭感觉。

实际操作上，先准备一批有代表性的输入，跑一遍基线模型得到输出，再用评估脚本打分。后续每做一次改动，重复同样的评估流程，对比分数变化。评估集应当覆盖你真实业务里会遇到的输入类型，否则分数再高也不说明问题。

第三步：提示词调优

03_prompt_tuning 关注的是在不改动模型权重的前提下，通过调整提示词来提升输出质量。这是成本最低的一档优化：先确认提示词已经写到足够好，再考虑更重的方案。

该模块的示例展示了如何组织提示词并观察效果变化。每次只改一个变量，改完立刻回到评估流程打分，避免多个改动叠加后无法归因。

第四步：RAG 调优

04_rag_tuning 处理检索增强生成。RAG 的效果由两部分决定：检索到的内容是否相关，以及模型如何使用检索到的内容。这个模块的重点在检索组件——即如何把外部知识切分、索引并召回，再交给模型生成答案。

如果你的场景需要模型回答训练数据里没有的事实性问题，这一步通常比直接微调更划算：知识更新只需重建索引，不必重新训练。示例代码演示了检索与生成如何衔接，可以在此基础上替换成自己的文档集合。

第五步：数据管道

05_data_pipeline 是为训练准备数据。微调效果的上限很大程度上由数据质量决定，这一步要完成的是把原始数据整理成模型可消费的训练格式。

示例强调简洁与可读，而不是重度优化，因此适合作为理解流程的起点：先跑通「原始数据 → 清洗 → 格式化 → 训练样本」这条链路，再针对自己的数据规模做工程化改造。

第六步：记忆微调

06_memory_tuning 是在自有数据上做记忆微调，把事实性知识嵌入模型，从而提升模型在特定数据上的事实准确率。这是整个序列里最重的一步，也是前面几步都做完之后才应该进入的一步。

判断是否该做记忆微调的标准很直接：如果提示词调优和 RAG 都已经试过、评估分数仍然不达标，且失败集中在「模型不知道这些事实」上，那么微调才有明确收益。反之，如果问题出在指令遵循或格式上，微调未必是对症的方案。

第七步：扩展示例

主线走完后，仓库还提供了几个独立场景：

Meta Llama 记忆微调：把事实嵌入 LLM 并提升在自有数据上的事实准确率，是记忆微调主题的延伸示例。
JSON 输出：按保证的 JSON schema 从 LLM 中抽取结构化结果。适合需要把模型输出直接喂给下游程序的场景。
Slackbot：演示如何创建一个调用 LLM 的 Slack 机器人，把模型能力接到团队日常沟通工具里。

这些示例与主线共享同一套凭据与依赖配置，不需要额外准备环境。

一个完整示例

下面这条最小路径把「生成 → 评估 → 调优 → 再评估」串起来，用于验证整条链路可用。它不涉及训练，但覆盖了日常迭代中最常重复的动作。

1. 确认环境

cat ~/.lamini/configure.yaml

输出中应能看到 production 与 key 两个字段，且 Key 已替换为真实值。

2. 安装依赖

pip3 install -r ./lamini-examples/requirements.txt

3. 跑基线生成

进入 01_llama3 目录，运行其中的示例脚本，记录模型对一组测试输入的原始输出。把这批输出存成文件，作为后续对比的基准。

4. 跑评估

进入 02_eval 目录，用同一组测试输入和上一步保存的基线输出运行评估脚本，得到一个基线分数。

5. 修改提示词后重跑

在 03_prompt_tuning 中调整提示词，用完全相同的测试输入重新生成，再回到评估脚本打分。对比两次分数：只有分数稳定提升，才说明这次提示词改动有效。

6. 决定下一步

如果提示词调优后分数仍不达标，按失败类型分流：知识缺失走 RAG 或记忆微调，格式与指令问题继续打磨提示词。这个判断顺序能避免在错误的环节投入训练成本。

注意事项

按顺序学习：仓库明确建议按目录顺序推进，因为概念层层递进。打乱顺序容易在缺少评估基线的情况下做微调，导致无法判断改动是否有效。
示例重可读性而非性能：这些代码的目标是教学与演示，强调简洁和易读，没有做重度优化。直接用于生产前需要自行做工程化改造。
鼓励 fork 后改造：掌握某个模块后，仓库建议 fork 一份并改造成自己的应用，而不是把示例原样当作成品。
凭据以明文存放：~/.lamini/configure.yaml 中保存的是明文 API Key，注意文件权限，不要复制进任何会被提交或分享的目录。
许可范围：仓库代码采用 Apache 2.0 许可，可用于包括商业应用在内的任意用途；引用或分发时按该许可的要求处理。
易变信息以官网为准：模型版本、可用区域、配额与计费规则都可能调整，动手前请以官网当前信息为准。