发现 AI 能力已经入侵了微信读书…

今天把一本英文电子书导入到微信读书之后，发现竟然自动生成了双语对照，而且导入速度应该不超过 5 分钟，粗看了生成的效果还挺通顺😁

续费会员理由+1

新一集布莱泽 不多说 直接开香槟🍾🍾🍾

分享今天听到的一句算法与工程跨界的话：

模型的训练是有状态的，推理是无状态的

（私以为可以从这个方向去考虑推理加速的优化方向

新出的这期播客讲了一些确实很 unpopular，但是确实很有启发的一些点，也印证了目前在做 LLM 生成的一些想说却没办法找到知音的一些观点，是嘴替无误了， 一些 takeaways：

1. 看好移动端模型
2. 向量数据库和文本匹配搜索的结论(怎么搜索得好现在还是被低估了)
3. context 上的优化怎么做
4. 构建数据飞轮很重要，这个是AI产品交互上需要考虑的（参考 midjouney）
5. LLM 低代码是伪需求[旺柴] 但我论据上没办法像他这么组织，他有很多逻辑链在分享上没说出来

💻 最近工作上需要，开一个 NL2SQL 的坑，包含论文精读，工期更新等，功能包含但不限于 NL2SQL，也可以 NL2API，即刻作为一个快速记录。

📚 今天是这篇记录耶鲁大学 11 位同学构建 Spider-NL2SQL 测试集的论文，

arxiv.org

🤔 解决什么问题：

1️⃣ 以前的数据集要么重复性强，让模型仅仅需要学习问题与答案的匹配，泛化性很弱

2️⃣ SQL 样本太少，无法有足量的样本覆盖到各种 SQL 关键词，就算是 WikiSQL 数据集，也只充斥了 SELECT 开头的简单语句

Yale-Spider NL2SQL 数据集旨在解决以上的问题，旨在强调 NL2SQL 模型泛化性能力，同时需要胜任更加复杂的 SQL 语句生成任务。为此他们创造了这个数据集作为一个标准的 train-dev-test 数据集。

🐎 本文其实是一篇 NL2SQL 数据集准备的指导论文，有些 takeaways：

1️⃣ 数据准备：数据需要做以下预处理：
1) foreign key 需要表达清楚，表征不同表之间的关系
2) 有些 column 名是缩写的，文中尚需要将其转化为全称，比如要将 stu_id 转化为 student_id
3) 数据集构建就尽量要涵盖所有 SQL 关键词，并且在每个数据库中对每个关键词都要提供足量的例子

2️⃣ 入参要求：将模型对备选数 colunn 的搜索空间控制在同一个数据库（same database）中

3️⃣ 模型评估：模型评估需要解决筛选 column 次序上的问题，如 select, where 中的 column 顺序不一样，作者给了一段将 sql 语句基于关键词分解成 component 的方法可以解决这个问题。并且罗列了其他两种不同的评估方案

4️⃣ train-test split 方法：分为基于 example 粒度划分，和基于 database 粒度划分。前者在 train&test 数据集中会出现不同问题，针对相同一个数据库的情况。后者则保证了测试集中，不会出现训练集中的数据库信息，更加考验模型的泛化能力（因为测试集中的数据库字段模型都没见过）

我们可以针对自己的场景来选择构建我们自身的数据集和训练方案。

最近刚结完婚，一些筹备婚礼的 tip，这个只适用于在饭店吃饭的晚宴类婚礼

1. 摄影摄像不要省，因为我看了都直呼真香
2. 一定要多与策划沟通，增加属于自己的小心机，毕竟一生一次。把代码元素，aigc 元素 融入之后，这是属于我们自己的婚礼啦
3. 门外的迎宾牌尽量极简，增加属于自己的东西最重要，比如照片墙，时间线等，不要搞太复杂。外面的布景不会有太多宾客留意，但会一眼看出属于新人自己的东西
4. 现场场控很重要，一定要联系婚庆公司安排好

最后，我家老婆最美！

尝试了一下 GPT-4 对于诗词的理解能力，并让它给出在 midjourney 中的 prompt，并且直接丢入 midjourney 进行测试（只增加了 ink wash painting 锁定风格）。

发现在给出解释方面较 GPT-3.5 信达雅了更多，并且能基于它的理解来生成对应的图片也更加地应景，几枝这个插件是不是可以考虑重写一个🐶

图 1: GPT3.5 的生成 prompt，看起来没有理解我的问题
图二：用“江南无所有，聊赠一枝春”来测试 GPT-4，用它的第二个 prompt 直接丢进 midjourney
图三：midjourney 生成的结果，图里的人确实挺想跟你分享春天
图四：用“长记曾携手处，千树压，西湖寒碧”来测试 GPT-4，用第一个 prompt 直接丢进 midjourney
图五：midjourney 生成的结果，把曾携手的渺小和孤独画了出来

学习

今天才听到 proof of stake 除了环境友好之外，也是对交易确定性的重塑，从 pow 的基于概率确认，过渡到基于 BFT 的确定性的确认，是对交易实时性要求的一种解决方案。

感谢 BuidlerDAO 有这样宝贵的翻译机会，很棒的一次本土化体验～希望有更多大佬一起进 DAO 交流 😁