对话Dify.AI联创延君晨：Ops的实现还未真正到来

整理 | 王轶群

责编 | 唐小引

出品 | GOSIM Foundation

上线36小时，就收获了海量用户及好评，Dify.AI是AI产品界的一个神话。

2023年5 月9 日，Dify.AI正式上线生产环境。尚未来得及小范围公测，只因其创始人在社区平台的一条动态，就引发了大量用户自发传播。在36小时内，Dify.AI上创建的应用数超过1500个，尚未正式开源就收获了超240的开源项目Star及大量用户使用反馈。

（图源：Dify.AI的CSDN博客）

而截至2024年3月29日，不到一年的时间里，Dify.AI云服务上构建了超过13万AI 应用，在 GitHub收获了18.5k Stars, 成为全球排名前三的LLM Infra产品。

GOSIM特意请到了Dify AI的联合创始人延君晨做客对谈，一起来聊一聊Dify.AI的产品设计，并对AI产品的设计逻辑展开探讨。

注：本次采访时间为2023年9月23日，及2023 GOSIM大会举办期间的嘉宾访谈摘录。

敏捷团队，造就敏捷项目

GOSIM：先请延君晨老师介绍一下Dify.AI。

延君晨：Dify.AI其实是一个很年轻的团队。我们是在2023年3月份开始立项做Dify.AI，2023年5月11日发布第一个版本，同时在 GitHub 开源。不到半年的时间，平台公有云服务上累计了7万多个应用，开源版本也部署了超过4万个实例。在构建AI应用的技术栈领域，我们探索了很多方向。

当然，也产生了很多的问题，包括我们自己的产品定位也有一些变化。Dify 最开始定位是LLMOps产品。我们认为随着大模型的普及，很多应用开发者会产生基于大模型的产品运营、数据分析，构建数据飞轮等需求。所以在当时选择这个切入点创业，但在做的过程中发现，以现阶段的大模型技术的成熟度，Ops的需求可能还没有真正到来。

所以，我们在后来在产品迭代中，产品定位逐步演进为一个AI应用技术栈或者应用开发框架。不仅是产品形态的变化，我们本质上还是想让更多的开发者及业务人员能共同参与进来，基于大模型构建出自己想要的产品，去改变公司内部的效率，或是构建出一些激动人心的新形态的应用。

GOSIM：给我们介绍一下Dify.AI的团队、团队规模，以及角色分工。

延君晨：Dify是一个很敏捷的团队，我们在一块共事了很长时间。并不是说从2023年我们决定要做这件事才开始招人，我们其实是一个完整成建制的产品研发、设计、运营团队，规模大概不到20个人。大部分同事以前是腾讯云DevOps Coding的团队成员，2022年底，我们也想看看在大模型这个全新领域里可以做些什么。两个产品经理，大概十二三个开发和两三个运营人员，共同组成Dify 的团队。

（Dify.AI联合创始人延君晨）

我们目前还是以技术驱动为主导，所以团队内部每天的工作还是在产品的规划和研发上，其他的一些运营相关的工作做的比较少。所以，上线很快收到好评，海外也有不错的用户基础，这些自然增长对我们而言是比较幸运的事情，对我们来说是一个很大的鼓舞。

我们原本的假设是，启动一个新项目需要付出一定的周期和成本去做增长，现在和我们的预期是有差异的。按照我的理解，Dify处于一个数据结果超出预期、但产品的完成度低于预期的一个阶段。所以我们会尽最大的努力，去把我们构想的产品形态去更好地交付出来，更好地跟我们社区的开发者共创。

GOSIM：Dify.AI最近也非常受到开发者和AI领域专业人士的关注，很大程度就是Dify在非常短的时间内，就实现了一个相对来说比较完善的产品和服务。很多小伙伴非常好奇这是怎么做到的。现在的大家知道这是一个非常老练的、协同度非常高、很有默契的团队，能够抓住目前的机会去上线他们的产品。

AI产品交互：提示词是一个大话题

GOSIM：我们邀请到延君晨老师，其实想开放式地去讨论一下，当前AI产品交互设计的发展方向、AI产品数据飞轮的设计方向，以及这些AI产品未来的产品形态的演进。

