Duolingo 最近推出了一种新角色——创意技术专家（creative technologists），旨在弥合设计与工程之间的沟通。这一角色专注于设计优先的方法，要求具备动画优化能力，并能有效与工程师沟通。通过使用 Rive 这一设计工具，创意技术专家能够直接创建应用程序中的互动动画，减少设计与工程之间的反复沟通，从而提升工作效率。 创意技术专家的角色： 该角色结合了设计和工程的技能，能够在设计和最终产品之间缩小差距。 他们的职责包括优化动画资产、编写文档并与工程师沟通设计细节。 Rive 的应用： Rive 是一个用于构建互动运动图形的工具，使得动画师和创意技术专家可以直接创建应用中的动画，而无需复杂的技术规格。 Duolingo 首次使用 Rive 进行奖励动画，并逐步扩展到角色的语音同步等领域。 团队协作与优化： 创意技术专家与动画师和工程师紧密合作，确保动画的设计与实现的有效对接。 他们帮助识别设计约束，优化项目的构建方式，从而减少未来的修改和更新成本。 招聘与技能要求： Duolingo 寻找具备工程和设计背景的人才，特别是有状态机、VFX 和 Unity 等相关经验的人。 理想的候选人应能通过技术测试，并有解决新工具或技术问题的能力。 职业发展与行业趋势： 创意技术专家的角色在行业中逐渐兴起，未来可能会有更多类似的职位出现，以满足设计与工程之间的需求。 Duolingo 计划在即将到来的 Duocon 会议上宣布更多基于 Rive 的项目，展示其在互动学习体验中的应用潜力。 Duolingo 创造了一个新的角色，连接设计师和开发人员 Duolingo 最近引入了一个介于设计和工程之间的新角色。这个角色专注于 设计优先的方式，他们正在寻找能够与动画师一起优化设计并将这些优化传达给工程师的人。他们称之为 Creative Technologist。 Creative Technologist 负责弥合设计师和开发人员之间的鸿沟，也就是我们常说的“交接”。他们既有技术背景又有设计眼光，是左右脑兼备的人才。他们受雇时会特别要求成为 Rive 的专家。 为什么选择 Rive？ Rive 是一个可以创建运行时交互动态图形的设计工具。Duolingo 的首位 Creative Technologist Jeff Masters 解释道：“以前，动画师会提供一个模型，并附上技术规范，说明如何用代码实现他们的想法。但现在，Rive 让我们的动画师和 Creative Technologist 可以直接创建应用程序中使用的实际素材，不再需要反复与工程师沟通外观问题。在 Rive 中，设计就是最终产品。” 动画副创意总监 Alex Chopjian 的设计和技术能力让他们的 CEO 希望有更多这样的动画师。他说：“在 Rive 中，设计与最终产品之间的差距非常小。你可以直接在浏览器中看到动画效果，而完全不需要接触代码。”...

LLM 知识图谱构建器是 Neo4j 提供的一款创新工具，旨在将非结构化数据转化为动态知识图谱，支持生成式 AI 应用。该工具集成了检索增强生成（RAG）聊天机器人，使用户能够通过自然语言查询数据并获得可解释的洞察。用户无需编写代码，即可通过简单的步骤实现数据的提取与可视化，极大地简化了知识图谱的构建过程。 工具介绍： LLM 知识图谱构建器可将 PDF、网页和 YouTube 视频等非结构化文本转化为知识图谱。 该应用基于 React 前端和 Python FastAPI 后端，使用 Neo4j 的图形能力进行图谱构建。 使用步骤： 数据摄取：支持多种数据源，如 PDF、维基百科页面和 YouTube 视频。 实体识别：利用 LLM 识别和提取文本中的实体及其关系。 图谱构建：将识别的实体和关系转化为图格式。 用户界面：提供直观的网页界面，方便用户上传数据源、可视化生成的图谱，并与 RAG 代理互动。 创建知识图谱： 用户可通过拖放文件或输入链接来上传数据，系统将自动识别和处理。 提供预定义的图谱模式选项，用户可根据需求选择或自定义模式。 探索与互动： 生成的知识图谱以节点和边的形式展现，便于高效存储和查询复杂数据网络。 用户可通过 RAG 代理询问与数据相关的问题，系统将根据存储的图谱信息提供回答。 LLM 知识图谱构建器：从零到 GraphRAG 只需五分钟 使用 LLM 知识图谱构建器，在你的生成式 AI (GenAI) 应用中提取和使用知识图谱。 LLM 知识图谱构建器 是 Neo4j 的 GraphRAG 生态系统工具之一，帮助你将非结构化数据转化为动态知识图谱。它集成了检索增强生成 (RAG) 聊天机器人，支持自然语言查询，并提供数据的可解释见解。 什么是 Neo4j LLM 知识图谱构建器？ Neo4j LLM 知识图谱构建器是一款创新的在线应用，无需编写代码和 Cypher 查询，即可将非结构化文本转化为知识图谱，提供神奇的文本到图谱体验。 它使用机器学习模型 (大语言模型：OpenAI、Gemini、Diffbot) 将 PDF、网页和 YouTube 视频转换为实体及其关系的知识图谱。...

