技术

检索增强生成（Retrieval-augmented generation, RAG） 是我们团队提高大语言模型（LLM）生成响应质量的首选模式。我们已经在包括 Jugalbandi AI Platform 在内的多个项目中成功使用了它。通过 RAG，相关且可信的文档（如 HTML 和 PDF 格式）的信息被存储在支持向量数据类型或高效文档搜索的数据库中，例如 pgvector、Qdrant 或 Elasticsearch Relevance Engine。在收到给定提示后，数据库会被调取以检索相关文档，然后这些文档会与提示结合在一起，为 LLM 提供更丰富的上下文。这样一来输出质量更高，且大大减少了幻觉现象。上下文窗口——决定了 LLM 输入的尺寸是有限的，这意味着需要选择最相关的文档。我们会通过重新排序来提升提示内容的相关性。文档如果太大而无法计算嵌入，这意味着它们必须被分割成更小的块。这通常是一个困难的问题，其中一种方法是让这些块在某种程度上重叠。

Spotify 推出的 Backstage 已成为我们客户托管开发者体验门户的首选平台。本身来说，Backstage 只是一个托管插件，在托管的同时提供管理构成平台生态系统资产目录的界面的 shell。任何由 Backstage 显示或管理的实体都在 catalog-info 文件中配置，其中包含状态、生命周期、依赖关系和 API 等其他细节的数据。默认情况下，单个实体描述符是手动编写的，并且通常由负责相应组件的团队进行维护和版本化。保持描述符的更新可能是乏味的，并且会成为开发者采用过程中的障碍。此外，总有可能忽视变更或完全错过某些组件。我们发现 自动生成 Backstage 实体描述符 更有效且不易出错。大多数组织有现有的信息源可以启动填充目录条目的过程。良好的开发实践，例如，在 AWS 资源上放置适当的标签或向源文件添加元数据，可以简化实体发现和描述符生成。这些自动化流程可以定期运行 —— 比如每天一次 —— 以保持目录的新鲜和更新。

大语言模型(LLMs)是自然语言处理(NLP)中的瑞士军刀。但它们往往比较昂贵，且并非总是最合适的 - 有时候使用一个螺丝刀会更合适。实际上，在 将传统NLP与LLMs相结合 ，或者在将多种NLP与LLMs相结合，以实现用例并利用LLMs的实际需求能力的步骤方面有很大的潜力。传统的数据科学和NLP方法，例如文档聚类、主题识别和分类，甚至摘要生成，成本更低且可能更有效地解决你的使用案例问题的一部分。然后，在需要生成和总结较长文本，或将多个大型文档合并时，我们使用LLMs，以利用其较高的注意力跨度和记忆力。例如，我们已经成功地将这些技术结合使用，从一个大型单个趋势文档语料库生成关于某一领域的全面趋势报告，同时结合传统聚类方法和LLMs的生成能力。

持续合规 是一种实践，旨在确保软件开发过程以及相关技术一直遵守行业法规和安全标准，这一过程大量依赖自动化，人工操作可能会降低开发速度并引入错误。作为替代，组织可以自动化合规检查和审计。他们可以将工具集成到软件开发流水线中，使团队能够在开发过程的早期发现并处理合规问题。将合规规则和最佳实践编码化有助于在团队间执行一致的政策和标准。它使用户能够扫描代码变更中的漏洞、强制执行编码标准以及追踪基础设施配置变更，以确保它们满足合规要求。最后，以上内容的自动化报告简化了审计工作，并提供了清晰的合规证据。我们已经讨论过诸如发布软件物料清单（SBOMs）和应用软件供应链层级建议的技术 — 很适合在早期进行这样的尝试。这种技术的好处是多方面的。首先，自动化能够带来更安全的软件，可以在早期识别并处理漏洞，其次，随着手动任务的消除，开发速度也会加快。最后，还能够降低成本和提高一致性。对于像软件驱动汽车这样的安全关键行业，自动化持续合规可以提高认证过程的效率和可靠性，最终造就更安全、更可靠的车辆。

尽管不是一个新概念，我也注意到通过内容交付网络（CDNs）进行去中心化代码执行的可用性和使用量正在增长。诸如 Cloudflare Workers 或 Amazon CloudFront Edge Functions 这样的服务提供了一种机制，可以在靠近客户地理位置的地方执行无服务器代码片段。 边缘函数 不仅可以在边缘生成响应时提供更低的延迟，还可以在请求和响应从区域服务器出发和返回的途中，以特定位置的方式重写它们。例如，你可能会重写请求的 URL，以路由到一个特定服务器，该服务器拥有与请求正文中找到的字段相关的本地数据。这种方法最适合于短暂、快速运行的无状态处理，因为边缘的计算能力是有限的。

