有态度的前沿技术解析，第28期技术雷达正式发布！

经过半年的追踪与沉淀，TAB 根据我们在多个行业中的实践案例，为技术从业者们产出了第28期技术雷达。本期内容对百余个技术条目进行分析，阐述它们目前的成熟度，并提供了相应的技术选型建议。

一、本期主题

1.实用人工智能的飞速崛起

别多想，这篇主题文章并非由 ChatGPT 撰写。人工智能已经在专业领域默默酝酿了几十年，像 GitHub Copilot 这样的工具在几年前就已经存在（并逐渐被采用）了。然而，在过去几个月里，类似 ChatGPT 这样的工具已经彻底改变了人们对人工智能的认识，并使得这类工具开始被广泛使用。本期技术雷达中有几个条目涉及到了 AI 在项目上的实际应用，不仅仅是关于代码建议的范畴：基于AI辅助的测试先行开发、使用AI帮助构建分析模型等。类似于电子表格能够让会计师停止用计算器手动重新计算复杂表格，下一代的AI会承担起替换需要知识（而不是智慧）的乏味任务，来解放技术从业者包括开发人员。

不过，我们提醒不要过度或不当使用人工智能。现今，AI模型能够生成一个良好的初稿。但生成的内容始终需要由人类监测、验证、审查和负责任地使用。如果忽视这些预警，机构和用户可能面临名誉和安全风险。甚至有些产品用例 也提醒用户，“AI生成的内容可能存在错误。在使用前请确保它的正确性和合理性”。

2.易用的无障碍设计

多年来，无障碍设计一直是组织重视的因素。最近，我们着重展示了我们的团队在工具和技术方面经验的增长，这些经验使开发具备了更好的无障碍设计。我们几个地区的团队通过宣传活动增强了对这些技术的认知。我们在持续集成流水线开发、设计中的无障碍注解、智能引导无障碍测试、ax-lineter 和 IBM Equal Access Accessibility Checker 方面，提出了与无障碍设计相关的条目。我们很愿意看到人们越来越重视这个主题，为更多的人提供改进后的功能访问方式，这些技术毫无疑问是优秀的。

3.Lambda 陷阱

无服务器函数 AWS Lambdas 越来越频繁地出现在架构师和开发者的工具箱中，并被用于实现各种基于于云基础架构的任务。然而，就像许多有用的东西一样，有时候解决方案开始时简洁实用，但随着不断成功、持续演进，最终违反范式中规定的约束、变得沉重不堪，终遭弃用。在看到许多无服务器风格解决方案成功应用的同时，我们也从项目中听到了许多警示性的故事，比如 Lambda 弹球反模式。虽然出现了很多解决这些问题的工具，但是这些工具极易被误用。例如，帮助 Lambda 之间共享代码或协调复杂互动的工具，它可能可以解决一个简单常见的问题，但随着新的构建模块的加入就会面临出现低劣架构模式的风险。如果您需要一个工具来管理跨无服务器函数集合的代码共享和独立部署，那么也许是时候重新思考该方法的适用性了。像所有的技术解决方案一样，无服务器有其适宜的应用场景，但它的许多功能在使用时都需要权衡利弊，这种情况随着解决方案的演进会更加突出。

4.数据分析和人工智能中的工程严谨性

我们始终认为 "质量内建" 是开发可靠的数据分析与机器学习模型的重要因素。测试驱动的数据转化，数据健全测试和数据模型测试使数据流水线可以更有力的支持分析系统。机器学习系统需要模型验证和质量控制来确保结果符合伦理，平等无偏见。通过整合这些实践，企业能更好地利用人工智能和机器学习，基于各自的用户群体打造负责任、数据驱动的解决方案。相关的工具生态也在不断演进，日趋成熟。例如，Soda Core 是一个在接收数据伊始就开始验证并自动监测异常的数据质量工具，Deepchecks 结合了持续集成和模型检查，将好的工程实践融入分析系统。Giskard 对 AI 模型进行质量控制，可以检查模型的偏见等其他负面因素，这与我们提倡的在开发 AI 解决方案时关注伦理的理念相符。我们认为这些逐渐成熟的工具可以证明，数据分析、人工智能与良好的工程实践相结合正在成为主流。