本文主要介绍了Perplexity 的产品开发之路。Perplexity 是一家成立不到两年的公司，迅速崛起为一个受欢迎的搜索产品，用户数量已达数千万，并且年收入超过 2000 万美元。公司采用“AI 优先”的方法，通过利用人工智能来优化产品开发流程，减少协调成本，提升团队效率。Perplexity 的团队结构扁平，通常由小团队（两到三人）组成，强调自驱动和灵活性，预计未来技术型产品经理将成为公司最重要的人才。 公司背景：Perplexity 在短时间内取得了显著的成就，最近融资 6300 万美元，估值超过 10 亿美元。其投资者包括 Nvidia、Jeff Bezos 等知名人士。 AI 优先策略：公司在构建产品的每一步都依赖 AI，鼓励员工在询问同事之前先向 AI 提问，以提高工作效率。 团队结构：大多数项目由两到三人完成，只有两个全职产品经理，强调小团队的高效运作。 决策与管理：公司采取去中心化的决策方式，鼓励团队成员自主做出快速决策，减少管理层级，提升响应速度。 灵活的工作流程：Perplexity 的项目管理依赖于灵活的季度计划和稳定的周目标设定，团队成员在每周开始时设定优先级目标，并努力完成 75% 的目标。 工具与协作：使用 Notion 进行文档管理和项目规划，利用 Unwrap.ai 整理和量化用户反馈，促进团队协作和信息透明。 未来展望：预计随着 AI 技术的发展，技术型产品经理和具备产品品味的工程师将变得更加重要，团队将继续保持扁平化结构以应对快速变化的市场需求。 Perplexity 的产品开发之路 不到两年前成立的 Perplexity 已成为我日常使用的产品，甚至取代了许多 Google 搜索——我并不孤单。这家员工不足 50 人的公司，用户数量已达到数千万。他们还实现了超过 2000 万美元的年度经常性收入 (ARR)，在搜索引擎领域与 Google 和 OpenAI 一较高下。最近筹集的 6300 万美元 使公司的估值超过 10 亿美元，投资者包括 Nvidia、Jeff Bezos、Andrej Karpathy、Garry Tan、Dylan Field、Elad Gil、Nat Friedman、Daniel Gross 和 Naval Ravikant (可惜没有我 😭)。Nvidia 的 CEO Jensen Huang 说他“几乎每天”都在使用这款产品。...