首先我们想聊聊提示词，也是我们当前最主流的与大模型以及相关的AI产品的交互方式之一。Prompt目前的这样的一个形态，是一个合理的与大模型、AI产品交互的方式吗？

延君晨：现在的生成式AI应用，确实是需要通过提示词这样的方式，去给大模型提供一些上下文。但在Dify构建的应用中，我们其实是做了一个类似积木拼插的结构。这里有两个问题：第一个问题是如何有效分配上下文空间，第二个问题是设计交互方式；我们就分开来说这两个话题。

第一个问题是上下文分配。我们知道当前上下文是有长度限制的，主流的模型可能是32K，个别模型可能是100K，但无论如何这个空间都是受限的。在这个范围内，要提供给大模型哪些信息？首先会有系统级的提示词，包含对大模型的一些限制，比如不知道的事情要说不；也包含了一些推理的要求，Dify上线的第一个版本中中就实现了RAG Pipeline，所以包含了从向量数据库中召回跟用户本次输入信息有关的一些文本块；还包含了用户的上下文的记忆，比如你是做一个C端应用，有用户跟大模型之前的聊天记录，你需要同时传递给大模型作为memory的一部分。

所以说虽然有32K的空间，但真正留给用户的空间并没有我们想的那么大，这是一个限制。这个限制可能会随着大模型技术做拓展，但拓展理论上来说是有上限的。因为过大的上下文，必然会导致注意力的不集中，间接导致性能下降。所以，32K到100K，可能就是一个现阶段的可行的方案。【24 年也陆续出现了超过 100k 上下文的大模型，所以对于 RAG 、模型推理、流程编排和交互方式都提出了新的要求。】

第二个问题，为用户提供的提示词空间应该是怎样的？这里是大多数C端产品经理可能会忽略一个问题：通过文本或者语音转文本交付给用户，是不是一个很好的交互形式？想象一下，一个从来没有接触过大模型的用户，当他遇到大模型输入的第一个句子是什么？可能是“你好”“你能做什么”这种很简单的话题，或者“你能帮我画个画吗”，或者是对待搜索引擎那样“你知道什么什么吗”。这是我们目前很常见的一种交互形式。

但是这对于需要基于上下文增强或理解的大模型来说，它并不是特别友好。我们试图教育我们的用户应该如何写提示词。这件事情首先成本是非常高的，第二这也不是一个产品经理该做的事情。这不是一个技术演进的应有方向。我们肯定是要机器去理解人，而不是人去理解机器。

提示词的这种交互形式，我认为至少有两个方面可以去优化。第一个方面是在产品设计层面，是不是应该抽象出来一个结构层，就在提示词分配的过程中，再把用户的一些基础信息，比如身份、偏好，作为一个结构，给用户一些比较友好的交互方式，让他来拼凑成一个提示词，这是一种信息结构上的优化。

第二个就是交互形式上或者叫情感提供层面的。现在像C.AI（Character.AI）这样的产品，在全球的流量中占比可能是第二，仅次于ChatGPT，同时留存率非常高。C.AI用户中有很多都是二次元或是年轻人，这意味着我们在设计产品交互的时候，是不是把这种模仿二次元人物的这种对话，或是通过更先进的VR、MR技术，来把大模型能力和现在这种更先进的用户交互做结合。这个也是我们探索的方向。

本质上，我们虽然给大模型的是文字，但是文字如何去编排、如何结构化、如何从用户手里获得，其实是有很多技巧的。我觉得这也是目前产品，尤其是C端产品经理可以去思考的一些角度。B端的话是另外一个话题。

GOSIM：刚刚提到两个方向，一个是可能我们明确用户的角色身份等信息，是不是很像过去说的用户分层，或者根据用户一些背景信息做一些推荐。这一块是会做到前端，还埋在后面？

