hi，各位读者朋友们！
这是《Weekly Copilot》推出的第9期，由 NewinData 与国内最大的 Global SaaS 和科技出海的创业者/企业家社区Linkloud 联名出品，一起为大家带来本周最深刻的科技与商业洞见。
本期为大家推荐以下3篇内容：
Github Copilot 从0到1；
从Dolly模型看sLLM发展；
SaaS 订阅模式vs消费模式；
Let's enjoy！
当GitHub的工程师们与OpenAI的大型语言模型（LLM）首次合作时，他们感到既兴奋又惊讶。GitHub的机器学习高级研究员Alireza Goudarzi回忆道：“作为一个理论AI研究员，我一直在研究深度学习模型，试图理解它们以及它们的学习方式，但这是我第一次真正被一个模型深深震撼。”尽管模型的行为有时让人意外，但它显然非常强大。实际上，它的强大之处足以推动GitHub Copilot的诞生。
考虑到人们对LLM和生成AI模型的兴趣不断增长，他们决定与GitHub的研究人员和工程师进行对话。这些人帮助构建了GitHub Copilot的早期版本，讨论了与不同的OpenAI LLM合作的感受，以及模型的改进如何帮助GitHub Copilot发展到今天的水平，甚至更进一步。
1.1 GitHub Copilot诞生简史
在2020年6月，OpenAI发布了GPT-3，这个语言模型引起了开发者社区和其他领域的浓厚兴趣。在GitHub上，这激发了我们工程师们对一个之前只是谈论的项目的兴趣：代码生成。
GitHub Next团队的主要机器学习工程师 Albert Ziegler 表示大约每 6 个月，公司的会议上总会有人提出是否应该考虑通用代码生成？但答案总是—— “不，这太难了，现有的模型无法做到”；然而，GPT-3 改变了一切，突然之间，这个模型已经变得足够好，可以开始考虑开发一个代码生成工具了；OpenAI 后来给到 Github 测试的 API，工程师们通过给它编程类的任务来进一步评估，并采用了两种不同的评估方式。
第一种评估方式中，GitHub Next团队通过众包一些独立的问题来测试模型，Ziegler 笑着表示他们之所以不再这样做，是因为这些模型变得太好了。一开始，模型能够解决大约一半的问题，但很快就能解决90%以上的问题，这种最初的测试方式激发了他们如何利用这个模型的一系列想法，他们开始构思一个基于人工智能的聊天机器人，开发者可以提出编程问题，并立即收到可运行的代码片段。
Ziegler 和工程师们于是构建了一个原型，但后来发现有更好的使用方式，他们开始尝试将其整合到集成开发环境（IDE）中，这种新的交互式方式几乎在所有情况下都非常有用，于是 GitHub Copilot 的开发也提上了日程。
1.2 探索模型的改进
为了推进这个项目的进展，确保能够跟上最新模型的发展，OpenAI 给到 Ziegle 团队的第一个模型只支持Python，接下来又提供了 JavaScript 模型和一个多语言模型，而他们当时发现 JavaScript 模型有一些问题，而多语言模型却表现出色，且每一次更新模型都变得越来越好，这让 GitHub Copilot 的计划更加有信心。
2021 年，OpenAI 发布了与 GitHub 合作构建的多语言 Codex 模型，这个模型是 GPT-3 的一个分支，最初它可以根据文本提示生成自然语言，但是 Codex 模型的独特之处在于它是在数十亿行的公开代码上进行训练的，这样它不仅可以生成自然语言输出，还可以提供代码建议。
这个模型通过一个 API 提供给企业使用，虽然这对 GitHub Copilot 来说是一个重大突破，但团队还需要在内部对模型进行改进，以确保它对最终用户尽可能准确。
当 GitHub Copilot 准备发布技术预览版本时，Ziegle 的团队组建了更多的功能团队，而模型改进团队则负责通过与底层语言模型的通信来监控和提高 GitHub Copilot 的质量，为了提高用户的完成度，即用户接受并在代码中采纳GitHub Copilot 的建议，模型改进团队采取了各种方法来提高完成度，包括精心设计提示和进行微调。
1.3 Prompt 制定
在使用大型语言模型（LLM）时，用户需要对输入进行精确和有意识的处理，才能得到期望的输出，提示制定是研究如何与这些模型进行最佳交互，以获得最佳的完成结果。
Github 模型改进团队的高级机器学习研究员John Berryman解释说：“简单来说，LLM本质上只是一个文档补全模型。在训练时，它会接收部分文档，并学习如何逐个标记地补全它们。因此，提示制定的艺术实际上就是创建一个‘伪文档’，以引导模型完成对客户有利的任务。”由于LLM是在部分文档补全的基础上进行训练的，如果部分文档是代码，那么这种补全能力就非常适合用于代码补全，这就是GitHub Copilot的基本形式。
为了更好地理解如何将模型应用于代码补全，团队会提供一个文件给模型，并评估它返回的代码补全。
Berryman说：“有时候结果还可以，有时候结果非常好，有时候结果甚至看起来几乎像魔法。关键在于，我们不仅向模型提供GitHub Copilot用户当前正在编辑的原始文件，我们还会寻找IDE中其他上下文信息，以提示模型生成更好的补全。”
他还表示：“有几个变化帮助GitHub Copilot发展到今天的水平，但我最喜欢的一个技巧是，当我们从用户相邻的编辑器标签中提取相似的文本时，我们的接受率和保留字符数量大大提高了。”尽管生成AI和LLM非常引人入胜，但Berryman似乎对用户从研究和工程努力中获得的利益感到最兴奋。
Berryman还表示他们的目标是确保开发者更具生产力，但实现这一目标的方式变得越来越有趣，可以通过将开发者对代码的思考方式融入算法本身来提高用户的生产力；开发者可能会在标签页之间来回切换以查看代码，而团队可以为他们提供这个功能，补全的结果就像用户花了很多时间去查找那些信息一样。
1.4 Fine-tuning 微调
微调是一种在人工智能中用于调整和改进预训练模型以适应特定任务或领域的技术。这个过程首先使用一个在大型数据集上进行过训练的预训练模型，然后在一个较小且更具特定相关性的数据集上进行训练，该数据集与特定的使用场景相关，这样可以使模型学习并适应新数据的微小差异，从而提高其在特定任务上的性能。
由于较大且更复杂的语言模型有时可能产生一些并不一定有帮助的输出，因为很难明确定义什么构成了一个“好”的回应，而训练像 Codex 这样含有1700亿参数的模型也非常具有挑战性。
Goudarzi补充道：“基本上，我们正在对用户特定的代码库进行基础的Codex模型微调，以提供更具针对性和定制化的代码补全。”
此外，他还表示当前面临的最大挑战是考虑用户为何接受或拒绝某个建议，他们必须考虑向模型提供什么样的上下文或信息，以使模型生成有用或无用的内容，虽然无法像典型的工程方式一样排查问题，但可以通过找出如何提出正确的问题来获得我们期望的输出。
1.5 GitHub Copilot 的过去与现在
随着OpenAI模型变得越来越强大，Github 的团队发现可以在LLM基础上开发更多领域的可能性。因此，GitHub Copilot 经过改进，并通过即将推出的 GitHub Copilot X 获得了新的聊天功能和语音辅助开发等新功能。
GitHub Next 团队的资深研究员Johan Rosenkilde回忆到，过去，他们从OpenAI那里获得的最新模型改进明显，但最终用户可能无法真正感受到差异。然而，当 Codex 的第三个版本发布时，可以明显感受到它的强大，尤其是当你使用的编程语言不是五大主流语言之一时。
当时那个模型版本发布的那个周末，Rosenkilde 恰好参加了一个编程比赛，使用的是F#语言，在最初的24小时里，他们显然是在使用GitHub Copilot 的旧模型，但后来——哇！魔法发生了，差异太明显了，简直无法忽视。
最开始，GitHub Copilot 有一个倾向，即在完全不同的编程语言中提供代码行，这显然会降低开发者的体验；Rosenkilde 表示你可能正在进行一个C#项目，然后突然在一个新文件的顶部，它会建议Python代码。
因此，团队在提示的标题部分加上了正在使用的语言，这在深入文件时没有任何影响，因为 Copilot 可以理解你在使用哪种语言，但在文件的顶部，可能会有一些混淆，早期的模型只会默认选择最受欢迎的语言。
大约1个月后，Github 的团队发现在文档的顶部加上文件路径更为有效，在大多数情况下，文件名的末尾会指明语言，事实上，文件名可能提供了重要的额外信息。例如，文件可能被命名为 'connectiondatabase.py'，那么这个文件很可能是关于数据库或连接的，所以你可能想要导入一个SQL库，而且这个文件是用Python写的。
所以，这不仅解决了语言问题，因为GitHub Copilot现在可以提供样板代码，所以它还显著提高了质量和用户体验。经过几个月的努力和多次迭代，Rosenkilde 的团队成功地创建了一个能够从其他文件中提取代码的组件，这是自 GitHub Copilot诞生以来一直在讨论的功能之一，这不仅仅是讨论或草案拉取请求，在后来 Albert Ziegler 开发了组件，用户可以查看在IDE中打开的其他文件，并扫描这些文件中与你当前光标下的文本相似的内容，这对于提高代码接受率来说是一个巨大的推动力，因为GitHub Copilot 突然了解了其他文件的内容。
OpenAI的ChatGPT是一个大规模语言模型，它具有惊人的能力。这种模型通过对数十亿、甚至数万亿的文本样本进行训练来实现。ChatGPT的设计理念是在短时间内预测下一个可能的词语，以此来深度理解语言。为了实现这个目标，需要大量的训练、计算资源和开发者的专业技能。
然而，未来的语言模型可能更专注于特定领域，而不是像OpenAI这样的机构所开发的全方位模型。如果每个行业甚至每个公司都有自己的模型，用于理解行业术语、语言和运营方式，那么我们可能会得到更少的完全捏造的答案，因为答案将来自于更为有限的词语和短语。
在以人工智能驱动的未来，每家公司自身的数据可能成为最有价值的资产。举例来说，如果你是一家保险公司，你的词汇表将与医院、汽车公司或律师事务所完全不同。当你将这些词汇与客户数据和组织内的所有内容结合起来时，你就拥有了一个语言模型。虽然这个模型可能不是很大，至少不像真正的大规模语言模型那么庞大，但它将是为你定制的模型，而不是为大众打造的模型。
为了让这些较小的大规模语言模型（sLLM）能够理解和应用数据，需要一套工具来收集、整合和持续更新公司的数据集。
构建这些模型可能会面临挑战。它们可能会利用开源或私人公司现有的大规模语言模型，然后微调以更专注于特定行业或公司的数据，这些过程都在比通用语言模型更安全的环境中进行。
对于创业社区来说，这是一个巨大的机会，我们已经看到许多公司在这个想法上取得了领先地位。
May Habib 是生成型AI初创公司 Writer 的联合创始人兼CEO。她表示，这正是她的公司试图做的：为每个客户定制模型，以适应他们的词汇和工作方式。她说，她的公司将以“超垂直化”的方式进入市场，这样可以提供更准确和定制的内容。
Habib 表示这涉及一种产品，位于基础的Writer产品之下，它基本上将大规模语言模型的丰富信息转化为更专注、更有用的内容，以适应每个单独客户的需求。她说：“我们与客户讨论这个问题的方式就像在大规模语言模型之上有小型语言模型。”
2.1 你好，Dolly
Databricks是一家知名的初创公司，专注于构建云数据湖库。他们最近推出了一个名为Dolly的sLLM，它是基于两年前的一个模型，并以第一只克隆羊的名字命名。他们选择在旧模型的基础上进行构建的原因是，该模型本身产生了大量垃圾信息，如公司的CEO Ali Ghodsi所解释的那样。
Dolly在一个较小、更专注的语料库上进行训练，据公司声称，它提供了更准确、更专注的答案。公司在公布Dolly的博客文章中写道：“Dolly底层的模型只有60亿个参数，相比之下，GPT-3有1750亿个参数，并且已经有2年的历史了。令人惊讶的是，Dolly的效果如此好。这表明像ChatGPT这样的最新模型中的许多质量提升可能归功于更专注的指令执行训练数据，而不是更大或更好调整的基础模型。”
该公司声称这种方法的优点在于，他们仅用三个小时和30美元的成本就训练出了Dolly，而训练ChatGPT可能需要数十万到数百万美元。
你的成本可能会根据你的数据集大小而有所变化，但基本思路是将你的数据输入到Dolly中，让它开始理解你公司特定的数据，并以ChatGPT的方式回答问题，同时保护数据的私密性。
每家公司都有与其组织相关的信息，如客户互动、客户服务、文档以及多年来发布的材料。而ChatGPT并不能完全理解所有这些信息或应对所有这些情况。
通过Dolly，你可以训练模型来理解并专注于你的数据集，你可以保留它，无需共享给其他人。这是你独有的信息，你可以在与行业竞争时利用它，这一点对于保护数据安全性至关重要，正如Ghodsi所说。
这也与Habib对她的客户的看法相同：他们不仅希望从ChatGPT中获得惊喜，还希望AI能够在安全的方式下实际应用于他们的数据。
2.2 我们走向哪里？
随着越来越多的数据可用，创业公司和成熟公司正继续建立工具，重点在于提供信息以供模型使用和不断更新。
思科的安全与合作执行副总裁兼总经理Jeetu Patel认为，未来可能不仅局限于sLLM，但肯定需要将公司的数据输入到某种现有的LLM中。
他说：“每家公司都会有一些基于自定义数据集进行推理的模型，这将给他们带来无法复制的独特优势。但这并不意味着每家公司都需要建立一个大型语言模型。他们需要的是利用已经存在的语言模型。”
他认为未来的趋势是，公司将使用比ChatGPT更具体的模型，并将自己的数据输入其中，这类似于Databricks试图使用Dolly实现的目标。
他说：“我认为区别在于，一些AI模型将是通用的，就像我们看到的ChatGPT，而其他一些将是公司特定的。”
以思科为例，Patel建议，未来你可以与思科的应用程序如WebEx进行交互，只需简单询问，就能得到当天所有会议的总结。作为安全主管，他也明白这种方法必须具备周密的权限设置，但这提供了一个可能的场景，这种应用可以在特定公司的产品和服务上实际发挥作用。
所有这些发展得如此之快，以至于很难准确预测这项技术在明天或下周的发展方向。但有些人认为，要在企业中发挥作用，模型必须足够灵活，能够处理公司专有的数据进行模型训练。如果情况确实如此，未来可能涉及更小型、更专注的模型。
Janelle Teng 是BVP 在旧金山办公室的投资副总裁，主要专注于云软件、基础设施和开发者平台的增长投资，专注于产品策略和产品驱动的增长；近期，Janelle 在其个人博客中更新了《Consumption vs. subscription business models during downturns》这篇文章，主要讲述经济衰退时期，软件的销售模式从过去的永久授权，到基于使用量的订阅模式，再到消费模式。
如何理解订阅模式和消费模式？其实订阅模式和消费模式是两种不同的商业模式，它们在产品或服务的交付方式和用户体验方面存在区别，
1）订阅模式：订阅模式是一种长期合作的商业模式，用户通过支付定期费用，获得对产品或服务的持续访问权。订阅模式通常适用于数字内容、软件、媒体流媒体、云服务等领域；
2）消费模式：消费模式是一种按需购买和使用产品或服务的商业模式。在这种模式下，用户只在需要时购买和使用产品或服务，而不需要长期的订阅关系；
订阅模式适用于需要长期持续访问的产品或服务，它建立了稳定的客户关系。而消费模式则适用于按需购买和使用的产品或服务，强调灵活性和低承诺风险。具体选择哪种模式取决于产品或服务的性质、目标用户和商业策略。
针对 Janelle 所提到的内容，她表示在过去的二十年里，软件企业的经济模式发生了巨大的变化，与云端交付的发展步伐相吻合。从过去的永久授权格式转向了基于单位（如用户席位或使用量）的订阅模式。然而，最近几年出现了另一种演变，即基于消费的模式逐渐崭露头角。
消费模式与订阅模式的一个重要区别在于它采用了基于计量使用的货币化方式。这种"按使用付费"的模式在云计算领域已存在一段时间，特别是在内容分发网络平台（如Akamai和Edgio/Limelight）和云服务提供商（如AWS、Azure和GCP）中非常突出。
然而，最近消费模式在基础设施和面向开发者的软件公司中变得越来越受欢迎。例如，在BVP云指数中的公司如Confluent、Datadog、Digital Ocean、Elastic、Fastly、MongoDB、New Relic、Snowflake和Twilio都采用了基于消费的模式。这一趋势也开始渗透到软件栈的其他层级，例如应用软件公司Autodesk引入了基于使用量计费的选择。
虽然订阅模式仍然是软件领域中更常见的模式，但基于消费的模式具有多种优势，使其对特定类型的企业非常有吸引力。例如，正如 Janelle 和她的同事之前指出的，以产品为导向的增长型公司可能会发现基于使用量计费是推动其市场营销策略的强有力催化剂。
然而，需要权衡消费模式的优势也有一些限制。Janelle 列举了最近Snowflake 发布的2024财年Q1的财报作为案例，尽管公司的主营业务和净利润表现超出了市场预期，但它在过去 2 个季度内第 2 次下调了2024财年的营收增长预期，导致股价在盘后下跌约13%。
Snowflake 指出，消费模式恶化以及未来的不确定性是修订预期的主要原因。这凸显出在经济环境疲软时，基于使用量计费模式存在一些脆弱性。在Janelle的博客文章中，她深入探讨了当前经济衰退期间消费模式和订阅模式的表现，提到了以下几点：
消费模式对终端客户需求的敏感度增加。
预测消费模式变得更加困难。
消费模式对估值产生影响。
3.1 消费模式对终端客户需求的敏感度增加
消费模式的核心原则之一是将定价与实际价值密切对齐，因为客户只支付他们实际使用的部分。这有助于减少未使用的软件容量，提高客户满意度，并增加客户的留存动力。与订阅模式不同，消费模式允许客户在期间内轻松扩大规模，减少了扩张过程中的摩擦和销售努力。根据高盛的研究，在后疫情需求繁荣时期，相对于整个软件行业组合，消费模式公司实现了超额的营收增长。
然而，在经济衰退期间，情况恰恰相反。由于客户可以立即减少使用量以降低支出，消费模式受到影响，这将立即反映在收入上，因为收入确认是根据使用量和时间计算的。相比之下，订阅模式通常按比例确认收入，因此在经济衰退期间，收入更具持久性，因为需求影响在时间上得到分散。例如，在基于用户席位的订阅模式中，即使客户最终减少人数，他们仍然需要在合同期间负责一定数量的预付许可证。减少的影响不会立即显现，但最终会在续约时反映出来。
这张图表可视化了当前经济衰退期间消费模式和订阅模式之间的弹性差异，展示了消费模式对终端客户需求变化更敏感的情况。这种情况往往会对消费模式公司产生更显著的连锁影响，而订阅模式公司则经历较为温和的模式变化。
3.2 预测消费模式更加困难
与订阅模式相比，消费模式允许根据客户需求更灵活地调配资源。然而，这也带来了一个挑战，即预测消费收入变得更加困难，因为它与使用量的波动性相关。
对于消费模式公司的领导者来说，确定未来使用行为的最佳先行指标可能具有挑战性。传统的前瞻性GAAP指标（如账单或剩余履约义务）在消费模式公司中往往不太适用，因为其中一些公司采用后付款方式计费或剩余履约义务覆盖率较低。
许多消费模式公司使用净美元留存率来预测未来的模式，但这是一个非GAAP指标，并非所有软件公司都以标准化的方式披露或计算该指标。
因此，消费模式公司的管理团队有时很难提供准确的预测或引导适当的期望。以Snowflake为例，在其2024财年Q1季度财报电话会议上，首席财务官Mike Scarpelli提到：“在讨论业绩指引之前，我想先讨论一下我们最近观察到的趋势。如我所提到的，自复活节以来，我们看到营收增长的速度比预期慢。与上个季度不同，这主要是由老客户推动的。虽然我们预计情况会逆转，但由于缺乏可预测性和可见度，我们将这些趋势延续到整个年度。”
根据高盛的指出，与订阅模式公司相比，消费模式软件公司在提供业绩指引后对2023财年的收入进行了更显著的下调。例如，从2022年第三季度到第四季度，MongoDB的2023财年预测下调了-4%，Datadog下调了-6%，Snowflake下调了-3%，而高盛覆盖的其他公司的下调幅度为-1%。然而，回顾2022财年的收入表现，高盛指出，尽管消费模式具有较大的波动性，但消费模式公司的业绩略高于市场预期。这或许凸显了在考虑短期和长期使用波动性时的困难，导致消费模式公司的管理团队在业绩指引中更加保守。
3.3 消费模式的估值影响
考虑到消费模式对系统性风险的高度敏感性，投资者对这种模式的估值可能会有一定的周期性。数据表明，在2021年11月的牛市时期，消费模式公司相对于订阅模式公司确实具有溢价。这并不令人意外，因为消费模式公司在繁荣时期能更好地捕捉增长势头。
原本预计，在2022年第一季度的SaaS市场下跌后，这种趋势会完全逆转，因为在经济衰退期间，订阅模式公司在结构上应该表现出更高的弹性和可预测性。然而，当前数据显示，虽然之前的溢价已消失，但消费模式公司与订阅模式公司相比并未被低估。消费模式公司确实经历了更大的估值回调，但其估值回到与订阅模式相当的水平，而不是落后于订阅模式。
这种发现可能是其他因素的结果，这些因素不能仅仅通过定价模型来完全捕捉，例如盈利能力和运营执行等因素。人们还可以认为，投资者理解消费模式固有的权衡，并可能更长期地看待，认识到在复苏时期消费模式的定价优势。可以推断，一旦条件回升，消费模式公司将更快反弹，因为订阅模式在市场上会有一定的滞后，历史先例也证实了这一点。
然而，像任何商业模式一样，消费模式也有其不完美之处。在适当的条件下，这种动态模式可以成为强大的增长加速器。但是，考虑到它更容易受到外部条件的影响，它也可能成为一把双刃剑。在不断变化的市场环境中，经营者和投资者需要仔细权衡和管理与消费模式相关的风险和机会。