Mark Zuckerberg 认为开放源代码的人工智能（AI）是未来发展的关键。他将开放源代码与早期的 Unix 操作系统进行比较，指出 Linux 的成功是因为其开放性和可修改性。Zuckerberg 预见，开放源代码的 AI 将在未来发展得更快、更安全，并且能够满足不同组织的需求。他强调 Meta 正在积极推动开放源代码 AI 的标准化，特别是通过推出 Llama 3.1 系列模型，以便更广泛地支持开发者和企业。 开放源代码的优势： 开放源代码允许开发者根据自身需求训练和调整模型，避免被锁定在封闭的供应商生态中。 组织可以在本地运行模型，保护敏感数据，提升安全性。 Llama 3.1 405B 模型的运行成本约为封闭模型（如 GPT-4o）的 50%，使其在经济性上具有竞争力。 Meta 的战略： Meta 通过开放源代码 AI 确保技术的可获取性，避免被竞争对手的封闭生态系统限制。 开放源代码的 Llama 模型将促进生态系统的发展，包括与 Amazon、Databricks 和 Nvidia 等公司的合作。 开放源代码对世界的影响： 开放源代码 AI 可以更广泛地分配技术利益，减少权力集中在少数公司手中。 Zuckerberg 认为开放源代码的透明性使其在安全性上优于封闭模型f，能够更好地应对潜在的意图和非意图的危害。 未来展望： Meta 计划通过构建内部团队和合作伙伴关系，推动 Llama 模型的广泛应用，期望在行业内引发开放源代码 AI 的广泛使用。 Zuckerberg 强调，开放源代码 AI 是促进经济机会和安全的最佳途径，呼吁大家共同参与这一进程。 开源 AI 是未来的发展方向 在高性能计算的早期，主要的科技公司都大力投资开发各自的封闭源代码版本的 Unix。当时很难想象有其他方法能开发出如此先进的软件。然而，后来开源的 Linux 逐渐受到欢迎——最初是因为它允许开发者随意修改代码且成本更低，随着时间的推移，它变得更加先进、安全，并拥有更广泛的生态系统，支持的功能比任何封闭的 Unix 都要多。今天，Linux 已成为云计算和大多数移动设备操作系统的行业标准基础——我们都因此受益，享受到更优质的产品。 我相信 AI 将以类似的方式发展。今天，几家科技公司正在开发领先的封闭模型，但开源正在迅速缩小差距。去年，Llama 2 仅相当于前沿后面的一代模型。今年，Llama 3 已经能够与最先进的模型竞争，并在某些领域中表现出色。从明年开始，我们预计未来的 Llama 模型将成为行业中最先进的模型。但即使在此之前，Llama 已经在开放性、可修改性和成本效益方面处于领先地位。...

本文探讨了通过“少量示例提示”（few-shot prompting）来提高大型语言模型（LLM）在调用工具时的性能。研究表明，少量示例提示能够显著提升模型在多种任务上的表现。通过一系列实验，作者分析了不同提示构造方式对模型性能的影响，发现选择合适的示例和格式化方式是提高性能的关键。 实验设置 研究使用了两个数据集进行实验：Query Analysis 和 Multiverse Math。Query Analysis 测试模型如何基于用户问题选择搜索索引，而 Multiverse Math 则考察模型在更复杂的多次调用场景中的表现。 少量示例提示技术 实验中采用了多种少量示例提示技术，包括零-shot、静态和动态消息等方式。结果表明，动态选择的示例通常优于静态示例，且使用消息格式的表现优于字符串格式。 性能评估 通过检查工具调用的召回率和参数的匹配程度来评估模型的表现。实验结果显示，少量示例提示普遍提高了模型的准确性，尤其是 Claude 模型的表现提升显著。 关键发现 使用少量相关示例（如 3 个）可以与使用更多示例（如 9 个）达到相似的效果，显示出示例数量的边际效益递减。此外，小型模型在使用少量示例时，表现能够与大型模型相媲美。 未来研究方向 文章提出了未来的研究问题，包括负面示例的效果、最佳的示例检索方法以及在复杂任务中如何选择示例等，鼓励开发者探索更多优化 LLM 性能的可能性。 少样本提示提高工具调用效率 工具是大语言模型 (LLM) 应用的重要组成部分，我们一直在努力改进 LangChain 的工具接口（参见我们关于 标准化工具调用 和 核心工具改进 的文章）。 我们还在研究如何 提升 LLM 工具调用的性能。一种常见的方法是使用 少样本提示，即在提示中加入示例输入和期望输出。研究表明，少样本提示能显著提升模型在多种任务中的表现。 构建少样本提示的方法很多，但缺乏最佳实践。我们进行了几次实验，探讨不同技术如何影响模型和任务的性能，愿意与大家分享我们的结果。 实验 我们在两个数据集上进行了实验。第一个数据集是 Query Analysis，这是一个标准场景，模型根据用户问题调用不同的搜索索引。第二个数据集是 Multiverse Math，测试在更智能化的 ReAct 工作流程中进行函数调用（涉及对 LLM 的多次调用）。我们对多个 OpenAI 和 Anthropic 模型进行了基准测试，尝试用不同方法提供少样本示例，以找到最佳方案。 查询分析 第二个数据集要求模型选择调用哪个搜索索引。为了正确查询数据源，模型需要一些领域知识并细致理解各数据源的内容类型。问题设计得非常复杂，以挑战模型的工具选择能力。 示例数据点 question: What are best practices for setting up a document loader for a RAG chain?...

