Enable javascript in your browser for better experience. Need to know to enable it? Go here.
第32期 | 四月 2025

平台

  • 平台

    采纳 试验 评估 暂缓 采纳 试验 评估 暂缓
  • 新的
  • 移进/移出
  • 没有变化

平台

采纳 ?

  • 23. GitLab CI/CD

    GitLab CI/CD 已发展为 GitLab 内部一个高度集成的系统,涵盖从代码集成、测试到部署和监控的所有环节。它支持复杂的工作流,包括多阶段流水线、缓存、并行执行和自动扩展运行器,非常适合大型项目和复杂流水线需求。我们特别想强调其内置的安全和合规工具(如 SAST 和 DAST 分析),使其非常适合具有高合规性要求的场景。此外,它还与 Kubernetes 无缝集成,支持云原生工作流,并提供实时日志、测试报告和可追溯性,以增强可观察性。

  • 24. Trino

    Trino 是一个开源的分布式 SQL 查询引擎,专为大数据的交互式分析查询而设计。它针对本地和云端环境进行了优化,支持直接在数据驻留的位置进行查询,包括关系型数据库和各种专有数据存储(通过连接器)。Trino 还能够查询存储为 Parquet 等文件格式的数据,以及像 Apache Iceberg 这样的开放表格格式。其内置的查询联邦功能允许将多个数据源的数据作为一个逻辑表进行查询,非常适合需要聚合多种来源数据的分析工作负载。Trino 是许多流行技术栈(如 AWS Athena、Starburst 和其他专有数据平台)的重要组成部分。我们的团队在各种用例中成功使用了 Trino,对于跨多个数据源进行分析的数据集查询,Trino 一直是一个可靠的选择。

