打造能记住你口味的饮食规划 LLM:知识图谱 + LoRA + RAG 完整指南与避坑清单
【免费下载链接】llm-courseCourse to get into Large Language Models (LLMs) with roadmaps and Colab notebooks.项目地址: https://gitcode.com/GitHub_Trending/ll/llm-course
先说个真实场景:一位久坐的上班族想要一份一周减脂餐,问通用对话模型,得到的答案大致是"早餐燕麦加鸡蛋、午餐多蔬菜、晚餐少主食"——听起来都对,但他不吃香菜、晚上十点才能下班做饭、上周体重纹丝不动,方案一条都没接住 🍳。本文介绍的就是"饮食规划 LLM"这条路:围绕个性化饮食推荐,把食物成分数据组织成知识图谱,用检索增强解决知识时效,用 LoRA 轻量微调对齐表达风格,最后用结构化校验兜住安全底线。全文按"问题—方案—选型—动手—验证—踩坑"展开,给出一段可跑的最小原型代码和一份评估阈值表。
为什么通用模型给不出靠谱的方案
问题不在模型"笨",而在四个结构性短板:
- 靠常识凑答案。训练语料里营养类内容杂而不精,模型只能按频率最高的"大众建议"作答,不会按你的数据算账;
- 知识有时效。膳食指南每几年才更新一次,而补充剂研究、低 GI 食物名单这类内容动得很快,模型参数里的快照追不上;
- 无法定量校验。热量缺口、宏量营养素配比是算术题,生成式模型擅长"说"不擅长"算",数字经常前后矛盾;
- 记不住你。单次会话之外,你的忌口、过敏、口味偏好对它来说不存在。
一句话:通用模型是闭卷作答,而饮食推荐更像开卷考试加验算题——它需要一本随问随查的"字典"和一台事后核算的计算器。
一套能跑通的方案长什么样
整个闭环只分三层,四步走(下图来自本项目仓库):
- 进:个人档案(身高体重、偏好、健康状况)与近 7 天生理指标,先做成一段结构化描述;
- 查:拿"食物—营养素—人群—禁忌"的三元组知识图谱做检索,把与本次问题相关的事实和依据条款捞出来;
- 答:基座模型上加 LoRA 适配层(LoRA 是低秩适配,相当于只微调少量附加参数,省显存也省时间),生成候选菜单;
- 验:用规则脚本检查禁忌食物与营养缺口,命中问题就带着原因重生成。
第四步的校验结果还会反过来指导图谱和训练样本的修正,这就是闭环的意义:不靠模型自觉,靠流程兜底。
怎么把领域知识塞进模型:三条路线怎么选
给模型"开卷"有三条路,先给结论,再给理由:
| 路线 | 改什么 | 什么时候选 | 成本 | 上手 |
|---|---|---|---|---|
| 检索增强(RAG,生成前先查资料) | 外挂检索库,模型不动 | 知识常变:食物成分、指南更新 | 最低,纯工程 | ⭐⭐ |
| LoRA 轻量微调 | 只训适配层 | 稳定偏好:回答风格、输出模板 | 中等,需数百到数千条样本 | ⭐⭐⭐ |
| 结构化输出约束 | 锁死输出格式与取值 | 硬校验:JSON 菜单、禁忌枚举 | 低,配一次 schema | ⭐⭐⭐ |
怎么选:先 RAG,再 LoRA,校验层从第一天就加。RAG 当天就能出效果,适合验证方向;微调样本其实可以由 RAG 流水线的输出整理而来,相当于"用系统给自己造教材"。LoRA 只负责把"回答腔调"和"输出格式"这两件相对稳定的事固化下来,别指望它记住新知识——知识放检索库,语气放模型里,分工清楚了返工就少。
最小原型怎么搭:一段代码跑通"检索 + 生成"
下面这段不到二十行,是整条链路的最小骨架:把领域事实写成一张小表,检索出事实,再让模型"照着事实回答" 🧪
# 领域知识以三元组形式存放:(食物, 营养素) 与 (食物, 相克) KG = {("三文鱼", "DHA"): "文献:海鱼omega-3来源", ("茶叶蛋", "鸡蛋"): "传统相克说法(未证实)"} def retrieve(food): hits = [v for (a, b), v in KG.items() if a == food or b == food] return "\n".join(hits) or "未检索到相关事实" prompt = f"""【检索事实】{retrieve('三文鱼')} 【用户】不吃香菜,周预算有限,目标减脂 要求:只依据检索事实回答,定量交给校验层。""" answer = llm_chat(prompt)跑起来后的真实交互大概是这样:
用户:帮我排下周的减脂餐,不吃香菜,晚上十点才到家。 系统:已识别 6 种食材;与你的禁忌比对通过;目标热量约 1600 kcal/天;已生成周计划初稿,周三晚餐需 20 分钟以上备菜,已替换为 10 分钟版本。 用户:把虾去掉,我对虾过敏。 系统:已移除 3 处虾类;替补食材为虾仁→鸡胸,营养覆盖下降约 2%,已用豆腐弥补。
效果的关键不在模型多聪明,而在于"事实来自表,数字来自算,模型只负责串故事"这三句话。
怎么判断推荐到底靠不靠谱
"读起来像"不算数,给四个可硬算的维度:
| 维度 | 定义 | 合理阈值(示意) | 不达标时先查什么 |
|---|---|---|---|
| 营养覆盖率 | 必需营养素被三餐覆盖的比例 | ≥90% | 图谱里该营养素的食物条目是否缺 |
| 热量偏差 | 方案总量对目标的偏离 | ≤10% | 分量表单位是否统一(克/份) |
| 禁忌拦截率 | 规则层成功拦下的违规比例 | 100% | 校验层枚举值是否漏更新 |
| 偏好匹配度 | 避开用户忌口/喜好的命中率 | ≥90% | 偏好解析是否把否定句读反 |
配套做法:固定留 20~30 个测试问题当回归集,每次改图谱或换提示词都跑一遍。这条纪律比任何单次调优都值钱,它能防止"修好了格式、弄丢了安全"这类回退。
哪些坑最容易翻车,分别怎么绕
数据缺失:食物成分表普遍有缺口,整列取均值会扭曲"相对含量"。规避:关键营养素缺失直接标记该条目不可用,不让模型猜。
参数陷阱:微调学习率偏大两三个数量级,通用能力被冲掉,模型变得"懂吃但不会说话"。规避:1e-4 量级起步、训两三个 epoch 就停,训完拿几个通用问题抽查。
定量幻觉:让模型同时算热量和写菜名,两头都不可靠。规避:把计算从生成职责里拆走——数字由代码算好再拼进提示词,或交给校验层兜底。
硬件限制:7B 模型全精度加载约 14 GB 显存,消费级显卡很吃力;4-bit 量化后权重压到 4 GB 上下,GGUF q4 这种格式纯 CPU 也能推理(下图为本仓库的内存对比示意):
知识过时:营养学结论迭代快,灌进权重的知识会慢慢失真。规避:会变的事实只放检索库、按月更新;微调只学格式与语气;每次更新后跑一遍评估回归再上线。
从 0 到 1,路径其实很短
把领域知识放得进去、算得准、查得出问题,这套饮食规划 LLM 就立住了:检索增强管"知道",轻量微调管"像样",结构化校验管"不翻车",三者成本都不高,顺序可以慢慢来。想系统补 RAG、LoRA、量化这几块的完整流程,可以 clone 下面这个仓库,里面有分模块的路线图文档和配套 Colab 示例:
git clone https://gitcode.com/GitHub_Trending/ll/llm-course配套资源:
- llm-course(上方仓库):LLM 学习路线图,含 RAG、微调、量化分模块示例;
- 开源食物成分库:USDA FoodData Central、Open Food Facts,可直接当结构化底座;
- 开源医疗问答数据集:挑几百条做第一轮 LoRA 样本足够;
- 结构约束:Outlines,按 JSON Schema 锁死输出格式;
- 量化部署:GGUF 模型 + llama.cpp,本地跑推理不用云。
【免费下载链接】llm-courseCourse to get into Large Language Models (LLMs) with roadmaps and Colab notebooks.项目地址: https://gitcode.com/GitHub_Trending/ll/llm-course
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考