本文探讨了“精益创业法”（Lean Startup Method）的优缺点，强调了在创业过程中进行实验的重要性，同时指出该方法在某些方面可能导致创业者的误导。作者认为，创业教育可以通过结合科学方法和最新研究成果，帮助创业者更成功地启动和发展他们的企业。 精益创业法的核心理念： 由 Steve Blank 和 Eric Ries 提出的精益创业法强调行动导向，鼓励创业者通过“商业模式画布”识别商业假设，并快速构建最小可行产品（MVP）进行测试。 创业者需根据反馈不断调整产品和市场，直到实现产品与市场的契合。 实验的重要性： 意大利学者的研究表明，采用科学方法进行系统性实验的创业团队表现更佳，能够更有效地进行调整并实现更高的收入。 精益创业法的局限性： 强调快速与客户沟通可能导致创业者过于关注短期反馈，而忽视了创新产品的潜在市场需求。 “商业模式画布”虽然有助于了解客户，但未能引导创业者思考其独特的商业假设，可能掩盖了创业想法的真正价值。 改进建议： 引用 Joshua Gans 等人的研究，建议创业者在进行实验之前先制定战略，明确为何自己的公司能够成功，从而更有效地进行实验和获取突破性见解。 结合科学方法和最新的学术研究，能够帮助创业者更成功地推出基于证据的创业项目。 精益创业方法的优点与不足 当别人知道我是创业学教授时，他们往往会让我听听他们的创业计划，或者疑惑地说：“创业不是应该即兴发挥吗？怎么还能教呢？”因此，我听了很多创业计划（去年是区块链，今年是CBD），但我也在思考如何回答一个更大的问题：我们能教给创业者什么，让他们的创业更成功？幸运的是，过去十年我从两个不同的来源学到了很多宝贵的经验。 第一个来源是由Steve Blank和Eric Ries开创的精益创业方法（Lean Startup Method），这方法在六年前由Blank在哈佛商业评论中详细介绍。简而言之，精益创业方法提出，成功创业的关键在于偏向行动。创始人应首先使用商业模式画布（Business Model Canvas）来理解其业务背后的假设，这需要他们填写九个涵盖“价值主张”和“客户细分”等主题的方框。然后，他们将关键问题转化为可测试的假设，快速且廉价地构建最小可行产品（MVP）来测试这些假设。如果测试证明假设正确，那就继续；否则，他们应调整方向，根据反馈修改产品或市场，直到找到产品与市场的最佳匹配，证明产品有市场需求。 精益创业方法在硅谷一经推出便大受欢迎，初创企业纷纷接受这种新的实验精神。这种方法也相对容易教授，因此成为各地创业加速器和创业课程的常见内容。但精益创业并不是过去十年中唯一的重大变化，另一个较为低调的革命也在进行。学者们凭借更好的数据、更复杂的分析技术和新方法，开始破解创业成功的密码。传统的智慧正在接受检验。（创业公司是否总是需要联合创始人？年轻人是否更适合做创始人？）我们已经开始对精益创业方法有了一些重要的认识。 首先，好消息是！证据强烈表明，初创企业应按照精益创业方法所倡导的方式进行实验。一组意大利学者进行了一项黄金标准的随机对照实验，研究了116家初创企业。半数企业学习了如何对他们的创业想法进行严格的实验，生成假设并系统地测试它们。另一半企业虽然也学习了实验方法，但没有被教导如何使用科学方法生成假设。像科学家一样行动的那组企业表现得更好——转向更多，避免了问题，最终产生了比对照组更高的收入。严格的实验显然对初创企业的成功至关重要。 然而，其他研究表明，精益创业方法的某些方面实际上可能是有害的。在一篇新论文中，一组著名的创业学者指出了这种方法的两个主要问题： 精益创业鼓励创始人“走出办公室”并尽快与客户交谈。但正如Steve Jobs所说：“知道自己想要什么不是客户的工作。”对快速从客户那里获取反馈的关注，使初创企业倾向于追求渐进式改进，关注客户今天的需求，而不是展望未来。此外，许多研究（例如Clay Christensen关于颠覆性创新的研究）表明，新颖性常常最初不受客户欢迎。如果你的想法是突破性的，而不是一个容易解释的渐进式产品，那么寻求早期客户的外部验证会更加困难。 这个问题被商业模式画布所加剧。虽然画布所问的问题很有用——你应该知道你的客户是谁！——但它没有问最重要的问题：基于你的独特知识和信念，你对世界的假设是什么？填写画布的九个方框反而让你专注于创业过程结束时的样子——当你有了复杂的渠道和供应商关系等等——但在精益创业方法中没有达到这一最终状态的路线图。此外，画布的详细业务要素掩盖了使你的想法与众不同的真正见解。看看LinkedIn完成的众多画布示例，你会发现其中没有一个展示出使公司成功的关于网络和简历的特殊见解。为了生成关于你的创业为何独特的理论，你应该回到科学方法。从观察世界开始，利用你的观察生成理论，思考如何通过你的创业想法改变世界。 那么，如何保留精益创业的优点而不保留其缺点呢？去年HBR的一篇文章提供了一条路径。Joshua Gans、Erin L. Scott和Scott Stern从企业战略研究中汲取灵感，提出了一种新的、更有效的创业实验方法。他们提供了一种以战略为起点的方法——一个关于你公司为何会成功的理论——并根据创始人的选择，建议进行合适的实验。通过将关键的突破性见解的开发权还给创始人而不是客户，这种方法有潜力成为精益创业的下一步进化。 有了这些新工具和证据，我们真的可以教人们启动更成功的基于证据的初创企业。这些初创企业不仅仅是像精益创业方法那样收集证据，还基于最新的学术证据，来提高创业者的成功率。