试验 ?

  • 25. ABsmartly

    ABsmartly 是一款先进的 A/B 测试与实验平台,专为快速且可信的决策制定而设计。其核心亮点是 Group Sequential Testing (GST) 引擎,与传统 A/B 测试工具相比,可将测试结果的速度提升高达 80%。平台提供实时报告、深度数据分割以及通过 API 优先的方式实现的无缝全栈集成,支持在网页、移动端、微服务和机器学习模型中运行实验。

    ABsmartly 专注于解决可扩展、数据驱动实验中的关键挑战,使得更快的迭代和更敏捷的产品开发成为可能。通过零延迟执行、强大的深度分割能力以及对多平台实验的支持,ABsmartly 对希望扩大实验文化并优先推动数据驱动创新的组织尤为有价值。借助其显著缩短的测试周期和自动化结果分析能力,ABsmartly 帮助我们比传统 A/B 测试平台更高效地优化功能和用户体验。

  • 26. Dapr

    自从我们上次在技术雷达中介绍 Dapr 以来,它已经有了显著的发展。它的许多新特性包括任务调度、虚拟角色以及更为复杂的重试策略和可观察性组件。它的构建模块列表不断扩展,新增了任务、加密等功能。我们的团队还注意到 Dapr 在安全默认设置方面的日益关注,支持 mTLS 和无发行版镜像。总体而言,我们对 Dapr 的表现感到满意,并期待其未来演进。

  • 27. Grafana Alloy

    前身为 Grafana Agent,Grafana Alloy 是一个开源的 OpenTelemetry Collector。Alloy 被设计为一个一体化的遥测数据收集器,用于收集包括日志、指标和跟踪在内的所有遥测数据。它支持常用的遥测数据格式,如 OpenTelemetry、Prometheus 和 Datadog。随着 Promtail 最近被弃用,Alloy 正逐渐成为遥测数据收集的首选工具——特别是在使用 Grafana 可观察性技术栈时,用于日志数据的收集。

  • 28. Grafana Loki

    Grafana Loki是一个受 Prometheus 启发的横向可扩展,高可用的多租户日志聚合系统。Loki 只对日志的元数据进行索引,并把它当做日志流的标签集,而日志数据本身则储存在像 S3, GCS 或 Azure Blob Storage 这样的块存储方案中。这样做的好处是 Loki 比竞争对手的运维复杂度更低,同时也降低了存储成本。正如你所期待的那样,它与 Grafana 和Grafana Alloy深度集成,即使其他的日志采集机制也被支持。

    Loki 3.0 引入了对原生OpenTelemetry的支持,这使得与 OpenTelemetry 系统的数据摄入与集成如配置一个端点一样简单。此外,它还提供了高级的多租户功能,例如通过 shuffle-sharding 的方式实现各租户间的隔离,避免异常的租户(比如正在执行高负载查询或者出现故障)影响到集群中的其他租户。如果你还没有关注 Grafana 生态系统的最新发展,现在正是个好时机——它正在快速地演进。

  • 29. Grafana Tempo

    Grafana Tempo 是一个高可扩展的分布式追踪后端,支持诸如 OpenTelemetry 等开放标准。Tempo 专为成本效率设计,依赖对象存储进行长期追踪数据的保存,并支持追踪查询、基于 Span 的指标生成以及与日志和指标的关联。Tempo 默认使用 Apache Parquet 为基础的列式块格式,提高了查询性能,并使下游工具能够访问追踪数据。查询通过 TraceQLTempo CLI 执行。Grafana Alloy 也可以配置以收集并转发追踪数据到 Tempo。我们的团队在 GKE 上自托管了 Tempo,使用 MinIO 作为对象存储,结合 OpenTelemetry 收集器以及 Grafana 用于追踪数据的可视化。

  • 30. Railway

    Heroku 曾是许多开发者快速发布和部署应用程序的优秀选择。近年来,我们也看到了像 Vercel 这样更现代、轻量且易用的平台的兴起,虽然它们主要面向前端应用的部署。而在全栈部署领域的一个替代选择是 Railway,这是一个云端 PaaS 平台,简化了从 GitHub/Docker 部署到生产环境可观测性的整个流程。

    Railway 支持大多数主流编程框架、数据库以及容器化部署。作为应用程序的长期托管平台,您可能需要仔细比较不同平台的成本。目前,我们的团队对 Railway 的部署和可观测性体验良好。其操作流畅,并且能够很好地与我们倡导的 持续部署 实践相结合。

  • 31. Unblocked

    Unblocked 是一款现成的 AI 团队助手。通过与代码库、企业文档平台、项目管理工具以及沟通工具的集成,Unblocked 能帮助解答关于复杂业务和技术概念、架构设计与实现以及操作流程的问题。这在处理大型或遗留系统时尤为有用。在使用 Unblocked 的过程中,我们观察到团队更重视快速获取与代码和用户故事相关的上下文信息,而非生成代码或用户故事。对于这些生成任务,特别是编码场景,软件工程代理 更为适合。

  • 32. Weights & Biases

    Weights & Biases 持续发展,自上次在技术雷达中提及以来,增加了更多面向 LLM 的功能。他们扩展了 Traces 并推出了 Weave,一个超越 LLM 系统跟踪的完整平台。Weave 支持创建系统评估、定义自定义指标、使用 LLM 作为任务(如摘要)的评判工具,并保存数据集以捕捉不同行为进行分析。这有助于优化 LLM 组件,并在本地和全局层面跟踪性能。该平台还支持迭代开发和高效调试,这对错误难以检测的代理系统尤为重要。此外,它还允许收集宝贵的人类反馈,这些反馈可以用于后续模型微调,从而进一步提升模型的表现和可靠性。

