Software 2.1

表格基础模型如TabPFN和TabICL不需要进行训练就能执行回归或分类。它们所做的是所谓的上下文学习。过去作为训练数据的东西现在变成了预测时的上下文数据。

本文探讨了上下文数据的概念，并将其与"经典"训练数据进行对比。从训练数据转向上下文数据是否改变了我们的建模方式？它是否实现了某些新功能？

让我们深入探讨。

1、训练 vs 上下文

对于传统机器学习（线性回归、XGBoost、SVM），训练数据塑造模型。特别是对于树模型，这一点非常直观：改变训练数据，你可能会得到一棵不同形状的树。拟合一个线性回归模型，权重（系数）就成为训练数据的函数。

表格基础模型则不同。预训练完成。没有经典的训练步骤。预测通过上下文学习进行。使用TFM预测时，你需要同时提供"训练"数据（即上下文）和测试数据。通过多个步骤，表格单...

ScaleDown的压缩端点由任务专用的小型语言模型（SLM）驱动，这些模型识别上下文中与给定查询相关的部分。本文介绍了我们如何训练这些模型，重点放在数据流水线上，因为大部分工作（和大部分决策）都在这里。

1、任务：抽取式句子选择

我们的压缩模型不生成文本。给定一个查询，它对上下文中的哪些token应该保留、哪些可以丢弃进行分类。这是一个刻意的设计选择：通过完全避免生成，我们消除了幻觉风险并保持推理速度。这帮助我们在保持低延迟和高吞吐量的同时大规模处理长上下文。

模型对每个token的相关性进行评分，我们使用这些token级别的评分来构建上下文中句子级别相对于查询的相关性。我们返回得分最高的句子来形成压缩后的输出。训练方法遵循已建立的模式：使用从已知良好答案派生的监督来学习(query, sentence)对上的相关性函数。...

在2026年，创建数据集、训练本地分类器并将其集成到你的产品中，可能比等待第三方提供商回复一个支持工单还要快。这很了不起。但也很危险，因为速度让你很容易跳过那些真正重要的步骤。

1、公交车站旁训练出的模型

我最近在Apiiro运行了一个大型实验，结果惨败。原因之一是我们的LLM提供商出现了意外的延迟飙升，从0.5秒跳到了将近50秒。这彻底毁了实验，我不得不关闭它。

在等待提供商回复工单的时候，我开始为关键的分类部分开发一个本地TinyBERT模型。我实际上是在回家的公交车上开始构建它的。当我到站时，我已经有了一个3毫秒延迟且准确率很好的工作演示。感觉像是一场巨大的胜利。

接下来的几天我仔细看了之后发现，任务是不平衡的，我们的数据有限，而且我没有正确衡量指标。我尝试了更多模型，但没有太大改善。最终，我们保留了LLM...

作为软件开发者，我们在项目中已经无数次看到这样的场景：规格文档在项目初期写好，讨论了几周，然后悄悄地被冲刺看板、Jira工单和"我们在代码审查时再解决"所掩埋。

最终，代码成为了事实来源，而规格则变成了过时的产物。

现在，AI编程代理开始改变这种模式，一个新的术语正在出现——规格驱动开发（Spec-Driven Development，SDD）。其背后的理念很简单，但对于我们这些习惯了以文件和PR为思考单位的人来说，有一点不太舒服：

规格，而不是代码，应该是我们维护的主要产物。代码是我们从中生成的东西。代码作为事实来源 vs 规格作为事实来源

在本文中，我将介绍什么是规格驱动开发，它如何重塑软件开发生命周期，以及在实践中使用

我的孩子有非常具体的兴趣和信息需求。他会让我找关于金属或信号警报器等狭窄主题的书籍，而大多数时候，这样的书根本不存在。或者即使存在，也不是儿童读物。

所以我构建了一个系统来为他生成这样的书。这一切始于一次ChatGPT的实验。当我验证了对更自动化、更复杂方法的需求后，这个项目演变成了一个使用AI生成整本书的自动化流水线。

在本文中，我将分享：

第一本关于金属的书是如何启动这个项目的为什么直接使用ChatGPT生成不够用我如何使用编程代理来创建第一批书为什么我后来构建了一个专门的图书生成器当前的流水线是...