每个人都有犯错的时候，无论是谁，这都是很常见的现象，也许是世界上最常见的错误。 对于聪明的工程师来说，一个常见的错误是优化一个不应该存在的东西。为什么会这样呢？因为每个人在高中和大学，在高中和大学里，被训练了一种僵化的思维模式，那就是解题思维，解题一种收敛的逻辑，而非发散的逻辑。你不可能跟教授说你的问题太愚蠢了，那样你就可能被挂科。你必须接受教授的问题，并努力解答。因此，基本上每一个人，都在不知不觉中戴上了一个“精神枷锁”，这就是：竭尽全力的工作，却在优化优化那些根本不应该存在的东西。 为了解决以上问题，我提倡一种严格执行的五步法。 第一步：确保你的需求不那么愚蠢。通常来说，你的需求都十分愚蠢，这无关谁提出来的。如果是聪明人给你的需求和任务往往会更加危险，更有问题。因为，你甚至都不会质疑这些聪明人。 第二步：尽力去除不必要的部分和流程，这一步非常重要。如果你没有偶尔重新添加一些内容，那么说明你删除的还不够彻底。一种常见的误区是：很多流程中添加的部分都是为了以防万一，但实际上，你可以为许多事情做出类似的以防万一的理由。 第三步：简化或优化，注意是第三步，而不是第一步，否则他们就会优化一个根本不存在的东西。 第四步：加快进度。你的行动太慢了，要快速行动，但不要在前三步还没做好的时候就急于加速。 第五步：自动化。 我个人曾多次在这五个步骤上犯错，所以我必须不断提醒自己，这个过程需要反复进行。 Elon Musk 的“五步算法”：一个显著改善几乎所有事情的简单而巧妙的方法 Elon Musk 称之为“算法”，这是他在 Tesla 的内华达和弗里蒙特工厂不懈提高生产能力过程中总结的经验教训的精华。 根据 Walter Isaacson 在他的新书 Elon Musk 中的说法，Musk 在任何生产会议上都有很大的可能性提到这个算法。 “我经常重复这个算法，”Musk 说。“但我认为不断强调它是有帮助的。” 下次当你想在工作或生活中变得更高效时，可以试试 Musk 的算法。只需确保按照顺序完成每一步。(下面斜体部分是从 Isaacson 的书中引用的，引用了 Musk 的话。) 1. 质疑每一个需求。 每一个需求都应该附有提出该需求的人的名字。你永远不应该接受一个来自某个部门的需求，例如“法律部门”或“安全部门”。你需要知道具体是谁提出的需求。然后你应该质疑它，不管这个人多聪明。来自聪明人的需求反而最危险，因为人们不太可能质疑它们。即使是来自我的需求，也要质疑。 然后让这些需求变得不那么愚蠢。 当我接管一家新工厂的生产时，主管们必须在生产线启动前签署质量确认。工作人员经常需要等待五到十分钟才能找到主管 (这也是需要解决的另一个问题；领导者应该在车间，而不是在办公室里)。 为什么会有这个规定？公司 CEO 在一次昂贵的错误之后制定了这个规则。但如果操作员不能被信任判断他们的工作是否符合质量标准，他们就不应该 成为 操作员。 许多规定都是基于一次性事件，不需要以流程、指导方针或规则来回应。相反，只需处理特定情况。 从中学习，但不要因为个别事件就制定一成不变的规定。 2. 删除你能删除的任何部分或过程。 你可能需要后来加回来。事实上，如果你没有最终加回至少 10% 的部分，那么你删除得还不够多。 当我第一次成为主管时，我的一项工作是准备、打印并分发一份每日报告给大约 20 人。整个过程花费了一个多小时。有一天，我想知道是否有人实际上读了这份报告，所以我创建了它，但没有打印或分发。 没有人注意到。 所以我停止分发其他一些报告。创建了它们，但没有分发。没有人注意到。 我们经常做事情只是因为我们一直这样做。或者因为我们认为需要这样做。或者因为这是我们的工作，因此它必须很重要。(我们的工作中的每一件事都很重要，对吗？) 3. 简化和优化。 这应该在第二步之后进行。一个常见的错误是简化和优化一个不应该存在的部分或过程。 在我停止分发那些报告的几周后，我问了一些人是否需要我再次分发这些报告。不需要。然后我问我们是否还需要收集相关数据。在大多数情况下，我们不需要，因为它已经在其他地方被收集。(我的部门一直在做重复工作，因为我们认为我们不能信任其他部门把它做对。) 在一些情况下，我们确实偶尔需要某些数据，所以我找到了自动化收集过程的方法。我还找到了一个让生产人员不参与数据收集过程的方法，这意味着他们可以花更多时间生产，而不是充当数据录入员。 正如你马上会看到的，确保你不会自动化或优化一个根本不需要存在的过程。当然，通过使某件事变得更好，你可以取得百分比上的改进，但为什么不通过完全消除不必要的过程来节省 100% 的时间、精力和成本呢？ 4. 加快周期时间。 每个过程都可以加速。但只有在你遵循前三个步骤之后才这样做。在 Tesla 工厂，我错误地花了很多时间加速后来发现应该被删除的过程。...

