Bolt观点｜当我们说AI应用，我们在说什么
过去的三个月，我们看了100多个AI相关的应用。想和大家分享我们对AI应用建造的一些观点。这些观点只是基于我们今天已有的认知，难免有谬误，仅供参考。
模型
对于应用开发者而言，最重要的是把基础模型能力的进步变成对自己有益的事。在开发应用时，如果大部分时间被用在通过工程方法弥补今天模型的不足，可能应该问一个问题：如果明天模型变强了，我做的工作是否还有意义？这是个很容易被误解的观点。如果不去思考模型更可能会在哪些方向变强，就会得到干什么都没意义的结论。
能力最前沿的模型不会开源，并且会集中在极少数团队中，但开源的模型对绝大多数应用已经足够好，并且还会持续变得更好/更便宜。事实上，400B和以上的模型也没有开源的必要，因为大部分人用不起。应用开发者的一个常见路径会是用云上的模型快速启动，当达到一定规模的时候再考虑迁移到本地的开源或定制模型。
数据
数据是AI永远的核心。大模型在训练过程中见过海量的数据，作为应用开发者，什么样的数据能够成为壁垒？
特有领域的数据：这是个老生常谈。这些数据往往在内容和形式上和大模型训练数据的分布极不相同，最关键的是根据不同场景来选择如何使用这些数据。通常内容本质特别的数据用于微调，形式特别的数据用于对齐，用来确保准确性的数据则用于RAG。
Knowhow数据：比如流程文档，实验的最佳实践等等，这些knowhow在以前需要开发者去消化理解，从而嵌入到应用中去，使得应用达到更好的效果。大模型带来的一个变化是今天这些数据可以直接或间接地被模型消费，不管是直接用来帮助模型规划思考，或是用来生成前面提的特有领域数据。
反馈数据：在应用中尽可能记录各种反馈。这些反馈可以用来继续训练模型或者训练agent。事实上，AI应用团队要在效果上长期建立优势往往取决于能否高效地利用这些反馈数据。
显性反馈：在一些场景里是直接的任务成功与否的结果。在另一些场景里来自用户关于模型输出结果的评价。
隐性反馈：比如用户是否使用模型的输出，或者用户是否继续。在讲故事的场景里继续下去是个正面的反馈，在回答问题的场景里重新提问是个负面的反馈。
中间结果的反馈：如果是一个多步的过程，尽量在中间每一步都寻找一些反馈信息。把问题孤立起来总是更好优化一些。
提示词本身：所有的提示词，模型版本和对应的模型输出都应该被记录和管理起来。AI应用依然遵循应用的一些原则。提示词作为代码的一部分，应该在你的版本管理系统和测试流程中。
人机交互（HMI）
人机交互永远在易用性（效率）和准确性（效果）之间寻找平衡，AI的理解能力大幅提高了这个平衡的上限。几年前输入个人信息需要填一个复杂的表格，今天只需要一张身份证的照片，或者一份标准的简历。这是机器的理解能力带来的交互效率的提升。
AI应用的交互基本原则依然没有变。对任何一个问题，最优的交互方式永远是在满足准确性要求的前提下最简单的方式。
如果能满足准确性的要求，自然语言输入的交互是新时代最有吸引力的输入方式，不光是因为它极低的使用门槛，也因为它打开了许多新设备上的新应用场景。
但回到桌面上，很多时候自然语言的交互可能只是一个补充。有时是因为易用性，语言输入实在太累人了。有时是因为准确性，比如像素级的图像编辑。
很多时候交互的大幅提升本身就能重新定义应用。
模型和应用的交互（AMI）
这是一个新问题，也是个很有意思的问题。应用与模型的交互在很多方面和与人交互有许多相似的地方：最重要的一个相似点是在这个交互中模型是主体，应用软件是客体。因此是应用软件（甚至有时候是整个IT系统）来提供合适的交互适配AI。（通过增强模型本身来使模型获得更强的交互能力是另一个方向，某种意义上类似于人为了更好使用工具而接受的培训。）
与人机交互不同，AMI的主要目标是效果，也就是保证模型输出的效果，在今天可能包括了提升模型解决问题的能力，和确保模型的准确性和稳定性。这个目标有很多可以衡量的客观标准，因此可以被持续优化。
AI和应用的交互从渠道上讲只是prompt。但是涉及很多方面。整体而言和HMI相似，都是给AI数据，什么时候给，给什么数据，用什么形式，不同的选择效果可能差别很大。其实仔细想想，下面的每一条都和跟人的交互很相似。
交互的内容：比如RAG，针对一个问题，给多少上下文最合适？这些问题决定了embedding的拆分，召回等操作的具体原则。
交互的格式：有很多promptengineering的研究讨论这个内容。总的来说，接收到的内容的格式能很大程度影响大模型的表现。模型更喜欢读结构清晰的内容。比如bulletpoints，json，markdown，甚至代码。比如针对稍微复杂的推理问题，用自然语言的描述很可能把模型绕晕，但一段伪代码的表达模型可能就可以清楚理解。当然，很多这些内容清洗的工作本身也可以通过模型来完成。
交互的模态：有时候最合适的输入模态并不是文字。比如对一个拥有视觉模态能力的模型来说，处理一个网页信息抓取的任务最合适的输入方式是把网页的截图直接传给模型，这比把整个页面的HTML代码通过文本输给模型的效果要好得多。
很多时候模型接收的输入实际上来自于外部系统，因此这些外部系统需要有某种适配来为AI提供合适的信息：比如只有通过提供外部API的详细说明，模型才能很好地选择调用这些API。那么通过注释来提供这些详细说明就是外部系统必须为适配AI做的工作。（当然也可以利用设计文档，只是他们很难和API的实际情况保持一致）。今天的很多系统在设计和实现之初都不需要考虑怎么被AI使用，因此未来有很多这样的适配工作需要做，或许这里也有AI应用或是基础设施衍生的机会。
这篇随笔写到这里其实只是零散地覆盖了一小部分有关的话题，还有非常多的问题今后可以继续展开讨论，例如AI在各种已有和未来的设备上和外部世界的交互（但这是个很大的话题，或许以后可以找个机会深入讨论）。最后，这是个技术在飞快进步的时代，每隔几个月我们都会看到一些突破性的变化，使得很多观点需要修正。因此我们也会保持持续思考，也希望更多地在这里和大家分享。
LinearBolt
Bolt是线性资本为早期阶段、面向全球市场AI应用专门设立的投资项目。它秉持线性投资的理念和哲学，专注在技术驱动带来变革的项目，希望帮助创始人找到实现目标的最短路径，不管是行动速度，还是投资方式，Bolt的承诺是更轻，更快，更灵活。