评估 ?

  • 33. Arize Phoenix

    随着大语言模型和AI agent 应用的日益普及,LLM 可观测性的重要性不断凸显。此前,我们曾推荐过 LangfuseWeights & Biases (W&B) 等平台。 Arize Phoenix 是该领域另一个值得关注的新兴平台,我们团队在实际使用中也取得了积极的体验。Phoenix 提供了诸如 LLM 链路追踪、评估和提示词管理等核心功能,并可与主流 LLM 提供商和开发框架无缝集成,以在低成本、低配置的情况下实现对 LLM 输出内容、延迟和 Token 消耗等指标的深度洞察。目前我们仅限于对其开源工具的使用经验,而更全面的商业版 Arize 平台拥有更多高级能力,我们也期待未来对此进行进一步探索。

  • 34. Chainloop

    Chainloop 是一个开源的软件供应链安全平台,帮助安全团队强制执行合规性要求,同时允许开发团队将安全合规无缝集成到 CI/CD 流水线中。它包括一个控制平面(Control Plane),作为安全策略的单一事实来源,以及一个 CLI,用于在 CI/CD 工作流 中运行声明(attestations)以确保合规性。安全团队可以定义 工作流契约(Workflow Contracts),明确需要收集哪些工件(如 SBOM 和漏洞报告)、存储位置以及如何评估合规性。Chainloop 使用 OPA 的策略语言 Rego 验证声明,例如确保 CycloneDX 格式的 SBOM 符合版本要求。在工作流执行过程中,安全工件(如 SBOM)会附加到声明中,并推送到控制平面进行强制执行和审计。此方法确保可以一致且大规模地实施合规性,同时最大限度地减少开发工作流中的摩擦。最终,它实现了一个符合 SLSA 三级标准的单一事实来源,用于元数据、工件和声明的管理。

  • 35. DeepSeek R1

    DeepSeek-R1 是 DeepSeek 推出的第一代 推理模型 。在一系列非推理模型的基础上,DeepSeek 的工程师设计并应用了多种方法来最大化硬件使用率。这些方法包括多头潜在注意力(Multi-Head Latent Attention, MLA)、专家混合(Mixture of Experts, MoE)门控、8 位浮点训练(FP8)以及底层 PTX 编程。这些方法结合其 高性能计算协同设计 方法使 DeepSeek-R1 在显著降低训练和推理成本的同时,达到与最先进模型(state-of-the-art)相媲美的表现。

    DeepSeek-R1-Zero 另一个显著创新在于: 工程师们可以通过简单的强化学习(RL),无需监督微调(SFT)即可让非推理模型展现出推理能力。此外,所有的 DeepSeek 模型都为开放权重,即它们可以被自由获取,但训练代码和训练数据仍然为专有。该代码库还包括六个从 DeepSeek-R1 蒸馏而来的稠密模型,基于 Llama 和 Qwen 构建,其中的 DeepSeek-R1-Distill-Qwen-32B 在多个基准测试中超越了 OpenAI-o1-mini。

  • 36. Deno

    由 Node.js 的发明者 Ryan Dahl 创建的 Deno,旨在修正他认为 Node.js 存在的错误。Deno 具有更严格的沙盒机制、内置的依赖管理以及原生的 TypeScript 支持——这也是对其用户群体的重要吸引力。许多开发者在 TypeScript 项目中更偏爱 Deno,因为它更像是一个真正的 TypeScript 运行时和工具链,而不仅仅是 Node.js 的一个附加组件。

    自从被列入2019 年技术雷达以来,Deno 取得了显著进展。Deno 2 版本引入了对 Node.js 和 npm 库的兼容性支持,并推出了长期支持 (LTS) 版本及其他改进。此前,阻碍 Deno 采用的主要障碍之一是需要重写 Node.js 应用程序,而这些更新降低了迁移的难度,同时扩展了对相关工具和系统的依赖选项。鉴于 Node.js 和 npm 庞大的生态系统,这些变化有望进一步推动 Deno 的普及。

    此外,Deno 的标准库已趋于稳定,有助于遏制 npm 生态中过多低价值软件包的泛滥。Deno 提供的工具链和标准库,使 TypeScript 或 JavaScript 在服务器端开发中更具吸引力。然而,我们也提醒开发者,不应仅仅为了避免多语言编程而选择某个平台。

  • 37. Graphiti

    Graphiti 构建了动态且时间感知的知识图谱,能够捕捉不断演化的事实和关系。我们的团队使用 GraphRAG 来挖掘数据之间的关系,从而提升检索与响应的准确性。在数据集不断变化的情况下,Graphiti 在图的边上维护了时间元数据,用以记录关系的生命周期。它能够将结构化和非结构化数据以离散的Episodes 形式进行摄取,并支持基于时间、全文检索、语义和图算法的查询融合。 对于基于 LLM 的应用程序——无论是 RAG 模式还是 Agentic 方法——Graphiti 都能够支持长期记忆和基于状态的推理。

  • 38. Helicone

    类似于 LangfuseWeights & BiasesArize PhoenixHelicone 是一个面向企业需求的托管 LLMOps 平台,专注于管理 LLM 成本、评估 ROI 和降低风险。作为一个开源且以开发者为中心的平台,Helicone 支持生产级 AI 应用,覆盖整个 LLM 生命周期的提示词实验、监控、调试和优化。它能够实时分析来自不同 LLM 提供商的成本、利用率、性能以及代理堆栈跟踪。虽然 Helicone 大大简化了 LLM 运维管理,但作为一个正在发展的平台,它可能需要一定的专业知识才能充分利用其先进功能。我们的团队目前正在使用该平台,并获得了良好的体验。

  • 39. Humanloop

    Humanloop 是一个新兴的平台,致力于通过在关键决策点引入人类反馈,使 AI 系统更加可靠、适应性更强并且更符合用户需求。平台提供了用于人工标注、主动学习和人工参与的微调工具,同时支持根据业务需求对大语言模型进行评估。此外,它还帮助优化生成式 AI 解决方案的生命周期,以更高的成本效益实现更大的控制和效率。Humanloop 支持通过共享工作区、版本控制的提示管理以及 CI/CD 集成进行协作,从而有效防止回归。它还提供了可观测性功能,例如追踪、日志记录、警报和安全防护,用于监控和优化 AI 系统性能。这些功能使其在部署 AI 于高风险或受监管领域的组织中尤为重要,在这些领域中,人类监督是关键。凭借对负责任 AI 实践的关注,Humanloop 对于希望构建可扩展且符合伦理要求的 AI 系统的团队来说,值得认真评估。

  • 40. 模型上下文协议(MCP)

    在提示生成中,最大的挑战之一是确保 AI 工具能够访问与任务相关的所有上下文信息。这些上下文信息通常已经存在于我们每天使用的系统中,如维基、问题追踪器、数据库或可观察性系统。AI 工具与这些信息源的无缝集成可以显著提高 AI 生成输出的质量。

    模型上下文协议(MCP)是由 Anthropic 发布的开放标准,提供了一个标准化的框架,用于将 LLM 应用与外部数据源和工具集成。它定义了 MCP 服务器和客户端,服务器访问数据源,客户端则集成并使用这些数据来增强提示。许多编码助手已经实现了 MCP 集成,使其能够作为 MCP 客户端运行。MCP 服务器可以通过两种方式运行:本地运行,作为在用户机器上运行的 Python 或 Node 进程;或者远程运行,作为通过 SSE 连接的服务器(尽管我们尚未看到远程服务器的使用)。目前,MCP 主要以第一种方式使用,开发者通过克隆开源的 MCP 服务器 实现 来使用它。虽然本地运行的服务器提供了一种避免第三方依赖的简洁方式,但它们对于非技术用户仍然不够友好,并且带来了治理和更新管理等挑战。尽管如此,可以预见这一标准未来可能会发展成一个更成熟、更易于用户使用的生态系统。

  • 41. Open WebUI

    Open WebUI 是一个开源的自托管 AI 平台,功能多样且强大。它支持兼容 OpenAI 的 API,并能够与 OpenRouterGroqCloud 等提供商集成。通过 Ollama,它可以完全离线运行,连接到本地或 自托管 的模型。Open WebUI 内置了 RAG(检索增强生成) 功能,让用户可以在聊天驱动的体验中与本地或基于网络的文档互动。平台提供了细粒度的 RBAC(基于角色的访问控制)功能,可以为不同用户组配置不同的模型和平台能力。此外,Open WebUI 支持通过 Functions 进行扩展,这些基于 Python 的构建模块能够自定义和增强平台功能。一个重要功能是其 模型评估 系统,其中包含用于在特定任务上对比 LLM 的模型竞技场。Open WebUI 可根据不同需求部署于各类场景——无论是个人 AI 助手、团队协作助手,还是企业级 AI 平台,都能灵活适配。

  • 42. pg_mooncake

    pg_mooncake 是一个 PostgreSQL 扩展,用于添加列式存储和向量化执行功能。其列存表可存储为 Iceberg 或 Delta Lake 表格,数据可以存放在本地文件系统或兼容 S3 的云存储中。 pg_mooncake 支持从 Parquet、CSV 文件甚至 Hugging Face 数据集加载数据,非常适合需要列式存储的重度数据分析场景。它消除了在技术栈中添加专用列式存储技术的需求,为数据密集型分析提供了高效解决方案。

  • 43. 推理模型(Reasoning Models)

    自上次雷达发布以来, 推理模型(Reasoning Models) 的突破和普及是人工智能领域最重要的进展之一。这些模型,也被称为“思考模型”,在诸如前沿数学和编码等基准测试中,它们已达到人类顶级水平的表现。

    推理模型通常通过强化学习(RL)或监督式微调(SFT)进行训练,增强了诸如逐步思考(思维链)、探索替代方案(思维树)和自我修正等能力。典型代表包括 OpenAI 的 o1 / o3DeepSeek R1Gemini 2.0 Flash Thinking。然而,这些模型应被视为与通用大型语言模型(LLM)不同的类别,而非简单的高级版本。

    这种能力提升伴随着代价。推理模型需要更长的响应时间和更高的 token 消耗,因此我们戏称它们为“更慢的 AI”(如果当前的 AI 还不够慢的话)。并非所有任务都值得采用这类模型。对于文本摘要、内容生成或快速响应聊天机器人等简单任务,通用 LLM 仍然是更好的选择。我们建议在 STEM 领域、复杂问题解决和决策制定中使用推理模型——例如,将 LLM 用作评判者或通过推理模型显式的 CoT 输出来提高最终结果的可解释性。截至撰写本文时,混合推理模型 Claude 3.7 Sonnet 已发布,暗示了传统 LLM 和推理模型之间融合的可能性。

  • 44. Restate

    Restate 是一个持久化执行平台,类似于 Temporal ,由 Apache Flink 的原始创始人开发。功能方面,它提供了将工作流作为代码、状态事件处理、Saga 模式和持久化状态机等特性。Restate 使用 Rust 编写,并作为单个二进制文件部署,利用分布式日志记录事件,并通过基于 Flexible Paxos 的虚拟共识算法来实现,这保证了在节点故障时的持久性。平台提供了 Java、Go、Rust 和 TypeScript 等常见语言的 SDK。我们仍然认为,在分布式系统中最好避免使用分布式事务,因为这会带来额外的复杂性和不可避免的运维开销。然而,如果在你的环境中无法避免分布式事务,这个平台是值得评估的。

  • 45. Supabase

    Supabase 是一个开源的 Firebase 替代方案,用于构建可扩展且安全的后端。它提供了一整套集成服务,包括 PostgreSQL 数据库、认证、即时 API、Edge Functions、实时订阅、存储以及向量嵌入。 Supabase 的目标是简化后端开发,使开发者能够专注于构建前端体验,同时利用开源技术的强大功能和灵活性。与 Firebase 不同,Supabase 基于 PostgreSQL 构建。如果您正在进行原型设计或开发 MVP(最小可行产品),Supabase 值得考虑,因为在原型阶段之后,它更容易迁移到其他 SQL 解决方案。

  • 46. Synthesized

    在软件开发中,一个常见的挑战是为开发和测试环境生成测试数据。理想情况下,测试数据应尽可能接近生产环境,同时确保不暴露任何个人身份信息或敏感信息。虽然这看似简单,但测试数据的生成却远非易事。这也是我们对 Synthesized 感兴趣的原因——一个可以屏蔽和子集化现有生产数据,或生成具有统计相关性的合成数据的平台。Synthesized 可直接集成到构建流水线中,并提供隐私屏蔽功能,通过不可逆的数据混淆技术(如哈希、随机化和分组)实现逐属性匿名化。此外,它还可以生成大量合成数据用于性能测试。尽管该平台包含了当下流行的生成式 AI 功能,但其核心功能针对开发团队长期存在的一个真实挑战,值得进一步探索。

  • 47. Tonic.ai

    Tonic.ai 属于一类日益增长的平台,专注于为开发、测试和 QA 环境生成真实且去标识化的合成数据。与 Synthesized 类似,Tonic.ai 提供一套全面的工具,满足各种数据合成需求,这与 Synthetic Data Vault 更偏向于库的方式形成对比。Tonic.ai 能生成结构化和非结构化数据,在保持生产数据统计属性的同时,通过差分隐私技术确保隐私和合规。其关键功能包括自动检测、分类和去除非结构化数据中的敏感信息,以及通过 Tonic Ephemeral 按需提供数据库环境。此外,Tonic Textual 是一个安全的数据湖解决方案,帮助 AI 开发人员利用非结构化数据支持 检索增强生成(RAG) 系统和 LLM 微调。对于希望在严格的数据隐私要求下加速工程开发并生成可扩展且真实数据的团队,Tonic.ai 是一个值得评估的平台。

  • 48. turbopuffer

    turbopuffer 是一个无服务器的多租户搜索引擎,能够在对象存储上无缝集成向量搜索和全文搜索。我们非常欣赏其架构和设计选择,尤其是在耐久性、可扩展性和成本效率方面的专注。通过将对象存储用作预写日志并保持查询节点的无状态化,它非常适合高规模的搜索工作负载。

    turbopuffer 专为性能和准确性而设计,开箱即可提供高召回率,即使是复杂的基于过滤条件的查询也不例外。它将冷查询结果缓存到 NVMe SSD,并将经常访问的命名空间保存在内存中,从而实现对数十亿文档的低延迟搜索。这使其非常适合大规模文档检索、向量搜索以及检索增强生成(RAG)等 AI 应用。然而,其对对象存储的依赖也带来了查询延迟的权衡,使其在需要无状态分布式计算的工作负载中最为高效。turbopuffer 驱动了诸如 Cursor 这样的大规模生产系统,但目前仅通过推荐或邀请方式获得访问权限。

  • 49. VectorChord

    VectorChord 是一个用于向量相似性搜索的 PostgreSQL 扩展,由 pgvecto.rs 的创建者开发,作为其继任者。它是开源的,与 pgvector 数据类型兼容,并且专为磁盘高效和高性能的向量搜索而设计。它采用 IVF(倒排文件索引)以及 RaBitQ 量化技术,能够实现快速、可扩展且准确的向量搜索,同时显著降低计算需求。与该领域其他 PostgreSQL 扩展一样,它利用了 PostgreSQL 的生态系统,使向量搜索能够与标准事务操作并行执行。尽管 VectorChord 仍处于早期阶段,但对于向量搜索的工作负载,值得您进行评估。