延君晨：我会这么理解，这里可能会涉及到一些所谓的Agent能力。Agent 本质也是一种提示工程，这是一个非常大的话题，比如怎么让大模型知道用户，在C端产品的构建中，可能是把用户信息作为一个结构化数据封装，在模型上下文空间中的某个环节，通过提示词去调用API，用户的结构化身份信息将作为上下文传递给模型。【2023年11月  OpenAI 推出了 GPTs 和 Assistants API ，为大家提供基于 OpenAI 系列模型探索 AI Agent 的能力，在 OpenAI 的生态中，产生了无限的创意和想象。2024 年 1 月 Dify 也发布了Agent 模式，可以基于所有主流的的 LLMs 作为基础的自然语言理解和推理模型，并提供一系列工具让 LLM 根据需要来调用，解决多步骤的复杂问题场景，帮助开发者构建更具想象力的 GPTs 和 Agent Assistants（智能助手）】

这里面会用到大模型的推理能力。提示词工程是一个挺泛的话题，包含了刚刚说的空间分配、RAG 工程、AI Agent、数据工程、未来也可能涉及到模型微调。聚焦在C端产品上，我觉得一个很重要的方面就是结构化用户的数据，同时给用户一个更符合他价值观的，或者叫千人千面的交互体验会更重要一些。

交互方式优化：别忘了，人像大模型一样有幻觉

GOSIM：有没有让你觉得眼前一亮的这种交互设计或者有不错的使用体验？

延君晨：客观来讲，现阶段大部分的toC的产品交互设计还是挺统一的。基本是文本框，顶多再加上一点多模态。展望未来，我觉得肯定会有更丰富的相互设计。但在现阶段，可能想象空间没有那么大，顶多就是把语音识别做得更好，然后把图片的理解跟识别集成到交互框里最终实现。

可能会像微信那种交互方式，我们可以跟大模型进行多种形式的交流，但需要一些多模态技术。多模态技术也是个子话题，现在多模态大模型很不成熟，里面涉及到怎么在提示词里通过Agent实现任务拆解，把不同模态的模型集成，进行流程工程编排。这才能真正改善用户体验的方式。【吴恩达教授 24 年 3 月提出了“AI Agent Workflow（智能体工作流）”，这一概念应用的正是流程工程的理念，智能体工作流将会大规模推动未来 AI 落地的进展】

GOSIM：就是我们的确没有一个更好的产品形态或者交互形式出现？我觉得最自然的方式不就是对话吗？

延君晨：是对话。但大多数用户其实在使用某个产品的时候，不一定有一个明确的需求。所以他对于需求描述的颗粒度和准确性，其实没有一个明确的概念。我觉得这是一个很好的话题。大多数情况下，就像大模型一样，我们也有幻觉，我们不知道自己不知道。这个时候，我们可以利用大模型的推理能力，这种交互可能不限于单个提示词，而是在最终让大模型去执行任务之前，可以通过多轮的对话拆解到合适的颗粒度，让大模型能充分、无歧义地理解人的意图和语言。

语言存在先天的不足，让我们说话也会有歧义。那么，如何在产品设计过程中，让大模型在执行任务之前确认是否要跟用户进行多轮对话，需要一个回调机制去分析大模型是否获得了所有要素。比如，大模型的任务是预定一个行程，涉及到需求方的角色、家庭、环境、偏好、情感诉求、时间、预算等要素。这些信息要素，有些是通过结构化的函数调用拿到的，有些可能是通过多轮对话拿到的。其中也涉及到系统级提示词，就是我们最开始在编排应用时大模型跟用户交互的规则。所以说，这里也是一个复杂的提示词工程的架构。

GOSIM：多轮对话的确是目前更多AI产品选择的一个方向。去使用模型能力完成你所有的流程，是一个非常make sense的路径。但其实我们的互联网用户在过去的10年中，可能就是和手机界面的交互及屏幕的交互。屏幕的交互是用以菜单按钮，以点击或拖拉以及滑拽这种方式去完成的。

现在有了模型，要求我们就进行交流或者说多轮对话，我觉得Siri做了最早的这样的尝试。Siri也好，小爱同学也好，这些语音交互其实是能看的进程。你觉得它们真的能够去完成一个很复杂的需求吗？我们作为终端用户，真的适应这样的一个交互方式吗？