5.声明，还是编程？

每次技术雷达讨论时都会发生的，好像永无止境的话题在这次会议变得格外激烈——对于给定的任务，应该使用 JSON、YAML 或者像 HCL 这样的领域特定语言来编写声明性规范，还是应该在通用编程中编写代码语言？例如，我们讨论了 Terraform Cloud Operator 与 Crossplane 的区别，在其他情况下对部署流水线进行编程时，是否使用 AWS CDK 或 Dagger。声明性规范虽然通常更易于阅读和编写，但其有限的抽象会导致重复代码的产生。适当的编程语言可以使用抽象来避免重复，但这些抽象会让代码变得更难理解，特别是当抽象经过多年的变化而分层时。根据我们的经验，上述问题没有标准答案。这两种方法团队都应该考虑，当一个解决方案无法用一种语言类型去简洁的实现时，就应该重新评估使用另一种类型。有些时候拆分关注点并用不同的语言实现它们会更加合理。

二、部分象限亮点抢先看

将 CI/CD 基础设施作为一种服务

采纳

将 CI/CD 基础设施作为一种服务已经是很多元化以及成熟的方案，以至于需要自己管理整个 CI 基础设施的情况变得非常少见。使用 GitHub Actions、Azure DevOps 或 Gitlab CI/CD 等管理服务，具有托管云服务的所有常见优势（和权衡）。您不需要花时间、精力和硬件成本来维护和运营这个通常很复杂的基础设施。对于自己托管 CI 设施的公司，虽然团队可以受益于弹性和自助服务，然而往往在配置更多合适的代理或获得新的插件或功能时遇到瓶颈。即使是需要在自己的硬件上运行构建和验证的用例，现在也大多可以用自我托管的运行器来满足需求（我们已经写过一些关于 GitHub Actions 的文章，actions-runner-controller 和 Philips 的自我托管 GitHub 运行器）。然而，请注意，使用托管服务并不意味着您可以轻易获得安全保障；虽然成熟的服务提供了所需要的所有安全功能，但仍然需要实施对 CI/CD 基础架构的零信任安全。

设计中的无障碍注解

试验

在软件交付中越早考虑无障碍，就能越简单、更低成本的保证交付物对尽可能多的人可用。设计中的无障碍注释工具能促进沟通，帮助团队从工作的开始就考虑到文档结构、语义化的 HTML 和替代文本等重要的元素。这使得团队确保用户界面符合国际无障碍标准，并解决那些实际上很容易避免的常见无障碍问题。Figma 提供了一系列的无障碍性注释插件：The A11y Annotation Kit, Twitter 的 Accessibility Annotation Library 和 Axe 的工具集 Axe for Designers。

Soda Core

试验

Soda Core 是一个开源数据质量与可观测性工具。我们的团队已经使用它来验证数据在到达系统之前和之后的转换，并设置自动化监测检查以检测异常情况。我们对 Soda Core 中用于编写数据检查的 DSL —— SodaCL非常满意. SodaCL 能帮助除了数据工程师以外的其他团队成员来编写质量检查。总的来说，我们在解决大规模数据问题时使用 Soda Core 的体验非常好。

ChatGPT

评估

ChatGPT 是一个有趣的工具，它具有在软件开发的各个方面发挥作用的潜力。作为一个已经"阅读"了数十亿个网页的大型语言模型（LLM），ChatGPT 可以提供额外的视角，协助完成不同的任务，包括生成创意和需求、创建代码和测试等。它是一种多功能的工具，能够跨越软件生命周期的多个阶段，提高开发效率并减少错误。GPT-4，作为驱动 ChatGPT 的 LLM，现在也具备与外部工具集成的能力，如知识管理库、沙盒式编码环境以及网络搜索。目前，我们认为 ChatGPT 更适合作为流程的输入，如帮助完成用户故事的初稿或编码任务的模板，而不是一个能够产出"完美周全"结果的工具。

使用这些人工智能工具可能会存在知识产权和数据隐私方面的担忧，包括一些尚未解决的法律问题，因此我们建议企业在使用前征求其法律团队的意见。我们的一些客户已经开始在软件生命周期的各个阶段尝试使用 ChatGPT，我们鼓励其他人探索这个工具并评估其潜在的作用。我们预计，像 GitHub Copilot 一样，ChatGPT 很快就会有一个"商业版"的产品，这可能会缓解知识产权方面的顾虑。