暂缓 ?

  • 50. Tyk hybrid API management

    我们观察到多个团队在使用 Tyk hybrid API management 解决方案时遇到了问题。虽然托管控制平面和自管数据平面的设计理念为复杂的基础设施(如多云和混合云)提供了灵活性,但团队反馈在 Tyk 的 AWS 托管环境中,控制平面发生的故障通常是通过内部发现的,而非由 Tyk 主动检测到,这暴露了 Tyk 在可观测性方面的潜在不足。此外,事故支持的响应速度似乎偏慢,仅通过工单和邮件进行沟通在这些紧急情况下并不理想。同时,团队还反映 Tyk 文档的成熟度不足,尤其在处理复杂场景和问题时,文档往往不能提供足够的指导。此外,Tyk 生态系统中的其他产品似乎也不够成熟。例如,企业开发者门户被报告为不向后兼容,且定制能力有限。特别是在 Tyk 的混合部署场景中,我们建议谨慎使用,并将继续关注其成熟度的发展。

无法找到需要的信息?

 

每期技术雷达中的条目都在试图反映我们在过去六个月中的技术洞见,或许你所搜索的内容已经在前几期中出现过。由于我们有太多想要谈论的内容,有时候不得不剔除一些长期没有发生变化的条目。技术雷达来自于我们的主观经验,而非全面的市场分析,所以你可能会找不到自己最在意的技术条目。

下载 PDF

 

English | Español | Português | 中文

订阅技术雷达简报

 

立即订阅

查看存档并阅读往期内容