延君晨：我觉得一个正常的消费者，可能都有这样的体验。就我自己而言，我不认为说我们能一步到位，突然就从我们习惯了这种交互方式跃迁到完全靠自然语言。这其实效率并不高。

举个例子，比如我订一个上海到北京的高铁，假设我不通过人工智能，整个的步骤

应该是5分钟以内的。我为什么一定要去通过人工智能这种方式？一个产品经理万能公式之一：我们设计新产品的时候，一定要考虑它的替换成本，也要考虑价值差。目前大模型以及设计toC、toB的AI产品，会遇到的一个问题就是现在的替换成本还很高，无论是开发成本，还是用户接受的成本，它提供的这种增量价值还没有那么明显。

但是我们想象一个混合模式，比如我依然是用传统的这种交互界面，只不过用户在要点从北京到上海的过程中，旁边有个小助手或者是同时你可以语音说，虽然手工选择了北京到上海，但还需要你帮我提供价格范围、时间段，这些相对复杂的表单选项。

通过语音识别达成的话，这里面可能也涉及到语音识别技术的准确率，还要有模型对用户意图的理解，然后模型最终推给你它认为最优的方案。

Dify.AI的价值观里，涉及到一个词叫互信协作。刚我们说这个话题时，其实已经是把我们一部分工作、一部分的生活交付给人工智能。这个时候我信不信任它？以前Siri大家信不信任？其实不是特别信任，对吧？因为他们项目的交付度并不是很高，鲁棒性很差，通常也没有闭环。

大模型应用还处在一个前沿的技术阶段。我觉得现在是从技术应用点到应用解决方案的过渡期。刚说到的混合模式，现在可能是一个过渡态。我们距离每个人都有一个人工智能助理随时能响应需求的未来还比较远。这可能也涉及到VR技术的成熟，或可穿戴技术如何更轻量化，这是个复杂的话题。

之所以聊这个话题，也是我作为用户所产生的疑问。即使我是一个表达能力很强的人，也不一定能够通过多轮对话的形式来明确表达我的诉求。这不一定会比我的手在可视化界面的操作高效更多。

还有一个点是认识带宽问题。人脑能同时处理的任务组块就是4到7个，我们通过长时间训练，可以把一部分工作固定到一个组块，来提高我们的整体效率。人类没有并发能力。回到大模型上，我觉得有点类似。我们通过语音交互效率不一定特别高，有时候手机界面操作会更快。

但借助工具人们可以释放自己的注意力。一个相对宽松或者开放的环境中，比如我们在聊天的过程中，可以随时跟我给我的助理去说一些话，他可以去记录下来。相当于在这种环境下，我也能够很轻松放松地完成一些任务，而且可以并行，并不占用我自己个人带宽。这跟我拿着手机要完成这个任务的感觉是不一样的。你在工作忙的时候，订机票订了一半，被一个事情打断就去忙别的了，导致机票没有订完。尤其是对于追求效率的人来说，这种高并发性的情况时有发生，那么模型的能力对此是有帮助的。

反馈机制：大模型对于人类最大的价值所在

GOSIM：您自己在个人使用Agent或提示词工程时，有什么小技巧或者觉得比较抓狂的地方吗？

延君晨：就给Dify打打广告吧（笑）。Dify从第一行代码开始就跟大模型

结合非常紧。我们有1/3的代码和超过一半的产品原型都是通过大模型去完成的，甚至是Dify 这个名字也是 GPT 帮忙起的。我们为什么all in在AI这个领域内，是因为我们在做的过程中被大模型的能力深深震撼。【Dify 一词源自 Define + Modify，意指定义并且持续改进你的 AI 应用，它是为你而做的（Do it for you）。Dify.AI 的目标是让开发者（甚至非开发者）可以快速基于大型语言模型搭建出有用的东西，并确保它是可视化、可运营、可改进的。】