安全标兵**指的是团队成员中对技术和非技术交付决策的安全后果持有批判性思维的人。他们会向团队领导提出这些问题和顾虑，并且对基本安全指南和要求有比较到位的理解。他们协助开发团队在软件交付的所有活动中都以安全意识进行思考，从而降低系统的整体安全风险。安全标兵不是一个单独的职位，而是分配给现有团队成员的责任，这些成员需要由安全从业者进行培训指导。通过这样的培训，安全标兵通过传播知识，并作为开发团队和安全团队之间的桥梁，提高团队的安全意识。安全标兵所做的事情中一个非常好的活动示例是威胁建模，它帮助团队从一开始就将安全风险考虑在内。在团队中任命和培训安全标兵是一个很好的开始，但仅仅依赖标兵而没有来自领导层的适当投入可能会导致问题。根据我们的经验，建立安全意识需要整个团队及管理者的投入。

Text to SQL 是一种用于将自然语言查询转换为可以由数据库执行的 SQL 查询的技术。尽管大语言模型能够理解和转换自然语言，但在你自己的 schema 中创建准确的 SQL 仍然存在很大的挑战。为此可以引入 Vanna，它是一个在 Python 中用于 SQL 生成的检索增强生成（RAG）开源框架。Vanna 分两步工作：首先你需要使用数据定义语言语句（DDLs）和示范 SQL 描述你的结构，并为它们创建嵌入向量，然后再用自然语言提出问题。尽管 Vanna 可以与任何大语言模型协作，我们还是推荐你评估 NSQL，它是一个用于 Text to SQL 任务的领域特定大语言模型。 检索增强生成

通过将健康度评级与其他服务级目标（SLO）同等对待，并据此确定增强的优先级，而不是仅仅关注跟踪技术债务，我们不断体验到团队对其生态系统的改进。通过有效分配资源来解决与健康状况相关的最有影响的问题，团队和组织可以降低长期维护成本，更高效地发展产品。这种方法还能加强技术和非技术利益相关者之间的沟通，促进对系统状态的共同理解。尽管不同组织的衡量标准可能有所不同（请参阅本博文 中的示例），但它们最终都有助于实现长期可持续性，并确保软件保持适应性和竞争力。在瞬息万变的数字环境中，专注于 跟踪系统的健康状况与债务 ，可为维护和增强系统提供结构化的循证战略。

像GitHub Copilot这样的 AI 编码辅助工具目前主要是在帮助和增强个人工作的背景下讨论的。然而，软件交付仍然是团队工作，并将始终是团队工作，因此你应该寻找创建 AI 团队助理 的方法来帮助创建“10 倍团队”，而不是一群孤立的 AI 辅助的10 倍工程师。我们已经开始使用一种团队辅助方法，通过结合提示和知识源来增强知识放大、技能提升和对齐。标准化的提示有助于在团队环境中使用已经达成共识的最佳实践，例如编写用户故事的技术和模板，或实施威胁建模等实践。除了提示之外，通过检索增强生成提供的知识源，可以从组织指南或行业特定的知识库中提供与上下文相关的信息。这种方法使团队成员能够及时获得他们需要的知识和资源。

由大语言模型（LLMs）支持的聊天机器人正变得非常流行，我们看到围绕这些机器人的产品化和生产化都涌现出了许多新技术。其中一个产品化挑战是理解用户如何与这类聊天机器人展开交流，毕竟这种对话有多个发展方向。了解对话流的实际情况对于改进产品和提高转化率至关重要。有一种技术对解决这一问题大有裨益，就是 对LLM对话进行图分析（graph analysis for LLM-backed chats） 。那些支持特定期望结果的聊天代理 — 如购物行为或成功解决客户问题 — 通常可以表示为一个期望的状态机。通过将所有对话加载到一个场景中，你可以分析它实际所处的模式，并寻找与预期状态机的偏差。这有助于发现错误和进行产品改进。

基于大语言模型的 ChatOps 是通过聊天平台（主要是 Slack）应用大语言模型的新兴方式，允许工程师通过自然语言来构建、部署和操作软件。这种方式有可能通过增强平台服务的可发现性和用户友好性来简化工程工作流程。截至撰写本文时，两个早期示例分别是 PromptOps 和 Kubiya。然而，考虑到生产环境需要的精细管理，组织在让这些工具接近生产环境前应该彻底评估它们。

随着像 Autogen 和 CrewAI 这样的框架的出现， LLM（大型语言模型）驱动的自主代理 正在从单一代理和静态多代理系统发展到更先进的阶段。这些框架允许用户定义具有特定角色的代理，分配任务，并使代理通过委派或对话合作完成这些任务。类似于早期出现的单一代理系统，如 AutoGPT，单个代理可以分解任务，利用预配置的工具，并请求人工输入。尽管这一领域仍处于开发的早期阶段，但它发展迅速，并且拥有广阔的探索空间。

生成式人工智能（GenAI）和大语言模型（LLMs）可以帮助开发者编写和理解代码。在实际应用中，目前主要体现在较小的代码片段，但更多的产品和技术正在涌现，用于 利用 GenAI 理解遗留代码库 。这在遗留代码库文档记录不完整、或者过时的文档具有误导性时尤其有用。例如，Driver AI 或 bloop 使用了 RAG ，结合了语言智能、代码搜索与 LLMs，以帮助用户在代码库中定位自己的位置。更大的上下文窗口的新兴模型也将帮助这些技术更适配大型代码库。GenAI 对遗留代码的另一个有前景的应用是在大型机（mainframe）现代化领域，这里的瓶颈通常围绕着需要理解现有代码库、并将这种理解转化为现代化项目需求的逆向工程师。这些逆向工程师有了 GenAI 的帮助可以更快地完成工作。