Immuta

评估

Immuta 是一个数据安全平台，它允许你安全地访问数据，自动发现敏感数据并审计数据在组织中的使用情况。在过去，当我们考虑安全风险时，我们已经谈到了自动化、工程实践和将安全策略代码化的重要性。数据安全也不例外。我们的团队一直在探索 Immuta，它能将数据访问策略作为代码来管理，以实现精细化的访问控制，这超出了基于角色的访问控制（RBAC）所能提供的范围。基于版本控制的策略可以被测试，然后配置为 CI/CD 管道的一部分。在一个去中心化的数据生态系统中，比如由数据网格促成的生态系统，拥有特定领域的角色会导致身份认证系统中的角色或用户组扩散。Immuta 的基于属性的访问控制（ABAC）的特性将访问授权简化为一个数学方程式，即把用户的 "属性 "与数据源的 "标签 "相匹配。这个平台虽然很新，但在满足数据安全需求方面绝对值得考虑。

Passkeys

评估

“密码的终结”可能终于要到来了。在 FIDO 联盟的指导和苹果、谷歌、微软的支持下， passkeys 的可用性正在接近其他主流身份验证方式。当用 passkeys 注册新的登录信息时，它会产生一对密钥：网站收到公钥而用户保留私钥。它使用非对称加密处理登录。用户需要证明他们拥有私钥，但与密码不同，私钥不会被发送到网站上。在用户的设备上，会使用生物识别技术或 PIN 码来保护对 passkeys 的访问。

Passkeys 可以在各大软件生态中存储和同步，例如苹果的 iCloud 钥匙链、谷歌的密码管理器或微软的 Windows Hello。在大多数情况下，该功能只适用于最新的操作系统和浏览器版本。值得注意的是，Windows 10 并不支持在 Windows Hello 中存储密码。不过幸运的是，客户端到认证器协议 (CTAP) 让 passkeys 可以被保存在创建密钥或需要密钥登录的设备之外的不同设备上。例如，一个用户在 Windows 10 上为一个网站创建了一个 passkeys，并通过扫描二维码将其存储在 iPhone 上。因为密钥是通过 iCloud 同步的，所以用户可以从他们的 MacBook 等其他 Apple 生态设备上登录到该网站。Passkeys 也可以存储在硬件安全密钥上，在 iOS 和 Android 上也提供了对原生应用的支持。

尽管仍有一些可用性问题——例如，登录时需要设备支持并开启蓝牙，因为扫描二维码时要检查设备是否接近—— passkeys 依然是值得考虑的。我们建议你在 passkeys.io 上试用，以了解它们的可用性。

PyTorch

采纳

PyTorch 一直是我们选择的机器学习（ML）框架。相比于 TensorFlow，大多数团队更喜欢 PyTorch，因为它暴露了 TensorFlow 隐藏的 ML 内部工作原理，使其更易于调试。动态计算图使得模型优化比其他任何 ML 框架都更容易。State-of-the-Art (SOTA) 模型 的广泛可用性以及实现研究论文的便利性使 PyTorch 脱颖而出。在图 ML 领域，PyTorch Geometric 是一个更成熟的生态系统，我们的团队在使用中获得了良好的体验。PyTorch 在模型部署和扩展方面也逐渐弥合了缺失，例如，我们的团队已成功地在生产中使用 TorchServe 服务预训练模型。随着许多团队默认使用 PyTorch 来满足其端到端的深度学习需求，我们很高兴地建议采纳 PyTorch。

LangChain

评估

LangChain 是一个用于构建基于大型语言模型(LLMs)应用的框架。这些模型已经引起了一场生成式人工智能在各种场景下的竞赛。但是，单独使用这些 LLMs 可能是不够的——你必须将其与差异化的资产相结合去构建有影响力的产品。LangChain 提供了一些方便的功能去填补了模型和应用之间的裂痕，这些功能包括提示管理，组件链式连接，生成增强数据及丰富的用于确定执行动作和顺序的代理 。我们期待基于 LLMs 演变出更多的工具和框架, 并且我们推荐对 LangChain 进行评估。