在实际工作中，比如我自己平时其实一直是挂在Dify.AI产品里，我会自己在Dify上构建各种各样的小应用，比如专门用来写商务邮件的，我的英文没有那么好，我会专门写好提示词，让它帮我去把我的中文邮件翻译成英文的。比如今天我做演讲之前，会把很多提前准备好的材料，训练好一个演讲大师然后产品会帮我去生成一些金句。还有比如万能学习助手，也使用了刚刚提到的多轮对话的能力。它其实在我们日常工作和生活中帮助非常大。

大模型对于我们个人来说很大的价值是什么？我们很多时候的思考是不全面的。就是我们想学习一个问题，我们很多时候也不知道自己不知道。所以，我们一方面要解决大模型的幻觉，大模型也可以帮我们解决幻觉。这是很优雅的反馈机制。在学习中如果想学得好学得快，拥有一个反馈的环节非常重要，而大模型可以提供这种定制化的千人千面的反馈体验。

那么如何使用提示词？网上可以找到很多万能公式，有很多提示性的模板框架。这些确实都挺好的，但我更建议大家试着去用类似于Dify这种具备了提示词工程架构的工具。因为如果去模仿一些架构，还是要把你要演扮演的角色、所在的领域、回答问题的步骤帮它思考好，或者是给它一些Agent那种思维链，然后给它提供一些样本在上面学习，并要求它输出的格式。

但问题是，你还是只能通过单次跟模型的交互，没有办法让模型认识你、理解你——我们叫模型认知偏差。因为没有办法把用户个人的数据，包括私有的数据或是一些沉淀的知识，让大模型能理解——所以也需要RAG工程。这就需要类似于Dify这样的产品。

第二，你可能没有办法实现系统级固化的提示词，比如实现思维链是需要一些工程方法在的。程序员可以通过写代码去实现，但其中又涉及到多个模型的协作，还要基于不同的模型去写不同的提示词。想调用不同的模型，里面是需要一些抽象的，你需要一些模型跟应用模型提示词的结构。最终我们给模型都是提示词，而这个提示词里面又包含了很多内容结构。用类似于Dify这种开发框架或者提示词工程开发框架，即Prompt IDE，会很大地释放你的效率，同时也能减少模型的一些实施和调用成本。

如果实现我们的需求都是要经过多轮对话，其实可预见的时间的成本以及其他成本是更高的。目前大模型在跟我们的实际应用场景还是有一点距离的，这里也是开发者的机会。

当年iPhone刚出来的时候，有人做一个手电筒的应用，卖1.99美金，这个应用后来就被集成到了iPhone里。但在当时这个产品其实改变了一些开发者生态环境，也为开发者创造一些收益。我们相信未来可能模型厂会解决很多问题，但我们都不做了就等着模型厂来做这个也是不可能的。这个世界的演进变化，底层规律还是先去符合进化论。大家基于自己的数据、情感、价值判断做应用，最终涌现出好的东西。

很多时候，尤其现在做AI产品，功能是一个维度，但这个AI产品的价值观也是一个维度。它代表了一个虚拟的角色，就跟我们做IP一样，这个角色非常符合一些用户的价值观，这些用户就非常愿意跟这个模型的应用角色去交流，去用这个模型的应用产品，那它就有它的独特价值。

GOSIM：其实很多创新它是来自于生态系统里的，我们怎么样去设计一个产品的开放度和开放性，其实能够帮助开放生态里面诞生更多有生命力的应用创新。我们也非常期待未来在更好的模型能力下的创新交互方式出现。

延君晨：这里还有一个话题就是Plug-in（插件、外挂）。Plug-in最近又被提起来了

之前很热，冷一段时间又被提起来。Plug-in 有两个维度。第一个维度是可以把服务封装起来，提供给toC大模型，可以在给用户提供交互的时使用。还有一个维度，是可以通过把模型集成到自己的产品和服务中，让模型能理解识别公司的API，去调用公司原本的产品和服务去完成工作。

这两种集成方式，一个是以模型为中心，一个是以业务为中心或者产品为中心，都是大模型应用演进的方向，是很好的探索方向，对开发者也更有利。这才是开发者应该努力的方向。开发者不应该去天天想搞大模型。