反思是一种用于提高代理和类似 AI 系统质量与成功率的提示策略。本文概述了如何使用 LangGraph 构建 3 种反思技术，包括 Reflexion 和语言代理树搜索的实现。 关键链接 简单反思： （Python）反思： （Python）语言智能体树搜索： （Python）Youtube反思是一种提示策略，用于提升智能体和类似 AI 系统的质量和成功率。它通过提示大语言模型（LLM）反思和批评其过去的行为，有时还会结合外部信息，如工具观察。 人们常提到“系统1”和“系统2”思维，系统1是反应迅速或本能的，而系统2则更为有条理和反思性。正确应用反思，可以帮助 LLM 系统摆脱纯粹的系统1思维模式，表现出更接近系统2的行为。 反思需要时间！本文中的方法都用了一些额外的计算换取更好的输出质量。虽然这可能不适合低延迟应用，但对于知识密集型任务，响应质量比速度更重要，确实值得这样做。 以下是三个示例： 基本反思 链接： （Python， Youtube） 这个简单示例由两个 LLM 调用组成：一个生成器和一个反思器。生成器尝试直接响应用户请求，反思器则扮演老师角色，对初始响应提供建设性的批评。 循环进行固定次数后，返回最终生成的输出。 简单反思循环 我们可以在 LangGraph 中定义以下循环： from langgraph.graph import MessageGraph builder = MessageGraph() builder.add_node("generate", generation_node) builder.add_node("reflect", reflection_node) builder.set_entry_point("generate") def should_continue(state: List[BaseMessage]): if len(state) > 6: return END return "reflect" builder.add_conditional_edges("generate", should_continue) builder.add_edge("reflect", "generate") graph = builder.compile() MessageGraph 表示一个有状态图，其中“状态”只是一个消息列表。每次调用生成器或反思节点时，它会将一条消息添加到状态的末尾。最终结果由生成器节点返回。 这种简单的反思方式有时可以通过让 LLM 多次尝试改进输出，并让反思节点在批评输出时扮演不同角色，从而提高性能。 然而，由于反思步骤不依赖于任何外部过程，最终结果可能不会显著优于原始结果。我们来探索一些可以改善这一情况的其他技术。 反思 链接：（Python， Youtube）...

