针对当今科技领域发展的前沿指南.PDF

Thoughtworks,Inc.All Rights Reserved.1针对当今科技领域发展的 前沿指南技术雷达2024年4月Volume30 Thoughtworks,Inc.All Rights Reserved.2关于技术雷达 3雷达一览 4贡献者 5本期主题 6本期雷达 8技术 11平台 17工具 24语言和框架 34 Thoughtworks,Inc.All Rights Reserved.3Thoughtworks 技术雷达关于技术雷达Thoughtworker 酷爱技术。我们致力于建造技术，研究技术，测试技术，开源技术，书写技术，并不断改进技术。支持卓越软件并掀起 IT 革命是我们的使命，Thoughtworks 技术雷达就是为了完成这一使命。它由 Thoughtworks 中一群资深技术领导组成的技术顾问委员会，通过定期讨论 Thoughtworks 的全球技术战略以及对行业有重大影响的技术趋势而创建。技术雷达以独特的形式记录技术顾问委员会的讨论结果，从首席技术官到开发人员，雷达将会为各路利益相关方提供价值。这些内容只是简要的总结。我们建议您探索雷达中提到的内容以了解更多细节。技术雷达的本质是图形性质，把各种技术项目归类为技术、工具、平台和语言和框架。如果技术可以被归类到多个象限，我们选择看起来最合适的一个。我们还进一步将这些技术分为四个环以反映我们目前对其的态度。想要了解更多技术雷达相关信息，请点击： Thoughtworks,Inc.All Rights Reserved.4技术雷达是具有前瞻性的。为了给新的技术条目腾出空间，我们挪出了近期没有发生太多变化的技术条目，但略去某项技术并不表示我们不再关心它。暂缓评估试验采纳采纳：我们强烈主张业界采用这些技术。我们会在适当时候将其用于我们的项目。试验：值得追求。重要的是理解如何建立这种能力，企业应该在风险可控的项目中尝试此技术。评估：为了确认它将如何影响你所在的企业，值得作一番探究。暂缓：谨慎推行。新的挪进/挪出没有变化雷达一览技术雷达持续追踪有趣的技术是如何发展的，我们将其称之为条目。在技术雷达中，我们使用象限和环对其进行分类，不同象限代表不同种类的技术，而圆环则代表我们对它作出的成熟度评估。软件领域瞬息万变，我们追踪的技术条目也如此，因此您会发现它们在雷达中的位置也会改变。Thoughtworks 技术雷达 Thoughtworks,Inc.All Rights Reserved.5贡献者技术顾问委员会（TAB）由 Thoughtworks 的 22 名高级技术专家组成。TAB 每年召开两次面对面会议，每两周召开一次视频会议。其主要职责是为 Thoughtworks 的首席技术官 Rachel Laycock 和名誉首席技术官 Rebecca Parsons 提供咨询建议。作为一个综合型组织，TAB 能够审视影响 Thoughtworks 技术战略和技术人员的各种主题。本期技术雷达内容基于 2024 年 2 月技术委员会成员在纽约的面对面会议创建。Rebecca Parsons（CTO Emerita）Camilla Falconi CrispimJames LewisScott ShawRachel Laycock（CTO）Martin Fowler（Chief Scientist）Erik DrnenburgMarisa HoenigSelvakumar NatesanShangqi LiuSofia TaniaVanya SethWill AmaralBharani SubramaniamFausto de la TorreMike MasonMaya OrmazaBirgitta BckelerHao XuNeal FordPawan ShahBrandon Byars Thoughtworks,Inc.All Rights Reserved.6（或许）开源的许可证在我们的会议中，关于许可证引发了两类讨论。首先，多年来，开源软件开发生态系统依赖于一组由开源倡议组织（Open Source Initiative，OSI）编录的许可证，大多数情况下仅使用流行的几种。然而，最近发生了一些变化。一些知名工具，最近因为其维护者突然从开源模式切换到商业模式而受到了一些负面评价。当然，我们愿意为软件付费，并且认可对于额外功能使用商业许可证的常见模式。只是我们觉得，当这种转变出现在一个受众广泛的工具的核心功能上，尤其是当一个生态系统已经围绕该工具发展起来时，这是有问题的。其次，另一个有趣的转变出现在一些自诩开源的软件上，其基本功能只有在消费者支付订阅费或其他费用后才能使用。尽管这种商业模式以前就存在，但似乎在许多闪亮的新 AI 工具中被更多地利用了它们提供了一些在细则之下过于隐藏的惊人功能。我们建议特别关注许可证问题。在使用中要提起警惕，并确保存储库中的所有文件都受到顶层许可证的覆盖。人工智能助力软件开发团队显然，人工智能目前正在讨论中占主导地位：技术雷达中约有三分之一的类目与之相关。我们不仅讨论了面向开发者的人工智能工具，如 GitHub Copilot，CodiumAI，aider 和 Continue，我们还探讨了如何在整个团队中全面使用 AI、以及如何利用人工智能改变软件开发的各个方面。这其中包括一系列最终未能入选的工具，例如Warp 这样的人工智能辅助终端，将截图转换为代码的能力、由 LLMs 支持的 ChatOps 以及许多其他主题。尽管开发人员工具正在发展的日臻成熟，但我们始终对于“软件开发的所有方面都可以从人工智能和相关工具的务实使用中受益”抱有怀疑，我们正在积极跟踪相关领域的创新。与此同时，在人工智能带来近乎神奇的新技能时，相关的质量与安全风险也在涌现，这需要团队保持警惕，包括让非开发人员意识到潜在的风险。本期主题 Thoughtworks,Inc.All Rights Reserved.7涌现的大语言架构模式在技术领域，“模式”因为能够为特定问题提供一个简洁的解决方案名称而受到欢迎。随着大语言模型（LLMs）的日益普及，我们开始看到支持常见上下文的特定架构模式不断涌现。例如，我们讨论了 NeMo Guardrails，它允许开发人员围绕 LLM 的使用建立治理政策。我们还讨论了像 Langfuse 这样的工具，它们能够更好地观察LLM 的输出步骤，并知道如何处理（并验证）充斥着生成代码的臃肿代码库。我们讨论了如何使用检索增强生成（RAG），这是我们偏爱的模式，以提高 LLM 输出的质量，在企业生态系统中尤其有效。此外，我们还讨论了使用低能耗（和成本）大语言模型产生材料，然后由更强大（也更划算）的大语言模型选择性审查的技术。模式为技术构建了一个重要的词汇库，随着生成式 AI 继续渗透软件开发，我们预计会看到模式（以及不可避免的反模式）的爆炸式增长。让 Pull Request（PR）更接近正确的持续集成Thoughtworks 一直推崇在软件开发过程中采用快速反馈循环，因此也是持续集成（CI）的大力支持者。为此，我们在 20 世纪 90 年代末构建并开源了有史以来第一个 CI 服务器 Cruise Control。最近，我们的首席科学家Martin Fowler 在他的 bliki 上更新了对于持续集成的规范定义，以重申对这一实践的关注。然而，我们许多团队被迫忽视 CI/CD 中的 CI 部分，因为他们发现自己处于必须使用 Pull Request（PR）的情况。尽管 PR 的做法最初是为了管理大规模分布式的开源团队和不可靠的贡献者，然而目前已经发展成了同行评审（Peer Review，PR）的同义词，即使在紧密工作的小型团队也是如此。在这些情况下，许多开发者渴望从实践真正的 CI 中获得相同的流畅感。我们调查了几个试图减轻 PR 审查过程痛苦的工具，包括 gitStream 和 Github 合并队列。我们还讨论了诸如 stacked diffs 之类的技术，这些技术通过使集成过程更精细化，有望与 CI 的核心原则保持一致。除此之外，我们还探讨了从 PR 中提取度量的方法，以识别软件交付过程中的低效和瓶颈。工具在这个领域会起到巨大帮助，因为整体趋势是朝向生成式 AI 编程的。随着 AI 编码助手的出现，编码吞吐量增加，导致倾向于创建更大的 PR。这给异步代码审查过程增加了更大的压力。尽管我们仍然更喜欢原始的 CI 实践，但我们鼓励那些由于外部约束而无法使用 CI 的团队寻找方法，从而提高集成准确性和反馈周期速度。Thoughtworks,Inc.All Rights Reserved.8188242930313233343536373839404142432623456791516171011121314444749506566676869707172737475767778798081828351525459535658616263648588899091929394959697989910010110210310486871921222028252723841051454648555760暂缓暂缓评估评估试验试验采纳采纳本期雷达新的挪进/挪出没有变化 Thoughtworks,Inc.All Rights Reserved.采纳1.检索增强生成（RAG）试验2.自动生成 Backstage 实体描述符3.将传统 NLP 与 LLMs 相结合4.持续合规5.边缘函数6.安全标兵7.Text to SQL8.追踪健康债务状况评估9.人工智能团队助理10.对 LLM 对话进行图分析11.基于大语言模型的 ChatOps12.大语言模型驱动的自主代理13.使用 GenAI 理解遗留代码库14.VISS暂缓15.广泛集成测试16.过度热衷使用大语言模型17.急于冲向大语言模型微调（fine-tune LLMs）18.适用于 SSR 网络应用程序的 Web 组件采纳19.CloudEvents试验20.云上 Arm21.Azure Container Apps22.Azure OpenAI Service23.DataHub24.基础设施编排平台25.Pulumi26.Rancher Desktop27.Weights&Biases评估28.Bun29.Chronosphere30.DataOS31.Dify32.Elasticsearch Relevance Engine33.FOCUS34.Gemini Nano35.HyperDX36.IcePanel37.Langfuse38.Qdrant39.RISC-V 用于嵌入式40.Tigerbeetle41.WebTransport42.Zarf43.ZITADEL暂缓 技术平台本期雷达 Thoughtworks,Inc.All Rights Reserved.采纳44.Conan45.Kaniko46.Karpenter试验47.42Crunch API Conformance Scan48.actions-runner-controller49.Android 模拟器容器50.AWS CUDOS51.aws-nuke52.Bruno53.Develocity54.GitHub Copilot55.Gradio56.Gradle Version Catalog57.Maestro58.Microsoft SBOM 工具59.开放策略代理（OPA）60.Philipss self-hosted GitHub runner61.Pop62.Renovate63.Terrascan64.Velero评估65.aider66.Akvorado67.百川 268.Cargo Lambda69.Codium AI70.Continue71.Fern Docs72.Granted73.LinearB74.LLaVA75.Marimo76.Mixtral77.NeMo Guardrails78.Ollama79.OpenTofu80.QAnything81.System Initiative82.Tetragon83.Winglang暂缓 采纳 试验84.Astro85.DataComPy86.Pinia87.Ray评估88.安卓适应性89.Concrete ML90.Crabviz91.Crux92.Databricks Asset Bundles93.Electric94.LiteLLM95.LLaMA-Factory96.MLX97.Mojo98.Otter99.Pkl100.Rust for UI101.vLLM102.Voyager103.WGPU104.Zig暂缓105.LangChain工具语言和框架userid:532115,docid:158800,date:2024-04-10, Thoughtworks,Inc.All Rights Reserved.技术188242930313233343536373839404142432623456791516171011121314444749506566676869707172737475767778798081828351525459535658616263648588899091929394959697989910010110210310486871921222028252723841051454648555760暂缓暂缓评估评估试验试验采纳采纳采纳1.检索增强生成（RAG）试验2.自动生成 Backstage 实体描述符3.将传统 NLP 与 LLMs 相结合4.持续合规5.边缘函数6.安全标兵7.Text to SQL8.追踪健康债务状况评估9.人工智能团队助理10.对 LLM 对话进行图分析11.基于大语言模型的 ChatOps12.大语言模型驱动的自主代理13.使用 GenAI 理解遗留代码库14.VISS暂缓15.广泛集成测试16.过度热衷使用大语言模型17.急于冲向大语言模型微调（fine-tune LLMs）18.适用于 SSR 网络应用程序的 Web 组件新的挪进/挪出没有变化 Thoughtworks,Inc.All Rights Reserved.12技术1.检索增强生成（RAG）采纳检索增强生成（Retrieval-augmented generation，RAG）是我们团队提高大语言模型（LLM）生成响应质量的首选模式。我们已经在包括 Jugalbandi AI Platform 在内的多个项目中成功使用了它。通过 RAG，相关且可信的文档（如 HTML 和 PDF 格式）的信息被存储在支持向量数据类型或高效文档搜索的数据库中，例如 pgvector、Qdrant 或 Elasticsearch Relevance Engine。在收到给定提示后，数据库会被调取以检索相关文档，然后这些文档会与提示结合在一起，为 LLM 提供更丰富的上下文。这样一来输出质量更高，且大大减少了幻觉现象。上下文窗口决定了 LLM 输入的尺寸是有限的，这意味着需要选择最相关的文档。我们会通过重新排序来提升提示内容的相关性。文档如果太大而无法计算嵌入，这意味着它们必须被分割成更小的块。这通常是一个困难的问题，其中一种方法是让这些块在某种程度上重叠。2.自动生成 Backstage 实体描述符试验Spotify 推出的 Backstage 已成为我们客户托管开发者体验门户的首选平台。本身来说，Backstage 只是一个托管插件，在托管的同时提供管理构成平台生态系统资产目录的界面的 shell。任何由 Backstage 显示或管理的实体都在 catalog-info 文件中配置，其中包含状态、生命周期、依赖关系和 API 等其他细节的数据。默认情况下，单个实体描述符是手动编写的，并且通常由负责相应组件的团队进行维护和版本化。保持描述符的更新可能是乏味的，并且会成为开发者采用过程中的障碍。此外，总有可能忽视变更或完全错过某些组件。我们发现 自动生成 Backstage 实体描述符 更有效且不易出错。大多数组织有现有的信息源可以启动填充目录条目的过程。良好的开发实践，例如，在 AWS 资源上放置适当的标签或向源文件添加元数据，可以简化实体发现和描述符生成。这些自动化流程可以定期运行 比如每天一次 以保持目录的新鲜和更新。3.将传统 NLP 与 LLMs 相结合试验大语言模型（LLMs）是自然语言处理（NLP）中的瑞士军刀。但它们往往比较昂贵，且并非总是最合适的-有时候使用一个螺丝刀会更合适。实际上，在 将传统 NLP 与 LLMs 相结合，或者在将多种 NLP 与 LLMs 相结合，以实现用例并利用 LLMs 的实际需求能力的步骤方面有很大的潜力。传统的数据科学和 NLP 方法，例如文档聚类、主题识别和分类，甚至摘要生成，成本更低且可能更有效地解决你的使用案例问题的一部分。然后，在需要生成和总结较长文本，或将多个大型文档合并时，我们使用 LLMs，以利用其较高的注意力跨度和记忆力。例如，我们已经成功地将这些技术结合使用，从一个大型单个趋势文档语料库生成关于某一领域的全面趋势报告，同时结合传统聚类方法和 LLMs 的生成能力。4.持续合规试验持续合规 是一种实践，旨在确保软件开发过程以及相关技术一直遵守行业法规和安全标准，这一过程大量依赖自动化，人工操作可能会降低开发速度并引入错误。作为替代，组织可以自动化合规检查和审计。他们可以将工具集成到软件开发流水线中，使团队能够在开发过程的早期发现并处理合规问题。将合规规则和最佳实践编码化有助于在团队间执行一致的政策和标准。它使用户能够扫描代码变更中的漏洞、强制执行编码标准以及追 Thoughtworks,Inc.All Rights Reserved.13踪基础设施配置变更，以确保它们满足合规要求。最后，以上内容的自动化报告简化了审计工作，并提供了清晰的合规证据。我们已经讨论过诸如发布软件物料清单（SBOMs）和应用软件供应链层级建议的技术 很适合在早期进行这样的尝试。这种技术的好处是多方面的。首先，自动化能够带来更安全的软件，可以在早期识别并处理漏洞，其次，随着手动任务的消除，开发速度也会加快。最后，还能够降低成本和提高一致性。对于像软件驱动汽车这样的安全关键行业，自动化持续合规可以提高认证过程的效率和可靠性，最终造就更安全、更可靠的车辆。5.边缘函数试验尽管不是一个新概念，我也注意到通过内容交付网络（CDNs）进行去中心化代码执行的可用性和使用量正在增长。诸如 Cloudflare Workers 或 Amazon CloudFront Edge Functions 这样的服务提供了一种机制，可以在靠近客户地理位置的地方执行无服务器代码片段。边缘函数 不仅可以在边缘生成响应时提供更低的延迟，还可以在请求和响应从区域服务器出发和返回的途中，以特定位置的方式重写它们。例如，你可能会重写请求的 URL，以路由到一个特定服务器，该服务器拥有与请求正文中找到的字段相关的本地数据。这种方法最适合于短暂、快速运行的无状态处理，因为边缘的计算能力是有限的。6.安全标兵试验安全标兵*指的是团队成员中对技术和非技术交付决策的安全后果持有批判性思维的人。他们会向团队领导提出这些问题和顾虑，并且对基本安全指南和要求有比较到位的理解。他们协助开发团队在软件交付的所有活动中都以安全意识进行思考，从而降低系统的整体安全风险。安全标兵不是一个单独的职位，而是分配给现有团队成员的责任，这些成员需要由安全从业者进行培训指导。通过这样的培训，安全标兵通过传播知识，并作为开发团队和安全团队之间的桥梁，提高团队的安全意识。安全标兵所做的事情中一个非常好的活动示例是威胁建模，它帮助团队从一开始就将安全风险考虑在内。在团队中任命和培训安全标兵是一个很好的开始，但仅仅依赖标兵而没有来自领导层的适当投入可能会导致问题。根据我们的经验，建立安全意识需要整个团队及管理者的投入。7.Text to SQL试验Text to SQL 是一种用于将自然语言查询转换为可以由数据库执行的 SQL 查询的技术。尽管大语言模型能够理解和转换自然语言，但在你自己的 schema 中创建准确的 SQL 仍然存在很大的挑战。为此可以引入 Vanna，它是一个在 Python 中用于 SQL 生成的检索增强生成（RAG）开源框架。Vanna 分两步工作：首先你需要使用数据定义语言语句（DDLs）和示范 SQL 描述你的结构，并为它们创建嵌入向量，然后再用自然语言提出问题。尽管 Vanna 可以与任何大语言模型协作，我们还是推荐你评估 NSQL，它是一个用于 Text to SQL 任务的领域特定大语言模型。技术 Thoughtworks,Inc.All Rights Reserved.148.追踪健康债务状况试验通过将健康度评级与其他服务级目标（SLO）同等对待，并据此确定增强的优先级，而不是仅仅关注跟踪技术债务，我们不断体验到团队对其生态系统的改进。通过有效分配资源来解决与健康状况相关的最有影响的问题，团队和组织可以降低长期维护成本，更高效地发展产品。这种方法还能加强技术和非技术利益相关者之间的沟通，促进对系统状态的共同理解。尽管不同组织的衡量标准可能有所不同（请参阅本博文 中的示例），但它们最终都有助于实现长期可持续性，并确保软件保持适应性和竞争力。在瞬息万变的数字环境中，专注于 跟踪系统的健康状况与债务，可为维护和增强系统提供结构化的循证战略。9.人工智能团队助理评估像 GitHub Copilot 这样的 AI 编码辅助工具目前主要是在帮助和增强个人工作的背景下讨论的。然而，软件交付仍然是团队工作，并将始终是团队工作，因此你应该寻找创建 AI 团队助理 的方法来帮助创建“10 倍团队”，而不是一群孤立的 AI 辅助的 10 倍工程师。我们已经开始使用一种团队辅助方法，通过结合提示和知识源来增强知识放大、技能提升和对齐。标准化的提示有助于在团队环境中使用已经达成共识的最佳实践，例如编写用户故事的技术和模板，或实施威胁建模等实践。除了提示之外，通过检索增强生成提供的知识源，可以从组织指南或行业特定的知识库中提供与上下文相关的信息。这种方法使团队成员能够及时获得他们需要的知识和资源。10.对 LLM 对话进行图分析评估由大语言模型（LLMs）支持的聊天机器人正变得非常流行，我们看到围绕这些机器人的产品化和生产化都涌现出了许多新技术。其中一个产品化挑战是理解用户如何与这类聊天机器人展开交流，毕竟这种对话有多个发展方向。了解对话流的实际情况对于改进产品和提高转化率至关重要。有一种技术对解决这一问题大有裨益，就是 对 LLM 对话进行图分析（graph analysis for LLM-backed chats）。那些支持特定期望结果的聊天代理 如购物行为或成功解决客户问题 通常可以表示为一个期望的状态机。通过将所有对话加载到一个场景中，你可以分析它实际所处的模式，并寻找与预期状态机的偏差。这有助于发现错误和进行产品改进。11.基于大语言模型的 ChatOps评估基于大语言模型的 ChatOps*是通过聊天平台（主要是 Slack）应用大语言模型的新兴方式，允许工程师通过自然语言来构建、部署和操作软件。这种方式有可能通过增强平台服务的可发现性和用户友好性来简化工程工作流程。截至撰写本文时，两个早期示例分别是 PromptOps 和 Kubiya。然而，考虑到生产环境需要的精细管理，组织在让这些工具接近生产环境前应该彻底评估它们。技术 Thoughtworks,Inc.All Rights Reserved.1512.大语言模型驱动的自主代理评估随着像 Autogen 和 CrewAI 这样的框架的出现，LLM（大型语言模型）驱动的自主代理 正在从单一代理和静态多代理系统发展到更先进的阶段。这些框架允许用户定义具有特定角色的代理，分配任务，并使代理通过委派或对话合作完成这些任务。类似于早期出现的单一代理系统，如 AutoGPT，单个代理可以分解任务，利用预配置的工具，并请求人工输入。尽管这一领域仍处于开发的早期阶段，但它发展迅速，并且拥有广阔的探索空间。13.使用 GenAI 理解遗留代码库评估生成式人工智能（GenAI）和大语言模型（LLMs）可以帮助开发者编写和理解代码。在实际应用中，目前主要体现在较小的代码片段，但更多的产品和技术正在涌现，用于 利用 GenAI 理解遗留代码库。这在遗留代码库文档记录不完整、或者过时的文档具有误导性时尤其有用。例如，Driver AI 或 bloop 使用了 RAG，结合了语言智能、代码搜索与 LLMs，以帮助用户在代码库中定位自己的位置。更大的上下文窗口的新兴模型也将帮助这些技术更适配大型代码库。GenAI 对遗留代码的另一个有前景的应用是在大型机（mainframe）现代化领域，这里的瓶颈通常围绕着需要理解现有代码库、并将这种理解转化为现代化项目需求的逆向工程师。这些逆向工程师有了 GenAI 的帮助可以更快地完成工作。14.VISS评估Zoom 最近开源了其漏洞影响评分系统（Vulnerability Impact Scoring System）VISS。这个系统主要关注的是对安全措施的漏洞评分的优先级排序。VISS 与通用漏洞评分系统（CVSS）的不同之处在于，它不侧重于对最坏情况进行预测，而是试图从防御者的角度更客观地衡量漏洞的影响。为此，VISS 提供了一个基于网页的 UI，基于多个参数来计算漏洞分数 这些参数按照平台、基础设施和数据组进行分类 包括对平台的影响、影响的租户数量、数据影响等。尽管我们对这个特定工具还没有太多的实践经验，但我们认为这种基于行业上下文的优先级定制的评估方法是值得考虑的。15.广泛集成测试暂缓当我们对自动化测试表示赞扬时，也持续看到许多组织在我们认为无效的 广泛集成测试 上投入过多。“集成测试”这个术语在表述上有些模糊不清，我们尝试引用 Martin Fowler 在该主题上的 bliki 条目描述该分类指的是需要所有运行时依赖项的实时版本的测试。这样的测试显然是昂贵的，因为它需要具备所有必要基础设施、数据和服务的全功能测试环境。管理所有这些依赖项的正确版本需要大量的协调工作，这往往会拖慢发布周期。最后，测试本身通常是脆弱且无用的。例如，要确定测试失败是由于新代码、版本依赖性不匹配还是环境不足，而错误信息很少有助于挖掘问题源头。当然，这些批评并不意味着我们认为自动化的“黑盒”集成测试普遍存在问题，但我们的确发现了一种更有帮助的方法就是平衡对信心的需求与发布频率。可以先假设对运行时技术 Thoughtworks,Inc.All Rights Reserved.16依赖项的一组响应来验证被测试系统的行为，然后验证这些假设的两个阶段来完成。第一阶段使用服务虚拟化来创建运行时依赖项的测试替身，并验证被测试系统的行为。这简化了测试数据管理问题，并允许进行确定性测试。第二阶段可以使用契约测试来验证这些环境假设与真实依赖项。16.过度热衷使用大语言模型暂缓在急于利用最新人工智能技术的过程中，许多组织正在试图将大语言模型（LLMs）应用于各种应用，从内容生成到复杂的决策过程。LLMs 的吸引力不可否认；它们提供了看似毫不费力的解决方案来处理复杂问题，开发人员通常可以快速创建此类解决方案，而无需多年深入的机器学习经验。当 LLM-based 的解决方案多少能够工作时，就迅速部署并转向下一个任务，这可能颇具诱惑力。尽管这些基于 LLM 的价值证明是有用的，但我们建议团队仔细考虑所使用的技术以及是否 LLM 真的是正确的最终阶段解决方案。许多 LLM 可以解决的问题如情感分析或内容分类传统的自然语言处理（NLP）可以更便宜、更容易地解决。分析 LLM 的作用，然后评估其他潜在解决方案，不仅可以减轻 过度热衷使用大语言模型 的风险，还可以促进对人工智能技术的更细致理解和应用。17.急于冲向大语言模型微调（fine-tune LLMs）暂缓许多组织都在试图将大语言模型（LLMs）应用于他们的产品、领域或组织知识，我们看到了太多 急于冲向大语言模型微调（fine-tune LLMs）的情况。虽然这种操作的确可以强大到对特定任务的用例进行优化，但在许多情况下对大语言模型进行微调并不是必需的。最常见误用是为了让 LLM 应用程序了解特定的知识、事实或组织的代码库进行微调。在绝大多数场景下，使用检索增强生成（RAG）可以提供更好的解决方案和更优的投入产出比。微调需要大量的计算资源和专家能力，并且比 RAG 面临更多敏感和专有数据挑战。此外当你没有足够的数据进行微调时，还有欠拟合（underfitting）的风险。又或者，当你拥有太多数据时（这倒不太常见），出现过拟合（overfitting）风险。总之达到你所需要任务专业性的正确平衡是比较困难的。在你急于为应用场景进行大语言模型微调前，需要仔细考虑这些权衡和替代方案。18.适用于 SSR 网络应用程序的 Web 组件暂缓随着 Next.js 和 htmx 等框架逐步被采纳，我们看到服务端渲染（SSR）的使用越来越多。作为一种浏览器技术，在服务器上使用 web 组件并非易事。为了简化这一过程，许多框架应运而生，有时甚至使用浏览器引擎来执行操作，但复杂性依然存在。我们的开发人员发现他们需要绕过一些障碍并付出额外努力来整合前端组件和服务端组件。比开发者体验更糟糕的是用户体验：当自定义 web 组件需要在浏览器中加载和填充时，页面加载性能会受到影响，即使使用预渲染和谨慎调整组件，未样式化内容的闪现或一些布局移动几乎不可避免。正如我们在上一期技术雷达中提到的，我们的一个团队因为这些问题不得不将他们的设计系统从基于 web 组件的Stencil迁移出去。最近，我们从另一个团队收到报告，他们最终用浏览器端组件替换了服务器端生成的组件，其原因是开发的复杂性。我们建议谨慎使用 用于 SSR web 应用的 web 组件，即使框架支持。技术 Thoughtworks,Inc.All Rights Reserved.平台188242930313233343536373839404142432623456791516171011121314444749506566676869707172737475767778798081828351525459535658616263648588899091929394959697989910010110210310486871921222028252723841051454648555760暂缓暂缓评估评估试验试验采纳采纳采纳19.CloudEvents试验20.云上 Arm21.Azure Container Apps22.Azure OpenAI Service23.DataHub24.基础设施编排平台25.Pulumi26.Rancher Desktop27.Weights&Biases评估28.Bun29.Chronosphere30.DataOS31.Dify32.Elasticsearch Relevance Engine33.FOCUS34.Gemini Nano35.HyperDX36.IcePanel37.Langfuse38.Qdrant39.RISC-V 用于嵌入式40.Tigerbeetle41.WebTransport42.Zarf43.ZITADEL暂缓 新的挪进/挪出没有变化 Thoughtworks,Inc.All Rights Reserved.1819.CloudEvents采纳事件是事件驱动架构或无服务器应用中的常见机制。然而，生产者或云提供商对它们的支持形式却存在很大差异，这阻碍了跨平台和基础设施的互操作性。CloudEvents 是一种规范，用于以通用格式描述事件数据，以实现跨服务、平台和系统的互操作性。它提供了多种语言的 SDK，因此你可以将该规范嵌入到你的应用程序或工具链中。我们的团队不仅将其用于跨云平台，还用于领域事件规范以及其他场景。CloudEvents 由云原生计算基金会（CNCF）托管，现已成为一个毕业项目。我们的团队默认使用 CloudEvents 构建事件驱动架构，因此我们正将其移入采纳状态。20.云上 Arm试验近年来，由于与传统基于 x86 的实例相比更具有成本和能源效率优势，云上的 Arm 计算实例变得越来越受欢迎。许多云服务提供商现在都提供基于 Arm 的实例，包括 AWS、Azure 和 GCP。云上 Arm 的成本优势对于运行大型工作负载或需要扩展的企业特别有利。我们看到许多团队将工作负载（如 JVM 服务甚至数据库（包括 RDS）迁移到 Arm 实例，无需更改代码，构建脚本的更改也很小。新的基于云的应用程序和系统越来越默认使用云中的 Arm。根据我们的经验，我们建议所有工作负载使用 Arm 计算实例，除非存在特定于架构的依赖。支持多架构的工具，如多架构 Docker 镜像，也简化了构建和部署工作流。21.Azure Container Apps试验Azure Container Apps 是一个托管的 Kubernetes 应用平台，能够简化容器化工作负载的部署。与 Azure Kubernetes Service（AKS）相比，运行容器化应用程序的操作和管理负担相对较少，但这是以牺牲一些灵活性和控制权为代价的，也是团队需要权衡的。这个领域的另一个产品，Azure Container Instances，通常不能满足生产环境的需求。我们的团队去年开始使用 Azure Container Apps，当时它还处于公开预览阶段，但那时它已经能在运行大容器时取得良好的结果。现在它已经普遍可用，我们正在考虑将其应用于更多用例。Dapr 和 KEDA Autoscaler 都是在其支持范围。22.Azure OpenAI Service试验Azure OpenAI Service 通过 REST API、Python SDK 和基于 Web 的界面提供对 OpenAI 的 GPT-4、GPT-3.5-Turbo、Embeddings、DALL-E 模型等的访问。这些模型可以适用于内容生成、提取摘要、语义搜索和将自然语言转换为代码等任务。通过小样本学习（few-shot learning）和自定义超参数（hyperparameters），还可以进行微调。与 OpenAI 自己的 API 相比，Azure OpenAI 服务受益于 Azure 的企业级安全性和合规性功能，可在更多地区使用（尽管在更多地理区域可用性有限），并支持私有网络、内容过滤和手动模型版本控制。基于上述特性以及我们在具体使用中的积极体验，我们推荐已经使用 Azure 的企业考虑使用 Azure OpenAI Service，而不是 OpenAI API。平台 Thoughtworks,Inc.All Rights Reserved.1923.DataHub试验在使用 数据产品思维 构建产品时，数据血缘、数据可发现性、数据治理非常重要。我们的团队发现 DataHub 在这些方面能提供非常有效的支持。DataHub 的早期版本在需要更新元数据模型时，要求用户手动复制管理来自主产品的同步。近期的更新引入了通过插件实现的元数据模型定制。DataHub 的另一个有用功能是从源头到处理再到消费的强大端到端数据脉络。DataHub 既支持基于推送的集成，也支持基于拉动的数据血缘提取，可自动抓取跨数据源、调度器、协调器（通过扫描 Airflow DAG）、处理管道任务和仪表板等元数据。作为完整数据目录的一个开源选项，DataHub 逐渐成为我们团队的默认选择。24.基础设施编排平台试验组织内部的基础设施编排代码库频繁地成为维护和排查故障的时间黑洞。基础设施编排平台 应运而生，试图将基础设施代码交付和部署工作流的各个方面变得标准化和产品化。其中包括构建一些工具