惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Vercel News
Vercel News
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
雷峰网
雷峰网
有赞技术团队
有赞技术团队
罗磊的独立博客
博客园 - 叶小钗
Jina AI
Jina AI
博客园 - 司徒正美
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
T
Tailwind CSS Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
人人都是产品经理
人人都是产品经理
Apple Machine Learning Research
Apple Machine Learning Research
阮一峰的网络日志
阮一峰的网络日志
Microsoft Security Blog
Microsoft Security Blog
大猫的无限游戏
大猫的无限游戏
量子位
MyScale Blog
MyScale Blog
V
Visual Studio Blog
博客园 - 聂微东
The Cloudflare Blog
Engineering at Meta
Engineering at Meta
小众软件
小众软件
宝玉的分享
宝玉的分享

News Hacker | 极客洞察

Rockstar GTA 6 团队组工会:薪酬透明、灵活工时、反 crunch Framework 12 值不值:可维修 Linux 机对上 Apple Silicon 低价 MacBook 古罗马公寓:日常、城市规划与沉浸式体验 AI时代的专家价值:验证、经验与大学角色 Chad Whitacre 退 tech 转离线:Home Depot、印刷杂志、东正教社区 本地 Git remote:共享、隔离与 GitHub 误解 AI只该做琐事,别替代人情与创作 AISlop:检测 AI 生成代码坏味道的多语言 CLI 英国低价值采购系统:每月零申报的官僚负担 郁金香狂热:泡沫神话与理性争议 用 LLM 写代码,也要让人比模型更累 AI会重演前端“失去的十年”吗? AI 编程提产却压缩思考,工程质量与协作承压 Cloudflare 多 agent AI 代码评审引发成本与流程争议 500K AI电影“戛纳首映”被质疑只是公关噱头 8×H200跑2B模型到3k tok/s,“标准GPU”标题引争议 防水夹克演化:材料回潮、帽兜变迁与AI争议 意大利人与荷兰人教学时共享手势本能 Claude Code 隐藏配置考古:文档滞后、版本易碎与自动执行争议 大众汽车用 client assertion 阻断 Home Assistant 接入 Zot 支持 Claude Opus 4.8,评论聚焦 Claude Code 计费与 harness 神秘 Hy3 LLM 在 OpenRouter 霸榜:便宜、刷量与隐私争议 佛州 Blue Origin New Glenn 静态点火爆炸,堪比 N1 联网汽车监控升级:数据售卖、监管失灵与断网自保 Blue Origin New Glenn静态点火爆炸,发射台损毁恐延一年 住宅建造为何难规模化:地段、法规、偏好与收入 十种基础云:观云分类、光学现象与云计算误会 据称被 Shopify 收购后,Garnix 关停并开源 Bot Company疑借Airbnb私测家务机器人,致房屋受损 Coalton:Common Lisp 上的静态类型 Lisp,讨论集中在上手与类型建模
2MB“人类烹饪”被质疑:样本不全,更像食材搭配库
2026-05-28 · via News Hacker | 极客洞察

🎯 讨论背景

这篇文章和演示来自 Kaikaku(一个伦敦的自动化餐厅与烹饪创业公司),核心是把跨语言菜谱语料做食材标准化,再用一个很小的表示空间去浏览搭配关系。评论里提到它实际只用了 11 个来源,覆盖的语言和菜系并不均衡,但 demo 里确实能用来探索 flavor combinations 和替代食材。讨论因此分成两边:一边质疑“全人类烹饪”这个说法和数据代表性,另一边承认它对 food pairing、ingredient mapping 和 recipe helper 很有用。评论还把它和 The Flavor Bible(食材搭配参考书)、Salt Fat Acid Heat(讲烹饪基本规律的书)以及 Cooking for Engineers(把食谱做成图表的网站)联系起来,说明大家真正关心的是:食谱到底是步骤文本,还是一张可计算的风味与工艺地图。

📌 讨论焦点

标题夸大与样本覆盖不足

很多评论直接指出标题把一个有限语料库包装成了“全人类烹饪”,明显是 clickbait。有人翻论文后发现它其实只用了 11 个来源,英中语料占比极高,很多非洲、阿拉伯、南亚等饮食传统并没有真正覆盖到。还有人强调非英语内容是 AI 翻译过来的,这种做法虽然方便,但很可能放大归类和语义误差。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]

2MB 是否真能装下烹饪知识

一派观点认为烹饪知识并没有标题听起来那么庞大:可食食材大约就几千种,常见技法也不过几百种,所以高密度压缩并非完全不可能。另一派则要求给出真实 benchmark,认为如果模型必须依赖熟练厨师补全关键步骤,那它编码的只是提示和笔记,不是完整的烹饪能力。这个争论的核心不是文件大小,而是模型是否真的覆盖了 technique、ratio、火候和配比。

[来源1] [来源2] [来源3] [来源4] [来源5]

LLM 做菜的实用性与局限

不少人承认 LLM 用在厨房里很强,但前提是提问要够具体:要明确菜系、技巧、目标口味,还要不断追问,避免它把结果“Americanize”。有人分享把 spice rack 拍照上传、把 pantry 存成 memory,再针对某个具体菜式迭代提问,确实能得到比平均 recipe 更好的结果。与此同时,评论也反复指出它会漏掉关键一步、比例或温度,尤其对炸鸡、甜点这类对细节极敏感的菜最容易翻车。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]

风味配对与食材关系图谱

讨论里最受认可的部分,是把食材搭配当成可学习的 pattern,而不是死记菜谱。有人举 tomato 配 beef、glutamate 提鲜、cabbage 与 pickling、以及 fat+acid+salt 这种跨菜系结构,说明很多“好吃”的东西其实有可迁移的规律。也有人提到 shared volatile aroma compounds、嗅觉受体数据库、The Flavor Bible 之类的工具,认为这类知识图谱对未来找新搭配很有价值。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]

食谱可视化与流程图表达

另一条很热的支线是在讨论把 recipe 压成 schematic、flowchart 或 dependency graph。很多人觉得这种形式比长网页更适合厨房场景,能把材料、步骤和依赖关系一次看清,也方便两个人分工准备。反方则指出这种表达常常缺少数量、火候和细微技巧,图上还有不少 crossing edge,复杂菜并不一定更易读。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]

地域、本地化与食材归一化问题

很多细节争论其实落在食材归一化和本地化上,比如 scallion、green onion、long onion 是否应视为同一项,或者 squash、pumpkin 在不同地区到底指什么。评论还指出数据库在区域上很不平衡,South Asia、Africa、Middle East 的代表性不足,而 Japanese、Chinese、Korean 等又被切分成不同 bucket,说明“语言来源”和“菜系覆盖”并不是一回事。更麻烦的是 mango、chili、cheese 这类食材本身就有大量品种和地域差异,统一成一个标签远比标题暗示的复杂。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12]

📚 术语解释

ingredient normalization: 把不同语言、同义词和地区写法映射到统一的食材实体,避免同一种东西被拆成多个标签。

food pairing: 根据共享挥发性香气化合物或化学相似性,推测哪些食材在风味上可能互相兼容。

flavor network: 把食材之间的共现、相似和替代关系组织成图,用来找搭配、替换和新组合。

OPM: Object Process Methodology,一种用对象和过程关系建模工作流的方法,这里被拿来类比食谱结构。

The Flavor Bible: 一本常被引用的食材搭配参考书,用来查找哪些 ingredient 常常能配在一起。