本文是 LangChain 官方发布的关于 Agent 的系列文章，这里我将其汇总和翻译了一下 什么是智能体？ “什么是智能体？” 我几乎每天都会被问到这个问题。在 LangChain，我们构建工具来帮助开发人员构建大语言模型 (LLM) 应用程序，尤其是那些作为推理引擎并与外部数据和计算源交互的应用程序。这类系统通常被称为“智能体”。 每个人对智能体的定义似乎都有些不同。我的定义可能比大多数人的更技术化： 智能体是使用 LLM 来决定应用程序控制流的系统。 即便在这里，我也不得不承认我的定义并不完美。人们常常认为智能体是高级的、自主的、类人的——但如果只是一个简单系统，其中大语言模型 (LLM) 在两条路径之间进行选择呢？这虽然符合我的技术定义，但并不符合大家对智能体能力的普遍认知。智能体到底是什么，确实很难准确定义！ 这就是为什么我非常喜欢 Andrew Ng 上周的推文。在推文中，他建议“与其争论哪些工作应该包含或排除为真正的智能体，我们可以承认系统的智能行为有不同的程度。”就像自动驾驶汽车有不同的自动驾驶级别一样，我们也可以将智能体的能力视为一个光谱。我非常同意这个观点，我认为 Andrew 表达得很好。未来，当有人问我什么是智能体时，我会转而讨论什么是“智能行为”。 智能行为是什么意思？ 去年我做了一个关于 LLM 系统的 TED 演讲，并使用下面的幻灯片来讨论 LLM 应用程序中存在的不同自主级别。 一个系统越“智能”，LLM 决定系统行为的程度就越高。 使用 LLM 将输入路由到特定下游工作流具有一定程度的“智能”行为。这会在上图的Router类别中。 如果你使用多个 LLM 进行多个路由步骤？这会介于Router和State Machine之间。 如果其中一个步骤是确定是否继续或结束——有效地允许系统在完成之前循环运行？这会属于State Machine。 如果系统正在构建工具，记住这些工具，然后在未来的步骤中使用它们？这类似于Voyager 论文中实现的，非常智能，属于更高的Autonomous Agent类别。 这些“智能”定义仍然非常技术化。我更喜欢“智能”的技术定义，因为我认为它在设计和描述 LLM 系统时很有用。 为什么“智能”是一个有用的概念？ 与所有概念一样，值得问的是我们为什么需要“智能”这个概念。它有何帮助？ 了解你的系统有多智能可以指导你在开发过程中的决策——包括构建、运行、与之交互、评估甚至监控它。 你的系统越智能，编排框架就越有帮助。如果你正在设计一个复杂的智能系统，拥有一个具有正确抽象概念的框架可以加速开发。这个框架应该对分支逻辑和循环有一流的支持。 你的系统越智能，运行就越困难。它会越来越复杂，某些任务将需要很长时间才能完成。这意味着你会希望将任务作为后台运行。这也意味着你希望有持久的执行能力来处理中途发生的任何错误。 你的系统越智能，你就越希望在运行时与它交互。你会希望能够观察内部发生的情况，因为所采取的确切步骤可能事先未知。你会希望能够在特定时间点修改智能体的状态或指令，如果它偏离了预定路径，可以将其拉回正轨。 你的系统越智能，你就越希望有一个为这些类型的应用程序构建的评估框架。你会希望多次运行评估，因为有大量随机性叠加。你会希望能够不仅测试最终输出，还测试中间步骤，以测试智能体的效率。 你的系统越智能，你就越希望有一个新型的监控框架。你会希望能够深入了解智能体所采取的所有步骤。你还会希望能够根据智能体所采取的步骤查询运行情况。 了解和利用系统中的智能能力光谱可以提高开发过程的效率和健壮性。 智能是新的 我经常思考的一个问题是，在这场热潮中，什么是真正新的。我们是否需要为人们构建的 LLM 应用程序提供新工具和新基础设施？还是以前的通用工具和基础设施就足够了？ 对我来说，你的应用程序越智能，拥有新工具和基础设施就越关键。这正是促使我们构建LangGraph，一个帮助构建、运行和交互智能体的编排器，以及LangSmith，一个用于 LLM 应用程序的测试和可观测性平台。随着我们在智能光谱上不断前进，支持性工具的整个生态系统需要重新构想。 什么是“认知架构”？ 更新：有几位读者指出，“认知架构”这个术语在神经科学和计算认知科学中有丰富的历史。根据维基百科的定义，“认知架构”既指关于人类心智结构的理论，也指这种理论的计算实现。这个定义（以及相关的研究和文章）比我在这里提供的定义更为全面。所以这篇博客应该被视为我在过去一年中构建和帮助构建基于大语言模型 (LLM) 应用程序的经验与这一研究领域的对照。 在过去的六个月里，我经常使用“认知架构”这个短语，而且以后可能会更多地使用。这是我第一次从 Flo Crivello 那里听到的术语——所有的功劳都归于他，我认为这是一个很棒的术语。那么我究竟指的是什么呢？...

