动手点关注
干货不迷路
随着大模型应用开发热度越来越高，很多工具框架雨后春笋般的出现。随着llama2，chatGLM2等大模型开始许可商用，让更多更多中小厂商和工程师背景的开发者可以参与到这场AI盛宴，生态上下游开发者的规模将会爆发式增长，大模型应用开发进入第二阶段，如何更快，更高效的把大模型应用落地到生产，与现有系统整合或者改造成了聚焦的重点。
在第一阶段，以langchain和llama-index为代表的集成开发框架，能够快速构建一个LLM原型应用，获得了大量开发者的青睐。但它们距离生产仍然还有很大的gap需要跨越，比如它仅是一个python程序，聚焦于大模型任务本身，缺少一些通用性能力，如如何扩展，如何部署，也缺少相关工具配套支持，还有大模型应用通常还需要和传统应用，特别是大数据应用进行整合，那么这些框架里也缺少一体化的能力支持。
如果langchain类比tensorflow这样的框架，那么显然，在此基础上，应该还需要更高阶，更易用的，能力更全面的集成编排工具将应用粘合起来，高效率的工作。 在目前市面上有大量的langchain可视化的工具在尝试做这样的工作，如flowise，langflow等。还有以prompt可视化为起点后来发展为AI app开发工具dify，但它们整体开起来还是工业化程度不高，更聚焦于小的大模型APP开发，缺乏原型到生产的突破性变化。
今天介绍巨头和新生代代表在LLM in Production领域的两款代表性产品，一个是微软Azure提供的大模型应用开发方案，第二是langchain刚刚（7.18）发布的大模型应用开发平台LangSmith。
1）微软llm pipelines
对于AI应用来讲，数据与应用编排和特征与模型工程是核心，配套在其之上需要有相关大数据，云原生等基础设施的配套。工程师可以基于pipeline为骨架，快速搭建一个可变灵活的AI应用。在AI1.0时代这种模式可以说是最佳实践，google，亚马逊，微软等都有自己的pipeline工具，也有一大堆开源产品支撑。到了AI2.0时代，这种实践经验对于有了过去基础的公司来讲，继续沿用这一思路，将能力进行二次扩充，是非常不错的选项。不仅能力上可以复用，开发者习惯也可以保留，原来的AI应用开发者在简单熟悉后就能够进行大模型应用开发。
从架构图上看，微软提供了离线pipeline和异步在线pipeline，在pipeline构件层面增加了诸如OpenAI Service，Cache之类的服务组件及doc拆分等常见任务模版，以及langchain，Semantic Kernel等开发框架的封装。开发者无须关注底层细节，结合自己的业务流程构建pipeline即可。 更多细节：https://learn.microsoft.com/en-us/azure/architecture/guide/ai/language-model-pipelines
2）langsmith
langchain公司提供的一个用于调试、测试、评估和监控LLM应用程序的统一平台。
在其官方发布博客提到这么一句：
langchain开发的初衷是让开发者能够快速的构建一个LLM原型应用，langchain很好的解决了这个问题，可以简单5行代码就能构建一个LLM应用，但是它有一个问题就是，它仍然需要大量工作才能将这个原型变为生产环境应用。而langsmith就是为了减少原型到生产的gap而设计的。 笔者简单了解了一下这个产品，它的设计思路与微软还是有一些区别，算是为了达到可以生产化的另一个条路。由于langchain本身没有微软在1.0时代的积累。它在设计上更加围绕LLM应用本身，是一个相对平台产品的思路来开发。微软则更多倾向于是一个脚手架工具。前者更简单，更单一，而后者更灵活，更强大。 另外，langsmith关注了一个目前大模型的一个投入生产比较棘手的问题，就是大模型prompt的可读性，可调式性以及大模型输出的不稳定干预。目前微软等厂商也提供了guidance，Guardrails等工具库来解决，但集成度不高，有使用门槛。 langsmith团队结合自己的经验及访谈，总结当前LLM应用开发的几个痛点。 1.了解 LLM 调用的最终提示到底是什么（在所有的提示模板格式化之后，这个最终提示可能会很长，而且会被混淆）
2.了解 LLM 调用在每一步（在以任何方式进行后处理或转换之前）返回的具体内容
3.了解调用 LLM（或其他资源）的确切顺序，以及它们是如何串联在一起的
4.跟踪Token使用情况
5.管理成本
6.跟踪（和调试）延迟
7.没有良好的数据集来评估其应用程序
8.没有可用于评估其应用程序的良好指标
9.了解用户如何与产品互动
langsmith围绕这些痛点，提供了从debug，Testing，Evaluating，Monitoring的一整套完成功能支持，并且具有低代码可视化的操作界面，上手门槛比较低。以前来自四个环节介绍来自官方blog：
Debugging
LangSmith 可让您全面了解事件链中每一步的模型输入和输出。这使得团队可以轻松尝试新的链和提示模板，并发现意外结果、错误或延迟问题的来源。我们还将公开延迟和令牌使用情况，这样您就可以确定是哪些调用导致了问题。
Testing
我们看到开发人员要解决的一个主要问题是"如果我更改了这个链/提示，会对我的输出产生什么影响？要回答这个问题，最有效的方法是策划一个你所关心的示例数据集，然后在这个数据集上运行任何更改过的提示/链。首先，LangSmith 可以让您轻松地根据轨迹创建这些数据集，或者上传您手动策划的数据集。然后，您就可以在这些数据集上轻松运行链和提示。
Evaluating
LangSmith 与我们的开源评估模块集无缝集成。这些模块有两种主要的评估类型：启发式和 LLM。启发式评估将使用类似于 regexes 的逻辑来评估答案的正确性。LLM 评估将使用 LLM 进行自我评估。从长远来看，我们非常看好 LLM 辅助评估。这种方法的批评者会说，这种方法概念不清，而且实际成本很高（时间和金钱）。但是，我们已经看到顶级实验室提出了一些非常令人信服的证据，证明这是一种可行的策略。而且，随着我们共同对这些模式（包括私有模式和开源模式）进行改进，以及使用变得更加普遍，我们预计成本将大大降低。
Monitoring
虽然调试、测试和评估可以帮助您从原型到生产，但工作并不会在发货后就停止。开发人员需要积极跟踪性能，并根据反馈优化性能。我们经常看到开发人员依靠 LangSmith 来跟踪应用程序的系统级性能（如延迟和成本）、跟踪模型/链性能（通过将反馈与运行关联起来）、调试问题（深入研究出错的特定运行），并广泛了解用户如何与其应用程序交互以及他们的体验如何。
可以看出，langsmith仍然聚焦于llm应用内部，有点类似于一个机器学习平台，对于一个复合应用来讲，涉及并不多，并且也缺少一些生产部署监控层面的能力支持，它需要搭配其它工具来一起使用，换而言之，微软和langchain整合在一起或许是一个很好的点子。LangSmith 现在处于封闭测试阶段。想要试用可以点此注册：https://smith.langchain.com/
更多参考： https://blog.langchain.dev/announcing-langsmith/
小结：
分工，分层是技术普及，效率提高的前奏，笔者相信，未来这类平台或框架的需求将会爆炸式的增长。web开发时代有spring，云原生时代有k8s，AI时代会有AI时代的工具链支持。这些工具链的成熟也将会真正对于AI及大模型落地带来加速。
对于AI编排框架感兴趣的同学可以联系，一起提高和实践。