GOSIM：对，没错。其实我们GOSIM本身也是一个开源的开发者平台。希望有外部更多有创造力的小伙伴进来，为开发者生态注入更多生命力，去诞生更多有意思的创新。

我们刚刚聊到反馈机制的设计，我觉得这个的话也是大模型的下半场，是我们现在比较关注的方向。现在我们已经能看到了很多大模型的模型能力、模型效果是很好的。

如何让大模型持续进行迭代，持续发挥出更大的价值？大模型之间如果想要建立更好更快的壁垒，其实也要对反馈机制进行一些好的设计。无论什么样的产品，都要找到自己的数据飞轮，让整个产品的生态能够有机地运转起来。

想问一下Dify.AI在这方面有哪些尝试？目前在一个什么样的进程？你们对于AI产品的数据飞轮是怎样去理解的？

延君晨：我们是一个面向开发者的产品，有自己数据飞轮。但是我觉得分两个话题来讲。首先，就是对开发者而言，我们在这个维度上能提供什么。第二，就是目前从开发者们的角度来说，无论是toB还是toC，在我们平台上可以做什么。

先说第一个话题。Dify最开始的定义是一个LLM Ops产品。那什么叫Ops？在我们的理解中，大家基于大模型构建的产品不可能一上来就是一个满分的产品，甚至可能不及格。我们现在的提示词的编写，跟以前的编程范式是不太一样的，有很多需要调试的工作，涉及到需要有很多测试的环节，需要对数据进行标注，等等。这个过程我们认为它叫Ops。

回到数据这个角度，拿一个toB的场景来说，一家企业想要用一个大模型，首先大模型应该是跟这个行业或者跟企业的数据做强关联，这可能会涉及到一些微调，至少有一些数据的RAG。那企业在没有选择采购大模型之前，微调过程没法发生，就变成了一个叫鸡生蛋蛋生鸡的难题。

所以，我们理想的环境中，我们现在的架构一般RAG在前，微调在后，最终形成一个很好的数据循环。这个企业在投产大模型之前，先通过RAG工程，将企业的数据和大模型进行对接，这样企业可以基于大模型和企业的场景去做一些应用探索实践。

过程中就会产生真实的基于业务场景的用户和大模型的交互的数据，这个数据才是真正有标注价值的。无论是通过人类去标注还是机器去标注，标注出来的数据再拿去微调，固化成一个模型在这个行业里面的能力，形成一个比较好的闭环。Dify想给开发者提供的就是这套框架。只不过是从我们的研发的阶段和市场需求来说，这块能力还没那么完善。如果大家是关注Dify这个项目，会看到我们在未来3个月到半年会逐步在这个方面去强化。

国内大模型百花齐放，开发者大有所为

GOSIM：你有没有在这个行业中看到比较好的反馈机制的设计？

延君晨：从全球的角度来说，Midjourney是最有代表性的。它需要从每次生成那4张图中选择1张你认为好的，你认为符合提示词的，然后进行后面的渲染和生成，这就是一个非常好的反馈过程。

具备这样先天条件的产品，其实是很稀有的。它是从模型到应用，相当于自己全部做的，就拿国内的场景来说，具备这样条件的公司其实是很少的。大家可能都聚焦在自己的模型算力及模型优化、训练上，业务型的公司主要聚焦在业务场景和用户上。其中，我认为应用端比模型更有创新的机会。

国内的大模型生态，即将开始非常惨烈的厮杀。这里面真正活下来的大模型公司可能是本身的造血能力非常强，或者是技术独到能不断地去融资输血，在这里面也会有很多的价值创造的机会。

我认为，在无论是C端产品还是B端产品，这些真正落地的拿模型做应用的公司，应该是百花齐放的，只是我们起步比海外晚。分享一个数据，仅2023年上半年海外所有的这种toC的应用的下载量超过了3亿次，收入超过4亿美金。国内这方面我还没有拿到数据，确实人工智能算法的备案制度是2023年9月份才有，还是一个起步的阶段，对开发者来说也是大有所为的。

注：对话时间为2023年9月，本文发表时延君晨做了数据更新、内容批注和观点补充。