Zoom 最近开源了其漏洞影响评分系统（Vulnerability Impact Scoring System）—— VISS。这个系统主要关注的是对安全措施的漏洞评分的优先级排序。VISS 与通用漏洞评分系统（CVSS）的不同之处在于，它不侧重于对最坏情况进行预测，而是试图从防御者的角度更客观地衡量漏洞的影响。为此，VISS 提供了一个基于网页的 UI，基于多个参数来计算漏洞分数 — 这些参数按照平台、基础设施和数据组进行分类 — 包括对平台的影响、影响的租户数量、数据影响等。尽管我们对这个特定工具还没有太多的实践经验，但我们认为这种基于行业上下文的优先级定制的评估方法是值得考虑的。

当我们对自动化测试表示赞扬时，也持续看到许多组织在我们认为无效的 广泛集成测试 上投入过多。“集成测试”这个术语在表述上有些模糊不清，我们尝试引用 Martin Fowler 在该主题上的bliki 条目描述——该分类指的是需要所有运行时依赖项的实时版本的测试。这样的测试显然是昂贵的，因为它需要具备所有必要基础设施、数据和服务的全功能测试环境。管理所有这些依赖项的正确版本需要大量的协调工作，这往往会拖慢发布周期。最后，测试本身通常是脆弱且无用的。例如，要确定测试失败是由于新代码、版本依赖性不匹配还是环境不足，而错误信息很少有助于挖掘问题源头。当然，这些批评并不意味着我们认为自动化的“黑盒”集成测试普遍存在问题，但我们的确发现了一种更有帮助的方法——就是平衡对信心的需求与发布频率。可以先假设对运行时依赖项的一组响应来验证被测试系统的行为，然后验证这些假设的两个阶段来完成。第一阶段使用服务虚拟化来创建运行时依赖项的测试替身，并验证被测试系统的行为。这简化了测试数据管理问题，并允许进行确定性测试。第二阶段可以使用契约测试来验证这些环境假设与真实依赖项。

在急于利用最新人工智能技术的过程中，许多组织正在试图将大语言模型（LLMs）应用于各种应用，从内容生成到复杂的决策过程。LLMs 的吸引力不可否认；它们提供了看似毫不费力的解决方案来处理复杂问题，开发人员通常可以快速创建此类解决方案，而无需多年深入的机器学习经验。当LLM-based的解决方案多少能够工作时，就迅速部署并转向下一个任务，这可能颇具诱惑力。尽管这些基于LLM的价值证明是有用的，但我们建议团队仔细考虑所使用的技术以及是否LLM真的是正确的最终阶段解决方案。许多LLM可以解决的问题——如情感分析或内容分类——传统的自然语言处理（NLP）可以更便宜、更容易地解决。分析LLM的作用，然后评估其他潜在解决方案，不仅可以减轻 过度热衷使用大语言模型 的风险，还可以促进对人工智能技术的更细致理解和应用。

许多组织都在试图将大语言模型(LLMs)应用于他们的产品、领域或组织知识，我们看到了太多 急于冲向大语言模型微调（fine-tune LLMs） 的情况。虽然这种操作的确可以强大到对特定任务的用例进行优化，但在许多情况下对大语言模型进行微调并不是必需的。最常见误用是为了让 LLM 应用程序了解特定的知识、事实或组织的代码库进行微调。在绝大多数场景下，使用检索增强生成（RAG）可以提供更好的解决方案和更优的投入产出比。微调需要大量的计算资源和专家能力，并且比 RAG 面临更多敏感和专有数据挑战。此外当你没有足够的数据进行微调时，还有欠拟合(underfitting)的风险。又或者，当你拥有太多数据时(这倒不太常见)，出现过拟合(overfitting)风险。总之达到你所需要任务专业性的正确平衡是比较困难的。在你急于为应用场景进行大语言模型微调前，需要仔细考虑这些权衡和替代方案。

随着Next.js和htmx等框架逐步被采纳，我们看到服务端渲染（SSR）的使用越来越多。作为一种浏览器技术，在服务器上使用web 组件并非易事。为了简化这一过程，许多框架应运而生，有时甚至使用浏览器引擎来执行操作，但复杂性依然存在。我们的开发人员发现他们需要绕过一些障碍并付出额外努力来整合前端组件和服务端组件。比开发者体验更糟糕的是用户体验：当自定义 web 组件需要在浏览器中加载和填充时，页面加载性能会受到影响，即使使用预渲染和谨慎调整组件，未样式化内容的闪现或一些布局移动几乎不可避免。正如我们在上一期技术雷达中提到的，我们的一个团队因为这些问题不得不将他们的设计系统从基于 web 组件的Stencil迁移出去。最近，我们从另一个团队收到报告，他们最终用浏览器端组件替换了服务器端生成的组件，其原因是开发的复杂性。我们建议谨慎使用 用于 SSR web 应用的 web 组件 ，即使框架支持。