学习如何为您的应用程序定制模型。 介绍 微调可以通过以下方式让您更好地利用 API 提供的模型： 比直接使用提示获得更高质量的结果 可以训练比提示中更多的示例 由于提示更简短，节省 Token 请求延迟更低 OpenAI 的文本生成模型已经在大量文本数据上进行了预训练。为了有效使用这些模型，我们通常在提示中包含说明和几个示例。这种通过示例展示任务的方法称为“少样本学习”。 微调通过在提示中包含更多示例来改进少样本学习，从而在许多任务上获得更好的结果。一旦模型经过微调，您不需要在提示中提供那么多示例。 这样可以节省成本并降低请求延迟。 微调一般包括以下步骤： 准备并上传训练数据 训练一个新的微调模型 评估结果，如有需要返回第一步 使用您的微调模型 访问我们的定价页面，了解微调模型训练和使用的费用。 哪些模型可以微调？ GPT-4（gpt-4-0613 和 gpt-4o-*）的微调处于实验性访问计划中，符合条件的用户可以在创建新的微调任务时在微调界面中申请访问。 目前以下模型可以进行微调：gpt-3.5-turbo-0125（推荐），gpt-3.5-turbo-1106，gpt-3.5-turbo-0613，babbage-002，davinci-002，gpt-4-0613（实验性），以及 gpt-4o-2024-05-13。 如果您获得了更多数据且不想重复之前的训练步骤，还可以对一个已经微调的模型进行再次微调。 我们认为gpt-3.5-turbo在结果和易用性方面对于大多数用户来说是最佳选择。 何时使用微调 微调 OpenAI 的文本生成模型可以让它们更适合特定应用，但这需要大量的时间和精力投入。我们建议首先尝试通过提示工程、提示链（将复杂任务分解为多个提示）和函数调用来获得良好结果，主要原因包括： 我们的模型在许多任务上的初始表现可能不佳，但通过正确的提示可以改善结果，因此可能不需要微调 提示迭代和其他策略的反馈循环比微调更快，而微调需要创建数据集并运行训练任务 在需要微调的情况下，初始的提示工程工作不会浪费 - 通常我们会在微调数据中使用良好的提示（或结合提示链和工具使用与微调）时获得最佳效果 我们的提示工程指南提供了不进行微调而提高性能的一些最有效策略和技巧。您可以在我们的playground中快速迭代提示。 常见用例 以下是一些微调可以改善结果的常见用例： 设置风格、语气、格式或其他定性方面 提高生成所需输出的可靠性 纠正未能遵循复杂提示的错误 特定方式处理许多边缘情况 执行在提示中难以表达的新技能或任务 一个高层次的思路是，当“展示”比“说明”更容易时。在接下来的部分中，我们将探讨如何设置微调数据以及微调在基线模型上提升性能的各种示例。 另一个微调的有效场景是通过替换 GPT-4 或使用较短的提示来减少成本和/或延迟，而不牺牲质量。如果您能用 GPT-4 获得良好结果，通常可以通过在 GPT-4 结果上微调gpt-3.5-turbo模型并缩短指令提示，达到类似的质量。 准备您的数据集 一旦您确定微调是正确的解决方案（即您已经优化了提示并发现模型仍有问题），您就需要准备训练模型的数据。您应创建一组多样化的示范对话，这些对话与您在生产中要求模型响应的对话类似。 数据集中的每个示例都应该是与我们的聊天完成 API相同格式的对话，具体来说是一系列消息，每条消息都有一个角色、内容和可选名称。至少一些训练示例应直接针对模型在提示中表现不佳的情况，并且数据中提供的助手消息应是您希望模型给出的理想响应。 示例格式 在这个例子中，我们的目标是创建一个偶尔会给出讽刺回复的聊天机器人，以下是我们可以为数据集创建的三个训练示例（对话）： {"messages": [{"role": "system", "content": "Marv is a factual chatbot that is also sarcastic....