gitweixin
  • 首页
  • 小程序代码
    • 资讯读书
    • 工具类
    • O2O
    • 地图定位
    • 社交
    • 行业软件
    • 电商类
    • 互联网类
    • 企业类
    • UI控件
  • 大数据开发
    • Hadoop
    • Spark
    • Hbase
    • Elasticsearch
    • Kafka
    • Flink
    • 数据仓库
    • 数据挖掘
    • flume
    • Kafka
    • Hive
    • shardingsphere
    • solr
  • 开发博客
    • Android
    • php
    • python
    • 运维
    • 技术架构
    • 数据库
  • 程序员网赚
  • bug清单
  • 量化投资
  • 在线查询工具
    • 去行号
    • 在线时间戳转换工具
    • 免费图片批量修改尺寸在线工具
    • SVG转JPG在线工具

云和大型计算如何重塑 HPC

精品微信小程序开发门户,代码全部亲测可用

  • 首页   /  
  • 作者: east
  • ( 页面45 )
大数据开发 3月 30,2023

云和大型计算如何重塑 HPC

大约 25 年前,一些开源技术结合起来形成了一个强大的商业互联网,它终于准备好开展业务并拿走你的钱了。这种开源组合被称为 LAMP 堆栈(Linux、Apache HTTP Server、MySQL 和 PHP/Perl/Python),成为一代开发人员的标准开发堆栈。
现在别看,但我们很可能正处于另一个 LAMP 堆栈时刻的风口浪尖。
然而,这一次的重点不是建立一种新的在线方式来兜售狗粮。取而代之的是,一场新技术复兴正在进行,以解决算法复杂、消耗大量计算资源的大规模工作负载。想想为 COVID-19 接种疫苗、建造新的超音速喷气式飞机或驾驶自动驾驶汽车。科学和工程界正在以前所未有的令人眼花缭乱的速度更快地发展和提供更新的创新。
如何?云。但不仅仅是云。
云对于正在发生的事情的描述可能过于简单。对于这种转变,我们缺乏巧妙的简写,例如互联网的 LAMP 堆栈。有些东西突然解放了博士类型,可以在极其复杂的计算引擎上进行创新,为算法驱动的工作负载提供动力,这些工作负载正在以比早期 Friendster 或 Pets.com 承诺提供的方式更深刻的方式改变我们的生活。
“高性能计算”(HPC) 是与这些工作负载相关的最常见标签。但那是在公共云成为这些新应用程序的可行平台之前。浏览世界上最快的超级计算机 500 强榜单,您会看到越来越多的超级计算机基于公有云。这并非巧合:本地超级计算机和大型 Linux 集群已经存在了几十年(在商业互联网之前),但这种新趋势——有时被称为“大计算”或“深度技术”——在很大程度上依赖于云。
正如咨询公司 BCG 所说,“计算能力的增强和成本的下降以及技术平台的兴起是最重要的贡献者。云计算正在稳步提高性能并扩大使用范围。”
但这个新的“堆栈”不仅仅与云有关。相反,它取决于技术的三大趋势:仿真软件、专用硬件和云的广度和深度迅速增加。这些是当今每个快速发展的研究和科学团队都在利用的技术构建模块,也是为什么出现了数百家初创公司来撼动十年或更长时间前整合的长期垂死行业的原因。
就像 LAMP 堆栈的神奇时刻一样,今天的重要计算/深度技术时刻都是为了提高工程生产力。云对此至关重要,尽管它本身还不够。
以航空航天为例。传统上,航空工程师会依赖本地 HPC 集群来模拟与起飞和着陆相关的所有必要变量,以设计新的超音速喷气式飞机。相比之下,初创航空航天公司直接采用了云计算,其弹性基础架构使他们能够对应用程序进行建模和模拟,而无需在同事后面排队等待高度专业化的 HPC 硬件。构建和维护硬件的时间更少。更多时间进行实验和工程设计。这就是大型计算云方法的美妙之处。
将其与各种模拟软件相结合,可以在实际构建和原型化复杂的物理事物之前对新的创新进行建模。随着摩尔定律耗尽,专用硬件为这些算法复杂的模拟提供动力。云越狱了本地超级计算机和集群的所有这些,使得创建和运行模型、迭代和改进以及在移动到物理原型之前再次运行它们变得容易了一个数量级。 (要明确的是,这种大型计算/深度技术的大部分是关于构建物理事物,而不是软件。)
这个领域的棘手之处在于使它们运行所需的自定义硬件和软件配置以及优化其性能所需的复杂工作流程。这些类型的算法密集型工作负载需要越来越专业的 GPU 和其他更新的芯片架构。正在支付昂贵的博士学位以设计下一个伟大的涡轮机或喷气推进秘方的公司不希望通过强迫他们学习如何使用模拟软件和硬件组合来建立机器来让他们陷入困境。
“15 年前,这个 HPC 领域的任何公司都根据其在本地运行硬件的程度来脱颖而出,并且基本上押注摩尔定律将继续在 x86 架构上逐年提供持续更好的性能,”Joris 说Rescale 首席执行官 Poort 在接受采访时表示。 “如今最重要的是速度和灵活性——确保您的博士在他们的工作中使用最好的模拟软件,使他们免于成为专业大型计算基础设施的专家,这样他们就可以更快地推出新的创新。”
每家公司最终都会在云中使用模拟和专用硬件吗?可能不会。今天,这是火箭、推进、计算生物学、运输系统以及世界上 1% 最难计算挑战的领域。但是,尽管大型计算被用来解决当今最令人讨厌的问题,但我们肯定会看到新一波 Netflix 使用云、模拟软件和专用硬件的这种 LAMP 堆栈组合推翻世界大片。

作者 east
大数据开发 3月 29,2023

Databricks 开源其 Delta Lake 数据湖屋

为了消除数据湖和数据仓库竞争对手的疑虑,Databricks 周二表示,作为 Delta Lake 2.0 版本的一部分,它正在开源所有 Delta Lake API。该公司还宣布将把 Delta Lake 的所有增强功能贡献给 Linux 基金会。
Cloudera、Dremio、谷歌(Big Lake)、微软、甲骨文、SAP、AWS Snowflake、HPE(Ezmeral)和Vertica等Databricks竞争对手对该公司提出批评,质疑Delta Lake是开源还是专有,从而抢走了份额潜在客户,分析师说。
Ventana Research 研究总监 Matt Aslett 表示:“新公告应该为用户提供连续性和清晰度,并有助于消除关于 Delta Lake 是专有还是开源的混淆(部分是由竞争对手引起的)。”
Constellation Research 首席分析师 Doug Henschen 表示,通过这些公告,Databricks 正在平息客户的担忧和竞争批评。
“在竞争性交易中,像 Snowflake 这样的竞争对手会向潜在客户指出 Delta Lake 的某些方面是专有的,”Henschen 说,并补充说 Databricks 客户现在可以相信他们的数据在一个开放平台上,而不是锁定在三角洲湖中。
Databricks 将 Delta Lake 称为数据湖屋,这是一种同时提供存储和分析功能的数据架构,与以本机格式存储数据的数据湖和存储结构化数据(通常以 SQL 格式)的数据仓库的概念形成对比).
随着数据湖市场上越来越多的商业开源项目,Databricks 的 Delta Lake 可能会发现自己面临新的竞争,包括 Apache Iceberg,它为超大的分析表提供高性能查询。
“还有最近开始商业化的开源项目,例如 Apache Hudi 的 OneHouse 以及 Starburst 和 Dremio 都推出了 Apache Iceberg 产品,”Amalgam Insights 首席分析师 Hyoun Park 说。
“随着这些产品的推出,Delta Lake 面临着来自其他开源 lakehouse 格式的压力,要求它在功能上变得更加强大,因为 lakehouse 市场开始分裂,技术人员有多种选择,”Park 补充道。
Ventana 的 Aslett 说,这个领域的许多其他参与者都专注于 Apache Iceberg 作为 Delta Lake 表的替代品。与在行和列中存储数据的传统表相比,增量表可以访问 ACID(原子性、一致性、隔离性和持久性)事务来存储元数据,以帮助加快数据摄取。
4 月,谷歌宣布支持 Big Lake 和 Iceberg,本月早些时候,Snowflake 宣布在私人预览版中支持 Apache Iceberg 表。
Henschen 说,Iceberg 的公告,就像 Databricks 的开源战略一样,旨在吸引潜在客户,他们可能担心只与一家供应商合作,并且担心在未来访问自己的数据会受到阻碍。
Gartner 前研究副总裁 Sanjeev Mohan 表示,面对新的竞争,Databricks 转向开源 Delta Lake 是一个很好的举措。
“Databricks 宣布开源 Delta Lake 的全部功能是推动更广泛采用的极好一步,”Gartner 前大数据和分析研究副总裁 Sanjeev Mohan 说。
该公司表示,Databricks 的 Delta Lake 2.0 将于今年晚些时候全面上市,预计将为数据分析提供更快的查询性能。
Databricks 周二还发布了第二版 MLflow——一个用于管理端到端机器学习生命周期 (MLOps) 的开源平台。
MLflow 2.0 附带 MLflow Pipelines,它根据数据科学家正在构建的模型类型为数据科学家提供预定义的、生产就绪的模板,使他们能够加速模型开发,而无需生产工程师的干预,该公司表示。
据分析师称,MLflow 2.0 将成为数据科学家的一个更成熟的选择,因为机器学习生产仍然是一个具有挑战性的过程,并且将算法模型转换为安全管理资源上的生产级应用程序代码仍然很困难。
“这个领域有许多供应商解决方案,包括 Amazon Sagemaker、Azure Machine Learning、Google Cloud AI、Datarobot、Domino Data、Dataiku 和 Iguazio。但与超大规模计算器和 Databricks 的统一方法相比,Databricks 是一个中立的供应商数据和模型管理是 MLOps 供应商的一个差异化因素,后者专注于模型操作化的编码和生产挑战,”Amalgam 的 Park 说。
Henschen 说,发布 MLflow 2.0 的举措简化了将流媒体和流媒体分析引入生产数据管道的途径,并补充说许多公司都在与 MLOps 作斗争,甚至在成功创建机器学习模型后也失败了。

作者 east
大数据开发 3月 29,2023

什么是数据湖?用于大数据分析的大规模可扩展存储

2011 年,时任商业智能公司 Pentaho 首席技术官的 James Dixon 创造了数据湖一词。他将数据湖与当时流行的数据集市典型的信息孤岛进行了对比:
从那时起,数据湖不断发展,现在与数据仓库竞争大数据存储和分析的份额。各种工具和产品支持在数据湖中进行更快的 SQL 查询,所有三大云提供商都提供数据湖存储和分析。甚至还有新的 Data Lakehouse 概念,它将治理、安全和分析与负担得起的存储相结合。本文深入探讨了数据湖,包括它们是什么、如何使用以及如何确保您的数据湖不会变成数据沼泽。
数据湖本质上是一个单一的数据存储库,它保存您的所有数据,直到它准备好进行分析,或者可能只保存不适合您的数据仓库的数据。通常,数据湖以其本机文件格式存储数据,但数据可能会转换为另一种格式以提高分析效率。拥有数据湖的目标是从数据中提取业务或其他分析价值。
数据湖可以托管图像和视频等二进制数据、PDF 文档等非结构化数据、CSV 和 JSON 文件等半结构化数据,以及通常来自关系数据库的结构化数据。结构化数据对分析更有用,但半结构化数据可以很容易地导入到结构化形式中。通常可以使用智能自动化将非结构化数据转换为结构化数据。
问题不在于您是否需要数据湖或数据仓库;您很可能需要两者,但出于不同的目的。也可以将它们结合起来,我们将很快讨论。首先,让我们看看数据湖和数据仓库之间的主要区别:
数据集市是仅限于来自单个部门或业务单位的数据的分析数据库,与数据仓库相反,数据仓库以适合分析的形式组合了公司的所有关系数据。数据集市通过仅包含与部门相关的数据来提供有效的分析;因此,它们本质上是孤立的。一些人声称孤岛并不重要,因为业务部门不需要被排除的数据。在现实生活中,这通常很重要——总有上级需要基于来自多个业务部门的综合数据的报告。这就是为什么我们目前看到很多数据湖和数据仓库,而很少有数据集市的原因之一。
当您将原始数据存储在数据湖中时,在数据工程师或数据科学家对其进行处理之前,数据可能对业务分析师毫无用处。除了过滤和数据转换之外,数据湖还需要数据目录、数据安全和模式定义。不幸的是,没有这些功能的数据湖的简写术语是数据沼泽。
幸运的是,有很多工具可以帮助过滤和组织数据湖中的数据。例如,您可以通过创建 ORC 格式的 Hive 元存储来解决对架构的需求。设置完成后,元存储通过像 Presto 这样的大规模并行 SQL 引擎支持快速 SQL 查询。 (Optimized Row Columnar 格式是一种压缩的列式存储,针对 Hive 进行了优化,并且可以很好地与 Presto 配合使用。)
Apache Spark 是另一个大规模并行 SQL 引擎。虽然它可以与 ORC 格式一起使用,但它与另一种压缩的列式存储 Parquet 一起使用时效果更好。 Spark 可以对 Parquet 文件执行垂直和水平分区,生成只需要读取必要数据并可以跳过不相关数据的查询计划。
Databricks 是 Spark 和 MLflow 背后的公司,提供他们所谓的数据湖屋。根据 Databricks 的说法,lakehouse 结合了数据仓库和数据湖的最佳特性:
Databricks 开源的 Delta Lake 通过直接对数据湖中的数据提供可靠性和高性能构成了 Lakehouse 的基础。 Databricks Lakehouse Platform 还包括 Unity Catalog,它为数据和 AI 提供细粒度的治理。 Databricks 声称其 Data Lakehouse 提供的性价比是数据仓库的 12 倍。
过去,数据湖是使用商用计算机的 Apache Hadoop 集群和 HDFS(Hadoop 分布式文件系统)在本地实施的。 Hadoop 集群曾经是 Cloudera、Hortonworks 等公司的大生意。 Cloudera 和 Hortonworks 在 2018 年合并,这告诉你一些关于市场方向的信息。
发生变化的是云,特别是超大规模公共云供应商亚马逊网络服务 (AWS)、微软 Azure 和谷歌云平台 (GCP)。这三个云提供商都提供数据湖存储产品:Amazon Simple Storage Service (Amazon S3) 和 Amazon EMR(以前称为 Amazon Elastic MapReduce)、Azure Data Lake Store (ADLS) 和 Google Cloud Storage (GCS)。这三者还提供数据摄取、数据处理、分析和机器学习的服务。与在数据中心管理 Hadoop 集群相比,创建、管理和扩展云数据湖要容易得多,也快得多;权衡是云中的长期运营支出最终将变得巨大。
早些时候,我讨论了使用 Presto 和 Apache Spark 在数据湖上进行更快的 SQL 查询。 SQL 只是分析数据的其中一种方法,尽管它非常重要并且通常是第一步。此外,考虑使用 Power BI、Tableau 或 Qlik 等商业智能工具; Jupyter、Zeppelin 或 Spark 笔记本;机器学习,例如 scikit-learn、SparkML 或 KNIME;和深度学习,例如 TensorFlow 或 PyTorch。
超大规模云供应商拥有自己的分析和机器学习工具,可以连接到他们的数据湖。
Amazon Athena 使用 Presto 和 Hive 对 Amazon S3 中的数据执行 SQL 查询。 Amazon EMR 是一个云大数据平台,用于使用 Apache Spark、Apache Hive 和 Presto 等开源分析框架运行大规模分布式数据处理作业、交互式 SQL 查询和机器学习应用程序。 Amazon SageMaker 是一项完全托管的服务,用于构建、训练和部署机器学习模型。
Azure Data Lake Analytics (ADLA) 是一种较旧的按需(无服务器)分析作业服务,可简化大数据,并使用 U-SQL,即 SQL 加 C#。 ADLA 正在被 Azure Synapse Analytics 取代,这是一种无限的分析服务,将数据集成、企业数据仓库和大数据分析结合在一起。它使您可以使用无服务器或专用选项大规模地按您的条件自由查询数据。 Synapse 结合了数据湖、企业数据仓库和就地运营数据查询功能,可以自动从 ADLA 和数据仓库迁移数据和代码。 Synapse 与 Azure 机器学习、Azure 认知服务和 Power BI 深度集成。
Google Cloud Storage 提供与许多强大的 Google Cloud 服务的原生集成,例如 BigQuery(数据仓库)、Dataproc(Hadoop 生态系统)、Dataflow(无服务器流分析)、Video Intelligence API、Cloud Vision API 和 AI Platform。
总之,您可以非常灵活地选择合适的工具来分析您的数据。
自 Hadoop 集群和 MapReduce 时代以来,数据湖变得更加有用。 Presto 和 Apache Spark 提供比 MapReduce 快得多的 SQL 处理器,这要归功于内存中和大规模并行处理以及基于 Hive 的模式。与商用计算机的本地集群相比,基于云的数据湖更容易创建、管理和扩展。云数据湖与各种分析和人工智能工具紧密集成。

作者 east
大数据开发 3月 28,2023

为什么 Apache Iceberg 将统治云中的数据

云使数据团队能够收集大量数据并以合理的成本进行存储,从而为利用数据湖、数据网格和其他现代架构的新分析用例打开了大门。但是对于非常大量的数据,通用云存储在如何访问、管理和使用这些数据方面也提出了挑战和限制。
云中典型的 blob 存储系统缺乏显示文件之间关系或它们与表的对应方式所需的信息,这使得查询引擎的工作变得更加困难。此外,文件本身并不能使更改表的模式或在其上“时间旅行”变得容易。每个查询引擎必须有自己的如何查询文件的视图。突然之间,看似易于实现的数据架构变得比预期的更难。
这就是将表格格式应用于数据变得非常有用的地方。表格式明确定义了一个表、它的元数据和构成该表的文件。客户端不是在读取数据时应用架构,而是在运行查询之前就已经知道架构。此外,表元数据可以以提供更细粒度分区的方式保存。因此,将表格格式应用于数据可以提供许多优势,例如:
选择要使用的表格格式是一个重要的决定,因为它可以启用或限制可用的功能。在过去的两年里,我们看到 Apache Iceberg 获得了大量支持,这是一种最初由 Netflix 开发的表格格式,于 2018 年作为 Apache 孵化器项目开源,并于 2020 年从孵化器项目中毕业。
Iceberg 的构建是为了解决 Apache Hive 在处理超大数据集时遇到的一些挑战,包括规模、可用性和性能方面的问题。正如 Netflix 工程师当时指出的那样,超大规模数据集的表格格式应该像 SQL 一样可靠且可预测地工作,“没有任何不愉快的意外”。
有多种选择,我们相信 Iceberg 优于其他可用的开放式表格格式。这里有五个原因。
过去会对表格格式今天的工作方式产生重大影响。一些表格格式是从旧技术发展而来的,而另一些表格格式则一刀切。 Iceberg 属于后者。它是从头开始构建的,以解决 Apache Hive 中的缺点,这意味着它避免了过去阻碍数据湖的一些不良特性。如何处理架构更改(例如重命名列)就是一个很好的例子。
展望未来,这也意味着 Iceberg 不需要合理化如何在不导致生产数据应用程序出现问题的情况下进一步脱离相关工具。随着时间的推移,其他表格格式可能会迎头赶上,但截至目前,Iceberg 专注于提供下一组新功能,而不是回顾过去解决旧问题。
通过将处理引擎与表格格式分离,Iceberg 提供了更大的灵活性和更多选择。工程师不必被迫使用一种处理引擎,而是可以选择最适合工作的工具。选择之所以重要,至少有两个关键原因。首先,公司用来处理数据的引擎会随着时间而改变。例如,许多企业从 Hadoop 迁移到 Spark 或 Trino。其次,大型组织使用多种不同的技术是很常见的,并且有选择权使他们能够交替使用多种工具。
Iceberg 还支持多种文件格式,包括 Apache Parquet、Apache Avro 和 Apache ORC。这在今天提供了灵活性,但也为将来可能出现的文件格式提供了更好的长期可插拔性。
Iceberg 项目由 Apache 软件基金会管理,这意味着它遵循几个重要的 Apache Ways,包括赢得权威和共识决策。对于自称为“开源”的每个项目来说,情况不一定如此。 Apache Iceberg 公开其项目管理,因此您知道谁在运行该项目。其他表格格式没有透露谁有决策权。表格格式是数据架构中的基本选择,因此选择真正开放和协作的项目可以显着降低意外锁定的风险。
有几个迹象表明,围绕 Apache Iceberg 的协作社区正在使用户受益,并为项目的长期成功奠定基础。对于用户而言,Slack 频道和 GitHub 存储库显示出很高的参与度,无论是围绕新想法还是对现有功能的支持。至关重要的是,参与来自整个行业,而不仅仅是一个团体或 Iceberg 的原作者。
高度协作也有利于技术本身。该项目正在征求越来越多的提案,这些提案的想法各不相同,可以解决许多不同的用例。此外,该项目正在催生新的项目和想法,例如 Project Nessie、Puffin Spec 和开放元数据 API。
与其他一些表格项目不同,Iceberg 从一开始就内置了以性能为导向的功能,这在几个方面对用户有益。首先,用户通常假设一个具有开放代码的项目包含性能特性,却发现它们不包含在未来或含糊地承诺。其次,如果你想移动工作负载,使用表格格式应该很容易,你不太可能在 Iceberg 实现中遇到实质性差异。第三,一旦你开始使用开源 Iceberg,你就不太可能发现你需要的功能隐藏在付费专区后面。什么是开放的和什么不是开放的之间的区别也不是时间点问题。
作为一个从一开始就开放的项目,Iceberg 的存在是为了解决一个实际问题,而不是一个业务用例。这是一个很小但很重要的区别:拥有为 Iceberg 提供支持的付费产品的供应商,例如 Snowflake、AWS、Apple、Cloudera、Google Cloud 等,可以在他们实施 Iceberg 规范的程度方面展开竞争,但 Iceberg 项目本身无意为特定公司推动业务。
在 Snowflake,我们很早就创建了自己的表格格式,从而启用了各种新功能。但随着企业转向云数据平台,他们的需求和时间表会有所不同。一些公司有限制数据存储位置的监管要求,或者有他们需要保护的现有投资。
支持像 Iceberg 这样的外部表格式使我们的客户能够利用 Snowflake 中的所有数据,即使其中一些数据需要驻留在不同的位置。这就是为什么我们在今年早些时候在 Snowflake 中添加了对 Iceberg 作为附加表选项的支持,并且最近推出了一种名为 Iceberg Tables 的新型 Snowflake 表。
Apache Iceberg 社区中有一些优秀的资源,可用于了解有关该项目的更多信息并参与开源工作。

作者 east
大数据开发 3月 28,2023

如何将 R 与 BigQuery 结合使用

您是否希望将驻留在 Google BigQuery 中的数据作为 R 工作流程的一部分进行分析?多亏了 bigrquery R 包,这是一种非常无缝的体验——一旦你知道在这些数据上运行 dplyr 函数需要一些小的调整。
不过,首先,您需要一个 Google Cloud 帐户。请注意,即使数据在其他人的帐户中并且您不打算存储自己的数据,您也需要自己的 Google Cloud 帐户。
许多人已经拥有用于 Google 云端硬盘或 Gmail 等服务的通用 Google 帐户。如果您还没有,请务必创建一个。
然后,前往 https://console.cloud.google.com 上的 Google Cloud Console,使用您的 Google 帐户登录,并创建一个新的云项目。 R 老手注意:虽然在 RStudio 中工作时项目是个好主意,但在 Google Cloud 中它们是强制性的。
单击新建项目选项以创建新项目。
您应该会在 Google Cloud 顶部导航栏的左侧看到创建新项目的选项。单击“Google Cloud Platform”右侧的下拉菜单(如果您还没有任何项目,它可能会显示“选择项目”)。给你的项目一个名字。如果您已经在您的 Google 帐户中启用了结算功能,您将需要选择一个结算帐户;如果你不这样做,那可能不会作为一个选项出现。然后点击“创建”。
如果您不喜欢分配给项目的默认项目 ID,可以在单击“创建”按钮之前对其进行编辑。
如果你不喜欢为你的项目自动生成的项目 ID,你可以编辑它,假设你没有选择已经采取的东西。
完成新项目设置后,您会看到一个通用的 Google Cloud 仪表板,它看起来有点让人不知所措。这些都是什么?BigQuery 在哪里?您可能不需要担心大多数其他服务,但您确实希望能够在所有这些服务中轻松找到 BigQuery。
如果您只想使用一项服务,初始的 Google Cloud 主屏幕可能会有点让人不知所措。 (我已经删除了这个项目。)
一种方法是将 BigQuery“固定”到左侧导航菜单的顶部。 (如果您没有看到左侧导航,请单击左上角的三行“汉堡包”将其打开。)一直向下滚动,找到 BigQuery,将鼠标悬停在它上面,直到您看到一个图钉图标,然后单击图钉。
向下滚动到 Google Cloud 主屏幕左侧导航的底部,找到 BigQuery 服务。您可以通过将鼠标悬停在上面来“固定”它,直到看到固定图标,然后单击它。
现在,BigQuery 将始终显示在您的 Google Cloud Console 左侧导航菜单的顶部。向上滚动,您会看到 BigQuery。单击它,您将进入带有项目名称的 BigQuery 控制台,其中没有任何数据。
如果“编辑器”选项卡没有立即可见,请单击右上角的“编写新查询”按钮。
怎么办?人们通常通过使用可用的公共数据集来开始学习 BigQuery。您可以将其他用户的公共数据项目固定到您自己的项目中,包括一套由 Google 收集的数据集。如果您在您一直使用的同一个 BigQuery 浏览器选项卡中转到此 URL,Google 公共数据项目应该会自动将自己固定到您的项目。
感谢 GitHub 上的 JohannesNE 提供此提示:您可以使用下面显示的 URL 结构固定您可以访问的任何数据集。
如果这不起作用,请检查以确保您使用的是正确的 Google 帐户。如果您在浏览器中登录了多个 Google 帐户,您可能会被发送到与预期不同的帐户。
固定项目后,单击该固定项目名称左侧的三角形(在本例中为 bigquery-public-data),您将看到该项目中可用的所有数据集。 BigQuery 数据集就像一个传统的数据库:它有一个或多个数据表。单击数据集旁边的三角形以查看它包含的表格。
单击 BigQuery 网络界面中的表,您可以查看其架构,以及用于预览数据的选项卡。
单击表名以查看其架构。还有一个“预览”选项卡,可让您查看一些实际数据。
还有其他更少点击式的方法来查看您的数据结构。但首先….
BigQuery 对数据存储和数据查询都收费。当使用其他人创建的数据集时,他们需要为存储付费。如果您在 BigQuery 中创建和存储自己的数据,则需要付费——无论您是唯一一个使用它的人、与其他几个人共享数据还是将其公开,费率都是一样的。 (您每月可获得 10 GB 的免费存储空间。)
请注意,如果您对其他人的数据进行分析并将结果存储在 BigQuery 中,则新表将成为您的存储分配的一部分。
查询的价格基于查询处理的数据量而不是返回的数据量。这个很重要。如果您的查询在分析 4 GB 数据集后仅返回前 10 个结果,则该查询仍将使用您的 4 GB 数据分析配额,而不仅仅是与您的 10 行结果相关的少量数据。
您每月免费获得 1 TB 的数据查询;为分析而处理的每额外 TB 数据的成本为 5 美元。
如果你直接在数据上运行 SQL 查询,谷歌建议永远不要运行 SELECT * 命令,它会遍历所有可用的列。相反,只选择您需要减少需要处理的数据的特定列。这不仅可以降低您的成本;它还使您的查询运行得更快。我对我的 R dplyr 查询做同样的事情,并确保只选择我需要的列。
如果您想知道如何在查询运行之前知道您的查询将使用多少数据,答案很简单。在 BigQuery 云编辑器中,您可以在不运行查询的情况下键入查询,然后查看它将处理多少数据,如下面的屏幕截图所示。
使用 Web 界面中的 BigQuery SQL 编辑器,您可以在其数据集和项目下找到您的表。在不运行查询的情况下键入查询会显示它将处理多少数据。请记住在查询中使用 `projectname.datasetname.tablename`
即使您不了解 SQL,您也可以通过简单的 SQL 列选择来了解 R 中的成本,因为任何额外的过滤或聚合都不会减少分析的数据量。
因此,如果您的查询运行在 table-id 中名为 columnA、columnB 和 columnC 的三个列上,并且 table-id 在 dataset-id 中,它是 project-id 的一部分,您只需在查询编辑器中键入以下内容:
不要运行查询,只需键入它,然后查看右上角的行以查看将使用多少数据。无论您的 R 代码将对该数据做什么,都不会影响查询成本。
在上面的屏幕截图中,您可以看到我从 schedules 表中选择了三列,这是棒球数据集的一部分,是 bigquery-public-data 项目的一部分。
对元数据的查询是免费的,但您需要确保正确构建查询以符合查询条件。例如,使用 SELECT COUNT(*) 获取数据集中的行数是不收费的。
您还可以采取其他措施来限制成本。有关更多提示,请参阅 Google 的“控制 BigQuery 中的成本”页面。
不,您不需要信用卡即可开始使用 BigQuery。但是如果不启用计费,您的帐户就是一个 BigQuery“沙盒”,并非所有查询都有效。我强烈建议向您的帐户添加计费来源,即使您极不可能超出免费 BigQuery 分析的配额。
现在——终于! — 让我们看看如何使用 R 进入 BigQuery。
我将在本教程中使用 bigrquery 包,但您可能还需要考虑其他选项,包括 obdc 包或 RStudio 的专业驱动程序及其企业产品之一。
要使用 R 和 bigrquery 查询 BigQuery 数据,您首先需要使用以下语法建立与数据集的连接:
第一个参数是 bigrquery 包中的 bigquery() 函数,它告诉 dbConnect 您想要连接到 BigQuery 数据源。其他参数概述了项目 ID、数据集名称和计费项目 ID。
(连接对象几乎可以被称为任何东西,但按照惯例,它们通常被命名为 con。)
下面的代码加载 bigrquery 和 dplyr 库,然后创建与棒球数据集中的时间表表的连接。
bigquery-public-data 是项目参数,因为那是数据集所在的地方。 my_project_id 是计费参数,因为我的项目的配额将针对查询“计费”。
当我运行这段代码时,除了创建一个连接变量外,什么也没发生。但我第一次尝试使用该连接时,系统会要求我在浏览器窗口中验证我的 Google 帐户。
例如,要列出棒球数据集中所有可用的表,我会运行以下代码:
要在 R 中查询一个特定的 BigQuery 表,请使用 dplyr 的 tbl() 函数创建一个引用该表的表对象,例如使用我新创建的棒球数据集连接的时间表表:
如果您使用基本 R str() 命令检查 sked 的结构,您将看到一个列表,而不是数据框:
幸运的是,像 glimpse() 这样的 dplyr 函数通常可以与这种类型的对象(类 tbl_BigQueryConnection)无缝地工作。
运行 glimpse(skeds) 将主要返回您所期望的——除了它不知道数据中有多少行。
这告诉我 glimpse() 可能不会解析整个数据集——这意味着它很有可能不会增加查询费用,而是查询元数据。当我在运行该命令后检查我的 BigQuery Web 界面时,确实没有查询费用。
您可以对表对象运行 dplyr 命令,其方式与对传统数据框的操作方式几乎相同。但您可能还需要一个补充:将通常的 dplyr 工作流程的结果通过管道传输到 collect() 函数中。
下面的代码使用 dplyr 查看 skeds 表对象中的年份和主队,并将结果保存到 tibble(tidyverse 软件包套件使用的特殊类型的数据框)。
定价说明:我使用寻求相同信息的 SQL 语句检查了上述查询:
当我这样做时,BigQuery Web 编辑器显示只处理了 21.1 KiB 的数据,不超过 10 MB。为什么我的账单多了这么多?查询最小为 10 MB(并四舍五入到下一个 MB)。
旁白:如果您想将 R 查询的结果存储在临时 BigQuery 表而不是本地数据框中,您可以将 compute(name = “my_temp_table”) 添加到管道的末尾而不是 collect()。然而,你需要在一个你有权创建表的项目中工作,而谷歌的公共数据项目绝对不是那个。
如果您在没有 collect() 的情况下运行相同的代码,例如
您正在保存查询而不是查询的结果。请注意,available_teams 现在是一个具有类 tbl_sql、tbl_BigQueryConnection、tbl_dbi 和 tbl_lazy 的查询对象(惰性意味着它不会运行,除非特别调用)。
您可以在脚本中单独使用对象名称来运行保存的查询:
您可以在链式管道的末尾使用 show_query() 看到由 dplyr 语句生成的 SQL:
您可以将此 SQL 剪切并粘贴到 BigQuery 网络界面中,以查看您将使用多少数据。只需记住将普通表名(如“schedules”)更改为语法“project.dataset.tablename”;在这种情况下,`bigquery-public-data.baseball.schedules`。
如果您在 R 会话中第二次运行完全相同的查询,您将不会再次为数据分析付费,因为 BigQuery 将使用缓存的结果。
如果您习惯于编写 SQL 查询,并且想从 BigQuery 中提取数据作为更大的 R 工作流的一部分,则还可以在 R 中运行 SQL 命令。
例如,假设您要运行此 SQL 命令:
您可以使用 DBI 包的 dbGetQuery() 函数在 R 中执行此操作。这是代码:
请注意,我再次为该查询付费,因为 BigQuery 不认为 R 中的一个查询和 SQL 中的另一个查询完全相同,即使它们正在寻找相同的数据。
如果我再次运行该 SQL 查询,我就不会被收费。
在一次性初始设置之后,在 R 中分析 BigQuery 数据就像在本地数据帧上运行 dplyr 代码一样容易。请记住您的查询成本。如果您在 10 GB 的数据集上运行十几个查询,您将不会接近达到 1 TB 的每月免费配额。但是,如果您每天都在处理更大的数据集,那么有必要研究一下简化代码的方法。

作者 east
运维 3月 28,2023

减少云费用的 12 个编程技巧

没有什么比观看应用程序病毒式传播更能让开发团队精神振奋的了。这是一种美妙的感觉——至少,在每月的云账单到来之前是这样。一些开发人员认为,管理计算成本是 devops 团队的责任。编码人员编写软件,将其扔到墙上,然后让其他人担心为此付费。没有东西会离事实很远。
聪明的开发人员知道他们的编码决策对公司的底线有很大的影响。庞大的代码速度较慢,需要更多的云资源才能运行。选择更好的算法和编写更紧凑的代码不仅仅关乎速度。编写良好的代码运行成本更低。
开发人员并不总能看到这种联系。在您自己的机器上编写代码很容易,RAM 和额外的磁盘空间是在购买机器时支付的。如果您有 2 TB 的磁盘空间,您可能不会注意到您的代码占用了多少空间。如果一个新的算法需要两倍的时间来运行,你的桌面可能甚至不会闪烁——而且,谁会注意到多了几毫秒?但几乎可以肯定的是,将计算量增加一倍将导致更大的云计算费用。
现代云计算擅长将资源利用率转化为订单项费用。优秀的云开发人员明白,他们有能力在编写代码时做出更明智的决策。它可以像运行分析器来识别慢点一样简单,或者避免不必要的数据存储以减少内存占用。
这里有 12 种方法可以简化您的代码,使其运行起来更精简、更快、成本更低。
大多数开发人员不会花太多时间优化他们的代码。如果它在他们的笔记本电脑上瞬间运行,他们不会注意到随着时间的推移它的运行速度是否慢了 20%、30% 甚至 300%。该程序仍在瞬间响应。但是当它们在服务器上出现数百万次时,这些差异就会加起来。仔细的分析可以标记缓慢的部分。重写它们可以减少应用程序需要的实例数。
使用的 RAM 量是为云实例定价的一个重要参数。在许多情况下,将 RAM 增加一倍也会使成本增加一倍。程序员可以通过避免将数据保存在内存中来减少他们的 RAM 占用空间。一些流算法,如 Java 的 Stream 类,设计用于处理大型数据文件,而无需将它们全部加载到内存中。 Apache DataSketches 项目在不占用所有内存的情况下,为复杂的大数据统计生成近似答案。
作为一个附带的好处,谨慎的 RAM 消耗也可以加速你的算法。有时,操作系统会开始使用虚拟内存将数据卸载到磁盘上。这可以防止崩溃,但会显着降低程序速度。
使用较低分辨率的图像和视频可以通过多种方式获得回报。首先,存储它们会更便宜。其次,任何数据泄露费用都会降低。第三,该应用程序对用户来说似乎更快捷。
所有的静态图像应该从一开始就最小化。唉,最小化的数量并不简单,因为在某些时候视觉质量下降到足以让用户察觉。找到正确的权衡是一些程序员不准备做出的设计决定。
某些使用上传图像的应用程序还可以在接收到图像后创建更小的缩略图和分辨率降低的版本。为此开发了像 ImageMagik 这样的工具包和像 WebP 这样的格式。
许多开发人员都是数字包装老鼠,他们存储信息以备不时之需。他们用无穷无尽的列填写表格,然后从不删除行。如果您拥有硬件并且磁盘驱动器有足够的空间,那么额外的数据不会花费任何费用。但是云对一切都收费。您将来真的需要所有这些价值吗?用户还想要那么多细节吗?转储一些旧数据将为您节省数据存储和泄露方面的资金。
在云实例上使用本地磁盘不仅危险,而且成本高昂。本地磁盘空间通常设计得足够快以保持操作系统高效运行。许多开发人员在具有 1 TB 或更多 TB 存储空间的个人计算机上创建他们的代码。云机器存储很少如此便宜或容易获得。云通常根据大小直接为存储计费,因此最好的方法是尽可能少地使用存储。不仅要考虑最小化应用程序创建的临时文件的方法,还要考虑最小化所需的系统库和软件包的方法。
日志文件非常适合在开发过程中识别问题和调试软件。但是一旦代码投入生产,您就不需要保留所有这些代码。所有额外的信息都会阻塞本地磁盘或对象存储。在设计日志系统时,将其配置为经常删除日志。许多日志包如 Log4j 可以设置为保留最少数量的日志并滚动删除它们。
无服务器架构计划仅在您的代码运行时计费,这可以在负载间歇性时为您节省大量资金。即使是拥有源源不断的用户流的应用程序,其停滞时间也比您预期的要长。
许多无服务器定价计划奖励仔细的编码和非常快的性能以及最小的 RAM 消耗。计费公式以毫秒为单位计算响应时间,并且只对处理器被占用的时间收费。作为开发人员,您会立即获得反馈,因为您可以直接跟踪响应时间并查看您的代码更改如何影响它。
无服务器方法非常适合较小或更多实验项目,而且费用通常低至每月几美分。如果您的应用程序只是偶尔运行某些功能,那么使用无服务器可能是有意义的。
随着数据变老,访问频率降低。您可以通过将应用程序设置为将旧数据迁移到更便宜的位置来预见这一点。一些云对所谓的“冷存储”收费要低得多,这可能需要几分钟甚至几小时才能交付数据。其他云,如 Wasabi 或 Backblaze,专门为 Amazon S3 对象提供归档存储,收费远低于主要云。在某些情况下,他们甚至不对数据泄露收费。一旦不再需要大量数据就卸载数据可能非常具有成本效益。
如果你看过一些框架生成的 HTML 标签,你就会知道布局会变得多么可笑。它只是一直向下嵌套到 DIV 标签中的 DIV 标签——这需要花钱来生成和交付。我认识的一位网页设计师吹嘘说,通过更明智地使用 CSS 创建更简单的布局,他们的带宽费用就减少了 30%。
像 React 这样的一些框架需要相当多的计算能力,尤其是当它们使用服务器端渲染等功能时。所有这些代码推高了每月的云账单。相反的理念是创建一个静态站点,该站点由缓存逐字提供的不变的 HTML、CSS 和 JavaScript 块构建。通过将缓存移至更靠近用户的位置,使用内容分发网络可以进一步加快分发速度。
各种框架都接受这种静态哲学。 Jekyll、Hugo、Gridsome 和 Pelican 只是将您的所有内容打包到一组紧凑、不变的文件中的几个工具。您仍然可以使用 AJAX 调用在页面中构建个性化设置,但网站的大部分内容在服务器上产生的负载很小。
随着浏览器变得越来越强大,一些框架使得将更多计算直接转移到客户端变得更加简单。好的 JavaScript 或 WebAssembly 代码可以将更多的负载推到用户的机器上,并从您的云服务器上卸下。一些开发人员正在将他们的云层减少到只不过是一个带有一些用于身份验证的业务逻辑的数据库。一位朋友使用静态 HTML 和服务器端版本的 PostgreSQL 运行一切,其中嵌入了输出 JSON 的过程。
浏览器还有更精细的选项用于在本地存储信息,例如 HTML Web 存储标准和 W3C 索引数据库 API。不再只是短字符串和 cookie。由于这些数据不通过互联网传输,因此可以更快地获得这些数据,并且让用户放心,因为他们知道自己的数据没有存储在一个集中的、可破解的数据库中。当数据可以免费存在于用户的机器上时,为什么还要为数据存储和泄露付费?
一些开发人员专门处理数据库。有些人喜欢用精心设计的前端创造美好的第一印象。现在云成本如此灵活,一些团队正式任命“成本工程师”来管理代码成本和效率。成本工程师的首要关注点是让应用程序代码运行得更干净、更快、更轻便,从而更便宜。将此任务作为某人工作的一部分传达了一个信息,即管理代码成本作为开发团队角色和责任的一部分的重要性。

作者 east
Tensorflow 3月 27,2023

什么是 TensorFlow?机器学习库解释

机器学习是一门复杂的学科,但实施机器学习模型远没有过去那么令人生畏,这要归功于机器学习框架——例如谷歌的 TensorFlow——简化了获取数据、训练模型、提供预测和完善未来结果的过程.
TensorFlow 由 Google Brain 团队创建,最初于 2015 年向公众发布,是一个用于数值计算和大规模机器学习的开源库。 TensorFlow 将大量机器学习和深度学习模型和算法(也称为神经网络)捆绑在一起,并通过常见的编程隐喻使它们变得有用。它使用 Python 或 JavaScript 为构建应用程序提供方便的前端 API,同时在高性能 C++ 中执行这些应用程序。
TensorFlow 与 PyTorch 和 Apache MXNet 等框架竞争,可以训练和运行深度神经网络,用于手写数字分类、图像识别、词嵌入、递归神经网络、用于机器翻译的序列到序列模型、自然语言处理,以及基于 PDE(偏微分方程)的模拟。最重要的是,TensorFlow 支持大规模生产预测,使用与训练相同的模型。
TensorFlow 还有一个广泛的预训练模型库,可以在您自己的项目中使用。您还可以使用 TensorFlow Model Garden 中的代码作为训练您自己的模型的最佳实践示例。
TensorFlow 允许开发人员创建数据流图——描述数据如何通过图或一系列处理节点移动的结构。图中的每个节点代表一个数学运算,节点之间的每个连接或边都是一个多维数据数组或张量。
TensorFlow 应用程序可以在大多数任何方便的目标上运行:本地机器、云中的集群、iOS 和 Android 设备、CPU 或 GPU。如果您使用谷歌自己的云,您可以在谷歌定制的 TensorFlow 处理单元 (TPU) 芯片上运行 TensorFlow 以进一步加速。不过,由 TensorFlow 创建的结果模型可以部署在大多数用于提供预测服务的设备上。
2019 年 10 月发布的 TensorFlow 2.0 根据用户反馈以多种方式改进了框架,使其更易于使用(例如,通过使用相对简单的 Keras API 进行模型训练)和更高的性能。得益于新的 API,分布式训练更容易运行,并且对 TensorFlow Lite 的支持使得在更多种类的平台上部署模型成为可能。但是,必须重写为早期版本的 TensorFlow 编写的代码——有时只是轻微重写,有时是重写——以最大限度地利用新的 TensorFlow 2.0 功能。
经过训练的模型可用于通过使用 REST 或 gRPC API 的 Docker 容器将预测作为服务提供。对于更高级的服务场景,您可以使用 Kubernetes
TensorFlow 通过 Python 语言为程序员提供了所有这些。 Python 易于学习和使用,它提供了方便的方法来表达如何将高级抽象耦合在一起。 TensorFlow 在 Python 3.7 到 3.10 版本上受支持,虽然它可以在 Python 的早期版本上工作,但不能保证这样做。
TensorFlow 中的节点和张量是 Python 对象,TensorFlow 应用程序本身就是 Python 应用程序。然而,实际的数学运算并不是在 Python 中执行的。通过 TensorFlow 可用的转换库被编写为高性能 C++ 二进制文件。 Python 只是在各个部分之间引导流量,并提供高级编程抽象以将它们连接在一起。
TensorFlow 中的高级工作——创建节点和层并将它们链接在一起——使用 Keras 库。 Keras API 表面上很简单;一个三层的基本模型可以用不到 10 行代码定义,而同样的训练代码只需要多几行代码。但是如果你想“揭开面纱”并做更细粒度的工作,比如编写你自己的训练循环,你可以这样做。
一般来说,Python 是使用 TensorFlow 和机器学习的最流行的语言。但 JavaScript 现在也是 TensorFlow 的一流语言,而 JavaScript 的巨大优势之一是它可以在任何有网络浏览器的地方运行。
TensorFlow.js,作为 JavaScript TensorFlow 库的名称,使用 WebGL API 通过系统中可用的任何 GPU 来加速计算。也可以使用 WebAssembly 后端来执行,如果你只在 CPU 上运行,它比常规的 JavaScript 后端更快,尽管最好尽可能使用 GPU。预建模型让您可以启动并运行简单的项目,让您了解事情是如何运作的。
经过训练的 TensorFlow 模型也可以部署在边缘计算或移动设备上,例如 iOS 或 Android 系统。 TensorFlow Lite 工具集优化 TensorFlow 模型以在此类设备上良好运行,允许您在模型大小和准确性之间进行权衡。较小的模型(即 12MB 与 25MB,甚至 100+MB)的准确性较低,但准确性损失通常很小,并且被模型的速度和能效所抵消。
TensorFlow 为机器学习开发提供的最大好处是抽象。开发人员无需处理实现算法的具体细节,或找出将一个函数的输出连接到另一个函数的输入的正确方法,而是可以专注于整体应用程序逻辑。 TensorFlow 会处理幕后的细节。
TensorFlow 为需要调试和自省 TensorFlow 应用程序的开发人员提供了额外的便利。每个图形操作都可以单独和透明地评估和修改,而不是将整个图形构建为一个不透明的对象并立即对其进行评估。这种所谓的“急切执行模式”在旧版本的 TensorFlow 中作为一个选项提供,现在已成为标准。
TensorBoard 可视化套件让您可以通过基于 Web 的交互式仪表板检查和分析图形的运行方式。 Tensorboard.dev(由 Google 托管)服务可让您托管和共享用 TensorFlow 编写的机器学习实验。它可以免费使用,最多可存储 100M 标量、1GB 张量数据和 1GB 二进制对象数据。 (请注意,托管在 Tensorboard.dev 中的任何数据都是公开的,因此不要将其用于敏感项目。)
TensorFlow 还从谷歌一流商业机构的支持中获得了许多优势。 Google 推动了该项目背后的快速开发步伐,并创建了许多重要的产品,使 TensorFlow 更易于部署和使用。上述用于在谷歌云中加速性能的 TPU 芯片只是一个例子。
TensorFlow 实现的一些细节使得某些训练作业很难获得完全确定的模型训练结果。有时,在一个系统上训练的模型与在另一个系统上训练的模型会略有不同,即使它们被输入完全相同的数据。造成这种差异的原因很微妙——一个原因是随机数的播种方式和位置;另一个与使用 GPU 时的某些非确定性行为有关。 TensorFlow 的 2.0 分支有一个选项,可以通过几行代码在整个工作流中启用确定性。但是,此功能会以性能为代价,并且只能在调试工作流时使用。
打破围绕机器学习和人工智能的炒作,我们的小组讨论了该技术的定义和含义。
TensorFlow 与许多其他机器学习框架竞争。 PyTorch、CNTK 和 MXNet 是解决许多相同需求的三个主要框架。

作者 east
mysql 3月 27,2023

Google 的 Logica 语言解决了 SQL 的缺陷

谷歌推出了开源 Logica 编程语言,这是一种逻辑编程语言,旨在通过使用数学命题逻辑而非自然语言的语法来“解决 SQL 问题”。
作为谷歌 Yedalog 语言的后继者,Logica 于 4 月 12 日推出,是一种类似于 Datalogic 的逻辑语言。面向工程师、数据科学家和其他专家,它将代码编译为 SQL 并在基于云的 Google BiqQuery 数据仓库上运行,并提供对 PostgreSQL 和 SQLite 的实验性支持。但与 SQL 不同,Logica 更简洁并且支持可重用的抽象。它还支持模块和导入,可以从交互式 Python 笔记本中使用,并使测试查询变得简单自然,谷歌开发人员在一篇博客文章中写道。
Logica 通过使用数理逻辑语法而不是自然英语语言来解决 SQL 问题。谷歌列举了 SQL 的问题,例如从英文单词构建语句的冗长和对抽象的有限支持。 Logica 扩展了经典的逻辑编程语法,特别是聚合。它被宣传为一种用于数据操作的声明性语言。
Logica 开源项目背后的 Google 开发人员鼓励在以下场景中使用它:
Google 设立了一个教程来帮助开发者学习 Logica。要在 Google Cloud BigQuery 上运行逻辑程序,开发人员需要打开一个 Google Cloud 项目。项目建立后,开发者可以通过提供项目 ID 在 Colab 中运行 Logica 程序。要在本地运行 Logica,开发人员需要 Python 3。

作者 east
人工智能 3月 27,2023

人工智能的问题和前景:不只需要数据,更需要和人类智慧合作

人工智能 (AI) 的问题和前景是人。这一直是正确的,无论我们对机器人霸主接管的希望(和恐惧)是什么。在人工智能和更普遍的数据科学中,诀窍是融合人类和机器的优点。一段时间以来,人工智能行业的啦啦队倾向于强调等式的机器方面。但正如 Spring Health 数据科学家 Elena Dyachkova 所暗示的那样,数据(及其背后的机器)只有在解读数据的人是否聪明时才有用。换句话说,数据不是自我解释的,而是需要人类的智慧和判断来赋予它意义和价值。

Dyachkova 正在回复 Amplify Partners 的普通合伙人和 Mattermark 前数据主管 Sarah Catanzaro 的评论。在讨论不完善的数据和分析在决策制定中的效用时,Catanzaro 说,“我认为数据社区常常忽略了有缺陷但方向正确的报告和分析的价值。”然后她继续争辩说,“许多决定不需要高精度的洞察力;在许多情况下,我们不应该回避快速和肮脏的事情。”这是一个很好的提醒,我们不需要完美的数据来做出决定。事实上,追求完美可能会导致分析瘫痪,浪费时间和资源,而错过重要的机会。

那挺好的。 Gary Marcus 是 Geometric Intelligence 的科学家和创始人,Geometric Intelligence 是一家机器学习公司,于 2016 年被 Uber 收购,他坚持认为,欣赏 AI 及其子集机器学习和深度学习的关键是认识到这种模式识别工具处于“最佳状态”当我们需要的只是粗略的结果时,赌注很低,完美的结果是可选的。”尽管如此,在我们寻求更强大的 AI 驱动的应用程序的过程中,我们一直在寻找越来越多的数据,期望只要有足够的数据,机器学习模型就会以某种方式为我们提供比“粗略的结果”更好的结果。唉!它在现实世界中根本行不通。

虽然更多的数据可能很好,但对于许多应用程序来说,我们并不需要更多的数据。相反,我们需要人们更好地理解我们已有的数据。正如 Dyachkova 指出的那样,“产品分析 80% 是快速而肮脏的。但是判断什么时候快和脏是合适的能力需要对统计数据有很好的理解。”了解? Indeed.com 的数据科学家文森特道林 (Vincent Dowling) 更清楚地说明了这一点:“成为一名经验丰富的分析师/科学家的很多价值在于确定做出决定所需的严谨程度。”他们都在谈论如何做出决策,在这两种情况下,查看数据的人的体验比数据本身更重要。机器永远无法弥补操作它们的人的悟性不足。正如《卫报》的一篇社论所言,“人工智能的前景在于,它将赋予机器从数据中发现模式的能力,并比人类更快更好地做出决策。如果他们更快地做出更糟糕的决定会怎样?”这是一个非常现实的可能性,如果人们放弃所有权,认为数据和机器会以某种方式为自己说话。这也是一个非常危险的可能性,如果我们不考虑数据和算法可能存在的偏见、错误和限制。

让人们负责在实践中并不是那么容易实现的。正如 Gartner Research 副总裁 Manjunath Bhat 所说,人工智能受人类输入的影响,包括我们选择输入机器的数据。反过来,我们算法的结果会影响我们做出决策所依据的数据。 “人们以数据的形式消费事实。然而,数据可以被突变、转换和更改——所有这些都是为了使其易于使用。我们别无选择,只能生活在高度情境化的世界观范围内。”亚马逊应用科学家 Eugene Yan 认为,对于一个成功的机器学习项目,“你需要数据。您需要一个强大的管道来支持您的数据流。最重要的是,你需要高质量的标签。”但如果没有经验丰富的人,就无法正确标记这些数据。要很好地标记它,您需要了解数据。这让人回想起十年前 Gartner 分析师 Svetlana Sicular 提出的观点:企业中到处都是了解其业务细微差别的人。他们最有能力针对公司的数据找出正确的问题类型。他们可能缺乏的是 Dyachkova 指出的对统计、数学和特定公司业务的基本理解——知道什么时候“足够好”的结果实际上足够好的能力。

当然,这就是数据科学困难的原因。在每项关于采用 AI/ML 的主要障碍的调查中,“人才”总是位居榜首。有时我们认为这是因为数据科学人才短缺,但也许我们应该担心缺乏对统计、数学和特定公司业务的基本理解。或者更准确地说,我们应该担心缺乏能够沟通、合作和教育其他人这些基本理解的人才。数据科学不是一个孤立或专门化的领域,而是一个需要跨部门和跨职能协作和共享知识和见解的领域。因此,我们需要培养那些不仅擅长处理数据和机器,而且擅长与其他人交流和合作的人才。

作者 east
人工智能 3月 27,2023

研究人员对AI未来发展期望的未来有多糟糕?

在我们去年的调查中,我们询问了出版机器学习研究人员,他们如何将高级机器智能未来影响的概率划分为五个桶,从“非常好(例如人类繁荣的快速增长)”到“非常糟糕(例如人类灭绝)。1 中位数受访者将 5% 放在最差的桶上。但是整个分布是什么样的呢?这是每个人的答案,按照最差桶的概率排列:
(由于所选软件的限制,列宽可能会变形或列可能会丢失。)
这基本上是 2016 年调查的结果(尽管在乐观情绪相同时看起来排序略有不同),因此您可以看到情况发生了怎样的变化:
2016 年调查的分布。 (由于所选软件的限制,列宽可能会变形或列可能会丢失。)
对我来说最显着的变化是末尾新的大黑条:认为极端糟糕的结果至少有 50% 的人在六年内从人口的 3% 增加到 9%。
以下是 2022 年图表中不同场景的总体区域(相当于平均值):

非常好:24%
总的来说不错:26%
或多或少中性:18%
总的来说不好:17%
极差:14%

也就是说,在他们之间,这些研究人员将 31% 的信任度放在了人工智能让世界变得更糟这一点上。
在查看这些时要记住一些事情:

如果你听到“中位数 5%”,那是指处于意见范围中间的研究人员如何认为有 5% 的可能性出现极坏的结果。 (这并不意味着“大约 5% 的人预计会出现极其糟糕的结果”,这不会那么令人担忧。)将近一半的人处于 10% 或更高的水平。
上面的问题并没有具体问人类灭绝,所以你可能想知道“非常糟糕”是否包括很多比人类灭绝更糟糕的场景。为了核实,我们在 2022 年增加了两个明确关于“人类灭绝或类似的人类物种永久和严重丧失权力”的问题。对于这些,中位数研究人员也给出了 5% 和 10% 的答案。所以我的猜测是,这个问题中有很多非常糟糕的桶都指向人类灭绝的灾难水平。
你可能想知道受访者是否是因为担心人工智能风险而被选中的。我们试图通过通常提供资金来完成调查(经过一些实验后,最后一轮的调查者为 50 美元)并在邀请中以非常广泛的术语描述该主题(例如,不提及人工智能风险)来减轻这种可能性。我们更详细地检查了上次调查——请参阅 2016 年调查论文中的“我们的样本是否具有代表性?”。

这又是 2022 年的数据,但按整体乐观到悲观的程度排序,而不是具体出现极坏结果的概率:
(由于所选软件的限制,列宽可能会变形或列可能会丢失。)
有关更多调查要点,请参阅此博客文章。对于我们迄今为止提供的所有数据,请参阅此页面。
有关更多详细信息,请参见此处。
感谢 Harlan Stewart 帮助制定了这些 2022 年的数据,感谢 Zach Stein-Perlman 总体上整理了这些数据,感谢 Nathan Young 指出像这样的数据会很好。
笔记
完整的问题:

出于此问题的目的,假设 HLMI 将在某个时候存在。从长远来看,您认为这对人类的整体影响会有多积极或消极?请回答您发现以下几种影响的可能性有多大,概率相加为 100%:
______ 非常好(例如人类繁荣的快速增长)(1)
______ 总的来说不错 (2)
______ 或多或少是中性的 (3)
______ 总的来说不好 (4)
______ 非常糟糕(例如人类灭绝)(5)

作者 east
chatgpt 3月 26,2023

ChatGPT 有多受欢迎?第 2 部分:比 Pokémon GO 增长更慢

ChatGPT 报道的一个主要主题是其用户群的快速增长。一个普遍的说法是,它打破了记录,不到一周的时间就拥有了超过 100 万的用户,不到两个月的时间就拥有了 1 亿的用户。它似乎没有打破记录,但我确实认为 ChatGPT 的增长是一个异常值。
检查索赔
ChatGPT增长
据我所知,ChatGPT 在不到一周内拥有 100 万用户的说法的唯一来源来自 OpenAI 首席执行官 Sam Altman 的这条推文:

我看不出有任何理由强烈怀疑这是准确的,但请记住,这是一个有动机推销产品的人的不准确陈述,因此它可能是错误的或误导性的。
许多新闻媒体都报道了它在两个月内达到 1 亿用户的说法,这些媒体似乎都在 Similarweb 的数据中触底。我找不到详细的报告,但看起来他们在付费专区后面有更多数据。我认为暂时接受这种说法是合理的,但同样,它可能在某些方面与媒体报道的有所不同1。

我看到人们分享图表,显示各种应用程序和服务随时间变化的用户数量。这是一个相当夸张的例子:

这是一条令人印象深刻的曲线,它反映了一个值得注意的事件。但它缺少一些重要的数据和上下文。
关于这创下纪录的说法似乎源自投资银行瑞银 (UBS) 一位分析师的评论,他说“我们不记得应用程序以这种速度扩展”,我认为这是一个合理的、对冲的说法。更强烈的说法是它创造了一个彻底的记录,这似乎是误报。
其他应用程序的数据
我找到了除 Spotify2 以外的所有这些应用的每月用户数据。我还搜索了非常流行的应用程序列表,以寻找用户增长更快的好的线索。您可以在此处查看完整的数据集和来源。3 我在附录中提供了有关数据和我的方法的更多详细信息。
据我所知,该图表相当准确,但它缺少 Pokémon GO,后者速度要快得多。它还缺少 Instagram 的 Android 版本,这可以说是一个新的应用程序版本,并且在第一天就超过了 100 万。这是一张表格,总结了我能够找到的数字,按时间顺序列出:

比较 ChatGPT 和 Pokémon GO 的早期数字有点困难,因为我找不到 Pokémon GO 达到 1M 的天数或 ChatGPT 达到 10M 的天数,但 ChatGPT 似乎不太可能更快。
分析
按互联网用户数量扩展
在过去的几十年里,可以访问互联网的总人数一直在快速增长。此外,社交网站的发展使人们更容易彼此共享应用程序。这两者都应该让应用程序更容易传播。考虑到这一点,下面的图表显示了一段时间内使用每个应用程序的所有互联网用户的比例(注意对数纵轴):
几个应用程序随时间变化的每月用户数。纵轴是对数刻度。
总的来说,这些曲线的初始斜率似乎随着时间的推移而增加,这表明应用程序传播的速度不仅仅受互联网访问人数增加的影响。但是 Pokémon GO 和 ChatGPT 看起来就像不同高度的垂直线,所以这是另一个图表,显示了每个应用程序启动后的(对数)时间:
使用该服务的全球总人口中可以访问互联网的比例与服务推出后的天数。用户数量在 t=1 分钟时任意设置为 1
这非常清楚地表明,虽然 ChatGPT 是一个异常值,但它仍然比 Pokémon GO4 慢得多。
额外比较
我们可以做的另一个比较是与其他产品和服务进行比较,这些产品和服务被用户接受得非常快,以及它们的覆盖范围如何随着时间的推移而增加:

新发布视频在 24 小时内在 YouTube 上的观看次数为我们提供了一个参考点,让我们了解指向 Internet 上某些内容的链接传播和参与的速度有多快。与注册 ChatGPT 帐户相比,观看视频的门槛较低,这可能会给视频带来优势。此外,大概每个人有不止一个视图。我不知道这种影响有多大,但可能很大。
现场活动的按次付费销售,在这个 c对于格斗运动,是人们愿意在短时间内在家中使用的东西的参考点。付款比开户门槛更高,但营销和销售可以提前进行。
24 小时内的视频游戏销售,在某些情况下是数字下载,类似于按次付费,但似乎更直接类似于网站上的服务。我猜想视频游戏比 PPV 受益于更长的营销和预售期,但我不确定。

这是这些事情随时间变化的记录图,数据来自维基百科5,包含在数据电子表格中。每个点都是一个单独的视频、PPV 事件或游戏,我只包括那些创下 24 小时记录的点:
视频游戏、PPV 比赛、YouTube 视频和应用程序的前 24 小时内大多数销售、观看次数和用户的记录,以及应用程序第一周内用户的一些积分(显示为蓝色菱形)。每个数据点代表一个事件、游戏、视频或应用程序。仅包括其特定类别中的那些设置记录。

看起来非常流行的应用程序不如非常流行的视频游戏或视频那么受欢迎。我看不出可以从中得出强有力的结论,但我确实认为这是有帮助的背景。
其他注意事项
我怀疑 Pokémon GO 和其他视频游戏的营销优势是巨大的。我不记得在 Pokémon GO 发布之前看过它的广告,但我在它发布之前对有关它的新闻文章进行了简短的搜索,发现几个月前有很多炒作。在发布之前,我没有找到任何提及 ChatGPT 的新闻文章。这不会改变总体结论,即关于 ChatGPT 创下完全记录的说法是错误的,但它应该改变我们对它的看法。
ChatGPT 能够在没有任何营销的情况下击败大多数其他服务,这似乎是一件大事。我认为如果没有大量用户参与,很难向人们推销它的酷炫之处,但下一代 AI 产品可能不需要这样,因为人们已经意识到这项技术已经走了多远。考虑到这一点(以及围绕 Bing Chat 和 Bard 的炒作),我会勉强预测营销将在未来的版本中发挥更大的作用。
附录——方法和注意事项
我发现的大多数数字是针对每月用户的,或者在某些情况下是针对每月活跃用户的。我并不总是确定这两件事之间有什么区别。在某些情况下,我所能找到的只是每月应用程序下载量或年度下载量,我天真地认为这两者都严格大于每月用户。但无论如何,年度用户数量反映了长期增长,因此它们不应该影响结论。
假设指数增长,某些特定用户里程碑的天数是插值的。总的来说,我认为这不会对整个故事产生太大影响,但如果你需要知道精确的数字,你应该检查我的插值或找到更直接的测量值。没有一个数字是外推的。
在搜索数据时,我尝试使用 SEC 文件和公司公告等官方来源,或者使用看似信誉良好且拥有付费客户的第三方服务的测量值。但有时这些很难找到,我不得不使用不太可靠的来源,比如引用可疑的新闻报道或数据不完整的研究。
我没有打算以非常谨慎的方式产生非常可靠的数据。总的来说,这需要大约 1-2 个研究人员日的努力。鉴于此,我似乎可能犯了一些错误,但希望不会有任何破坏结论的错误。

作者 east
人工智能 3月 26,2023

让我们考虑放慢 AI 的速度

通过不制造厄运机器来避免厄运
如果你担心有人会建造一台机器来控制世界并消灭人类,那么一种反应就是尝试建造更多的机器来更早地控制世界而不破坏它,从而阻止毁灭性机器的征服.另一种或补充的反应是试图完全避免建造此类机器,至少在它们的世界末日倾向的程度是模棱两可的时候。
在我看来,后一种方法是一种至少值得考虑的基本和显而易见的事情,而且也有利于它,非常适合“不难想象在现实世界中发生的事情”这一类型。然而我的印象是,对于担心人工智能灭绝风险的人来说,“积极减缓 AI 进步”标题下的策略历来被驳回和忽视(尽管“不积极加快 AI 进步”很受欢迎)。
这些年来我附近的谈话感觉有点像这样:

有些人:人工智能可能会杀死所有人。我们应该设计一个完美善良的上帝般的超级人工智能来防止这种情况发生。
其他:哇,这听起来非常雄心勃勃
有些人:是的,但这非常重要,而且我们非常聪明,所以我知道它可以工作

有些人:好吧,这很难,我们放弃了
其他人:哦,难道我们不应该尝试阻止这种危险的 AI 的构建吗?
有些人:嗯,那会涉及到协调很多人——我们可能会自大到认为我们可以建造一个可以接管世界并将其改造为天堂的神机,但我们不是妄想

这对我来说似乎是一个错误。 (最近,对其他一些人来说。)
对于是否应该在“尝试放慢某些 AI 研究”的范围内做任何事情,我没有强烈的看法。但我认为 a) 天真的第一次猜测应该是一个很强的“可能”,并且 b) 在这个巨大的干预空间中注销所有内容之前应该进行适当的思考。而通常的试探性答案似乎是“当然不是”,然后似乎会回避该主题以进行进一步思考。 (至少根据我的经验——人工智能安全社区很大,对于我在这里所说的大多数事情,不同的部分可能会有不同的体验。)
也许我最强烈的观点是,人们不应该对这些不同类别的干预应用如此不同的雄心标准。喜欢:是的,在减缓 AI 进展以取得良好效果方面似乎存在很大困难。但在技术调整中,艰巨的挑战与艰巨的努力的热情相得益彰。并且非常不明显的是,这里的难度远大于设计可接受的安全版本机器所涉及的难度,这些机器能够在世界上任何其他人设计危险版本之前接管世界。
在过去的几个月里,我一直在和人们谈论这个问题,并且积累了很多不试图放慢 AI 速度的理由,其中大部分我都想至少讨论一下。我的印象是,现实生活中的争论恰逢人们转向我的观点。
快速说明
首先,为了避免误解——

我认为“减缓危险的 AI”包括以下任何一种:降低 AI 总体进步的速度,例如如果人工智能的一般资金减少,就会发生这种情况。将人工智能的努力从更直接导致风险结果的工作转移到其他工作,例如如果对非常大的 AI 模型存在广泛关注,并且人员和资金转移到其他项目,则可能会发生这种情况。停止工作类别,直到对其安全性有足够的信心,例如如果 AI 研究人员同意某些系统会带来灾难性风险,并且不应该开发,直到它们不被开发,就会发生这种情况。 (这可能意味着某些系统的永久终结,如果它们本质上是不安全的。)(所以特别是,我包括了直接目标是一般缓慢的行为,以及目标是在特定开发之前需要安全的行为,这意味着进度较慢。)
我确实认为这些东西的某些版本受到了认真的关注,通常以其他名称命名。我看到人们在考虑“差异化进步”(上图 b),并制定协调战略以在未来某个时候(例如在“部署”时)减慢 AI 的速度。而且我认为很多考虑都是为了避免主动加速人工智能的进步。我要说的是缺少的是,a) 现在考虑积极努力减缓 AI,以及 b) 直接射击以“减缓 AI”,而不是畏缩不前,只考虑在另一个概念化下出现的例子(也许这是一个不公平的诊断)。
AI Safety 是一个大社区,我只见过一个人进入它的窗口,所以也许情况有所不同,例如在直流电,或不同在伯克利租用对话。我只是说,在我这个世界的角落里,对此不感兴趣的程度是值得注意的,而且在我看来是误判了。

为什么不放慢人工智能?为什么不考虑呢?
好吧,如果我们暂时假设这个话题值得思考,我们会怎么想?放慢人工智能是个好主意吗?有充分的理由解雇它吗?
Scott Alexander 不久前写了一篇帖子,提出了不喜欢这个想法的理由,大致如下:

你想输掉一场军备竞赛吗?如果 AI 安全社区试图放慢速度,它将不成比例地减缓美国的进步,然后其他地方的人将快速前进,并成为其能力决定世界是否毁灭的人,其价值观决定未来的人如果有一个。同样,如果 AI 安全人员批评那些为 AI 进步做出贡献的人,那多半会让最友好、最细心的 AI 能力公司望而却步,鲁莽的会先得逞。
人们可能会考虑“协调”以避免这种病态的竞争。但与整个世界协调任何事情似乎都非常棘手。例如,有些国家幅员辽阔、令人生畏,难以与之交谈。
鼓动缓慢的 AI 进展是对 AI 能力人员的“背叛”,他们是 AI 安全社区的好朋友,他们的友谊对于确保 AI 实验室认真对待安全(以及非工具性可爱)具有战略价值! 嗨 AI 能力的朋友们!)。

我听到的其他意见,我将讨论其中的一些:

减缓人工智能的进步是徒劳的:尽管你付出了所有努力,但几年后你可能就会死去
基于说服人们人工智能风险是一个问题的协调是荒谬的雄心勃勃。要让 AI 教授相信这一点几乎是不可能的,更不用说真正的人类了,你需要说服大量的人。
我们要做什么,建立强大的 AI 永不死亡,当地球被太阳吞噬时?
如果 AI 进展迅速,实际上对安全性更好。这可能是因为 AI 能力工作得越快,AI 的进展就会越顺利,而这比周期的持续时间更重要。或者现在加快进度可能会迫使未来的进度相应变慢。或者因为在构建具有相关风险的 AI 之前完成安全工作可能会更好,在这种情况下,最好的策略可能是尽可能接近危险的 AI,然后停下来进行安全工作。或者,如果提前进行安全工作毫无用处,也许延迟可以,但没有什么好处。
减缓 AI 速度的具体途径是不值得的。例如,避免从事 AI 能力研究是不好的,因为它对学习对齐工作的道路非常有帮助。从事 AI 能力工作的 AI 安全人员可以成为这些公司做出更安全选择的力量。
先进的人工智能将足以帮助解决其他存在风险,从而代表整体存在风险的净降低。 1
监管机构对高级人工智能的本质一无所知(部分原因是它不存在,所以每个人都对此一无所知)。因此,他们将无法对其进行有效监管,也无法带来预期的结果。

我的印象是,对于这种注意力分配,还存在一些不那么认可或不那么利他或更愚蠢的动机。在与人们谈论这件事时至少出现过一次,或者似乎正在发生的一些事情:

先进的人工智能可能会带来多种奇迹,例如长寿有增无减。晚一点到达那里对子孙后代来说很好,但对我们这一代人来说,这可能意味着像我们的祖先在乌托邦永恒的风口浪尖上所做的那样死去。这将是非常令人失望的。对于一个真正相信未来的人来说,可能会倾向于寻找最好的场景——人类及时建立强大、安全的人工智能来拯救这一代人——而不是我们自己不可避免地丧生的场景。
有时,那些衷心感谢技术迄今为止所带来的繁荣的人会发现,在这里肤浅地站在卢德主义一边是痛苦的。
弄清楚思维是如何运作得足够好以从数学中创造出新的思维是一个非常深入和有趣的智力项目,参与其中感觉是正确的。很难直觉地觉得一个人不应该这样做。(插图来自现代计算强化学习的联合创始人:)

这将是有史以来最伟大的智力成就。科学、工程和人文学科的成就,其意义超越人类、超越生命、超越善恶。—理查德·萨顿 (@RichardSSutton) 2022 年 9 月 29 日

考虑会使您与他人发生冲突的项目会让您感到不舒服。提倡更慢的 AI 感觉就像试图阻碍别人的项目,这让人感觉具有对抗性,并且感觉它有更高的负担的证据,而不仅仅是做你自己的事情。
“Slow-down-AGI”将人们的想法发送到例如工业破坏或恐怖主义,而不是更无聊的课程,例如“为实验室制定何时暂停部署模型的共同规范的游说”。可以理解,这鼓励尽快放弃这个想法。
我的弱猜测是,一般来说,人工智能风险思维中存在一种偏见,任何不为零的力量都被认为是任意强烈的。就像,如果存在代理存在的压力,就会任意快速地出现任意代理的东西。如果有反馈回路,它会任意强。在这里,如果 AI 不能永远停滞不前,那么它基本上是零时间。如果一项法规不能阻止每一个危险的项目,那么它就毫无价值。面对对 AI 无所不能的经济激励,任何对危险 AI 的有限经济抑制都算不了什么。我认为这是一个不良的心理习惯:现实世界中的事物往往归结为实际的有限数量。这很可能是一个不公平的诊断。 (我不打算稍后讨论这个;这就是我要说的。)
我感觉到一种假设,即放慢一项技术的进步将是一种激进的、闻所未闻的举动。
我同意 lc 的观点,该主题似乎存在准禁忌,这也许可以解释很多未讨论的内容,但仍需要对其进行解释。我认为这表明对不合作的担忧起到了一定的作用,对于将放慢 AI 速度视为主要涉及反社会策略的想法也是如此。

我不确定这是否能完全解决为什么 AI 安全人员没有考虑进一步降低 AI 速度的原因,或者人们是否应该尝试这样做。但我的感觉是,上述许多理由至少有些错误,动机有些误导,所以我想反过来争论很多,包括论点和模糊的动机主题。
提案的普遍性
克制不激进
似乎有一种普遍的想法认为,技术是世界必须走的一条不可避免的道路,试图放慢或避开其中的任何一部分都是徒劳和极端的。

2
但根据经验,世界并不追求每一种技术——它几乎不追求任何技术。
糟糕的技术
首先,有很多机器没有制造压力,因为它们没有价值。考虑一台向你的眼睛喷屎的机器。我们可以在技术上做到这一点,但可能没有人建造过那台机器。
这似乎是一个愚蠢的例子,因为没有任何严肃的“技术是不可避免的”猜想会声称完全毫无意义的技术是不可避免的。但如果你对 AI 足够悲观,我认为这是正确的比较:根据我们的最佳理解,如果有一些 AI 如果被创造出来会给它们的创造者带来巨大的净成本,那么它们至少与制造它们一样无用作为“在你眼中喷屎”的机器。我们可能会由于错误而意外地制作它们,但并没有某种深层的经济力量拉动我们制作它们。如果不结盟的超级智能在你要求它做一件事时很有可能摧毁世界,那么这就是它所在的类别,它的设计只是在废料堆中腐烂并不奇怪,喷着狗屎的机器在你的眼中和在道路上传播鱼子酱的机器。
好吧,但也许相关参与者非常坚定地认为未结盟的超级智能是否是​​部署的好东西是错误的。或者你可能认为情况不会立即那么可怕,并且构建具有生存风险的 AI 确实对做出决策的人有好处(例如,因为成本不会在一段时间内到来,而且人们非常关心相对于科学成功的机会到未来的一大块)。如果明显的经济激励很大,那么技术是不可避免的吗?
极具价值的技术
在我看来不像。以下是一些我认为具有巨大经济价值的技术,出于对安全或伦理的担忧3,研究进展或吸收似乎比它可能的要慢得多:

大量的医学研究,包括真正重要的医学研究,例如尽管全球每年有 500,000 人死亡,但 FDA 从 70 年代到 2000 年代禁止对链球菌 A 疫苗进行人体试验。在 covid 疫苗经过所有适当的试验时,也有很多人死亡。

各种遗传学事物:食物的基因改造、基因驱动、早期重组 DNA 研究人员著名地组织了一项暂停,然后是正在进行的研究指南,包括禁止某些实验(参见 Asilomar 会议)
核武器、生物武器,也许还包括化学武器(或者这些可能根本没用)
各种人类生殖创新:人类克隆、人类基因操纵(具有经济价值的技术的一个显着例子是 to 如果这些国家之间没有明确的协调,我的知识几乎不会在不同国家之间传播,即使这会使这些国家更具竞争力。有人在中国的婴儿身上使用 CRISPR,但因此入狱。)

很多关于人类的科学?我最近进行了这项调查,并被提醒道德规则对于即使是令人难以置信的无害研究也是多么的阻碍。据我所知,欧盟现在规定在欧盟收集数据是非法的,除非你承诺从任何可能到达的地方删除数据,如果给你数据的人在某个时候希望这样做的话。总之,处理这个和 IRB 相关的事情可能增加了项目一半以上的工作量。似是而非,我误解了这些规则,但我怀疑其他研究人员比我更擅长弄清楚它们。
可能有来自被认为令人反感或令人尴尬的领域的例子,但作为局外人很难判断哪些领域是真正没有希望的,哪些被错误地认为是无望的。如果在那些被认为有吸引力的人中存在具有经济价值的健康干预措施,我想与没有以这种方式受损的类似有前途的技术相比,具有良好声誉的科学家发现和追求它们的速度要慢得多。对智力的科学研究显然因耻辱而放缓,但我不太清楚经济上有价值的结果是什么。
(我想这个列表中可能还有很多其他的东西,但我现在没有时间回顾它们。这个页面将来可能会收集更多。)

在我看来,故意放慢技术进步以留出时间进行甚至可能过度谨慎的行为是司空见惯的。 (这只是在审视因谨慎或道德问题而放慢速度的事情——可能还有其他原因让事情放慢。)
此外,在没有人特别试图放慢速度的有价值的技术中,进展被相对较小的障碍大幅放慢似乎很常见,这进一步证明了经济力量缺乏压倒性的力量。例如,弗莱明 (Fleming) 于 1928 年首次注意到霉菌对细菌的影响,但直到 1939 年,才有人认真、认真地尝试将其开发为药物。

4

此外,在这些事件发生之前的数千年里,许多人多次注意到霉菌、其他真菌或植物抑制了细菌的生长,但并没有充分利用这一观察结果,以至于它在 1920 年代不被视为新发现。与此同时,人们死于感染是一件大事。 1930 年,每年约有 300,000 名美国人死于细菌性疾病(约 250/100k)。
我的猜测是,人们对技术做出了真正的选择,而且他们是在面对比通常想象的要弱的经济力量时这样做的。
克制通常不是恐怖主义
我认为人们在想到“减缓 AI”时,从历史上看都会想象一些奇怪的事情。我认为他们的核心形象有时是恐怖主义(可以理解,他们不想考虑太久),有时是某种难以置信的乌托邦式全球协议。
以下是“减缓 AI 能力”的其他一些事情(执行每个事情的最佳人选各不相同,但如果你不是那个人,你可以与是的人交谈):

不主动转发 AI 进展,例如将你的生命或数百万美元投入其中(这通常已经被认为是)
试图说服研究人员、资助者、硬件制造商、机构等,他们也应该停止积极转发 AI 进展
尝试让这些人中的任何一个停止主动转发 AI 进展,即使他们不同意你的观点:通过谈判、付款、公开谴责或其他积极的方式。
尝试向世界传达人工智能正走向严重危害的信息。如果人工智能的进步受到广泛谴责,这将影响无数决策:工作选择、实验室政策、国家法律。要做到这一点,例如制作令人信服的风险演示,煽动对风险行为的污名化,写科幻小说来广泛和令人回味地说明问题(我认为这在过去实际上是有帮助的),上电视,写评论文章,帮助组织和授权已经关心的人,等等。
帮助组织那些认为他们的工作可能会造成毁灭性后果的研究人员,让他们采取协调一致的行动来避免这样做。
将 AI 资源从危险的研究转移到其他研究。将投资从导致大量但知之甚少的能力的项目转移到导致理解这些事情的项目,例如缩放前的理论(参见一般差异技术发展5)。
为 AI 研究人员和实验室制定具体的预防措施,以应对不同的明确定义的未来情况,Asilomar Conference s风格。这些措施可能包括由特定方或方法进行更严格的审查、修改实验或完全暂停调查。组织实验室来协调这些。
减少 AI 的可用计算,例如通过生产和贸易监管、卖方选择、采购计算、贸易策略。
在实验室,选择会减慢其他实验室速度的策略,例如减少对公共有益的研究成果
改变出版制度和激励措施以减少研究传播。例如。期刊核实研究结果并在不提供任何细节的情况下发布其发表的事实,保留研究优先级的记录以供日后发布,并分配参与资金。 (这就是 Szilárd 和他的同事如何安排缓解 1940 年代帮助德国的核研究,但我不确定是否使用了补偿性资助的想法。6)
上述行动将通过科学家、或资助者、或立法者、或实验室、或公众观察员等做出的选择来采取。与这些各方沟通,或帮助他们采取行动。

协调不是奇迹般的世界政府,通常协调的共同形象似乎是明确的、集中的、涉及世界上每一方的,就像在囚徒困境中合作:激励在任何时候都促使每个理性的一方背叛,但可能是通过道义论的美德或复杂的决策理论或强有力的国际条约,每个人都设法不背叛足够多的摇摇欲坠的时刻来寻找另一种解决方案。
这是一种可能的协调方式。 (而且我认为不应该被视为如此绝望——世界实际上已经在一些令人印象深刻的事情上进行了协调,例如核不扩散。)但是如果你想要的是让很多人同时做一件事,当他们可能做了另一个,那么有很多方法可以实现。
考虑其他一些协调行为的案例研究:

不吃沙子。整个世界协调起来几乎不吃任何沙子。他们是如何管理的?实际上,吃沙子几乎不符合任何人的兴趣,因此仅仅保持足够的认识论健康就可以让这一点得到广泛认可。
避免人兽交:可能有些人认为人兽交是道德的,但不要以为从事兽交会冒着巨大的耻辱感。因此,世界在做很少的事情上协调得很好。
在街上不穿维多利亚时代的服装:这很相似,但不涉及道德上的责备。历史服饰可以说通常比现代服饰更具美感,但即使是强烈同意的人也发现一般情况下穿它是不可想象的,并且除非有“借口”(例如特殊派对),否则他们会竭力避免穿它。这是对看似无处不在的激励(为了更好看)的一种非常强大的协调。据我所知,它在很大程度上是由“未完成”这一事实提供动力的,否则现在会很奇怪。 (这是一个非常通用的机制。)
政治正确性:公共话语对于可以说什么有很强的规范,这似乎并不是源于绝大多数人对此表示同意(如兽交所说)。关于什么是政治正确的新观点有时会广泛传播。这种协调行为似乎大致是由于社会惩罚的分散应用,既来自支持者的核心,也来自因不惩罚他人而害怕受到惩罚的人。然后也可能来自那些担心不遵守现在看来是其他人的行为规范的人。这与上面的示例不同,因为它似乎可以持续存在,即使只有极少数人同意规范的对象级原因。如果不倡导规范会让你被拥护者公开羞辱,那么你可能会倾向于倡导它,从而给其他人带来更大的压力。

这些都是非常广泛的行为协调案例,没有一个涉及囚徒困境类型的情况,或者人们做出明确的协议,然后他们有动机打破。它们不涉及大型多边协议的集中组织。协调行为可能来自每个人出于相关原因而单独想要做出某种选择,或者来自人们想要做他们周围的人正在做的事情,或者来自分布式行为动态,例如惩罚违规行为,或者来自在思考一个主题时的协作.
你可能认为它们是与 AI 关系不大的奇怪例子。我认为,a) 重要的是要记住人类群体行为中实际出现的大量奇怪的动态,并且不要在一个除了囚徒困境和有约束力的承诺之外什么都耗尽的世界里对 AI 进行理论化,并且 b) 以上内容实际上是这里所有潜在的相关动态。
如果 AI 实际上在我们的有生之年构成了巨大的生存风险,那么它是 n对任何特定个人来说都是坏事,那么理论上的情况看起来很像“避免吃沙子”的情况。如果一个理性的人只是独自一人并且没有面临任何类型的多代理情况,那么这是一个理性的人不想采取的选择。如果 AI 有那么危险,那么不采取这种次等选择可能很大程度上来自于一种像良好信息分发一样简单的协调机制。 (你仍然需要与非理性的人和价值观不同寻常的人打交道。)
但是,即使无法通过对情况的无处不在的洞察力协调谨慎,其他模型也可能奏效。例如,如果人们开始普遍担心 AI 研究不好,那可能会通过与上述类似的机制,大大减少对它的参与,超出关注的人群。或者它可能会产生广泛的地方法规,强制执行任何被认为可以接受的行为。这种监管不需要在世界范围内集中组织以服务于协调世界的目的,只要它在不同的地方相似地成长即可。这可能会发生,因为不同的地方有相似的利益(所有理性的政府都应该同样担心失去权力给目标无法验证的自动权力寻求系统),或者因为——与个人一样——存在支持非-集中方式。
军备竞赛模型及其替代方案
好吧,也许原则上你可能希望协调不要做自我毁灭的事情,但实际上,如果美国试图放慢脚步,中国或 Facebook 或其他不那么谨慎的人会不会接管世界?
从博弈论的角度来说,让我们更加小心我们正在玩的游戏。
军备竞赛
理论上什么是军备竞赛、游戏?在我看来,这是一个重复的囚徒困境。每一轮看起来像这样:

玩家 1 选择一行,玩家 2 选择一列,结果收益列在每个单元格中,{玩家 1,玩家 2}
在这个例子中,制造武器需要一个单位。如果任何人在回合结束时拥有比其他人更多的武器,他们将拿走他们所有的东西(十个单位)。
在单轮游戏中,制造武器总是比不制造武器更好(假设您的行为不会对对手的行为产生影响)。从这场比赛中摆脱出来总是更好的。
如果您认为 AI 构成毁灭世界的巨大风险,这与当前 AI 的情况不太一样。
自杀竞赛
一个更接近的模型:同上,除非有人选择建造,否则一切都会被摧毁(每个人都会失去他们所有的东西——十个单位的价值——以及一个单位,如果他们建造了)。

这与经典的“军备竞赛”有重要的不同,因为按下“现在每个人都输了”按钮并不是一种均衡策略。
也就是说:对于任何认为强大的错位 AI 代表近乎确定的死亡的人来说,其他可能的 AI 构建者的存在并不是“竞赛”的任何理由。
但很少有人如此悲观。玩家很有可能“调整 AI”的温和版本怎么样?
安全或自杀竞赛
好吧,让我们做一个像上一个一样的游戏,但是如果有人建造,一切都可能被摧毁(减去 10 个),在生存的情况下,每个人都会回到最初的军备竞赛乐趣,即根据谁建造的更多来重新分配东西比谁(+10 给建造者,-10 给非建造者,如果每个人都有的话)。因此,如果你单独构建 AI,并在概率启示录中幸运的话,仍然可以大获全胜。
如果任何建筑物发生,我们将 50% 作为厄运的可能性。然后我们有一个游戏,其预期收益是前两个游戏的一半:

(这些是预期收益——单单建筑的负一单位回报来自建筑的一单位成本,加上在灭绝事件中失去十个的一半机会和在世界接管事件中从对手那里拿走十个的一半机会。 )
现在你想做其他玩家正在做的事情:如果他们会建造就建造,如果他们会通过就通过。
如果毁灭世界的几率很低,这将成为最初的军备竞赛,而你总是想要建造。如果非常高,那将成为自杀式竞赛,你永远不想建造。在现实世界中让你进入这些不同阶段的概率是不同的,因为所有这些参数都是由组成的(人类灭绝的负面影响不是构建强大人工智能的研究成本的 10 倍,因为实例)。
但我的观点是:即使就简单模型而言,我们处于或接近军备竞赛的情况也不是很明显。因此,非常不明显的是,竞相更快地构建高级人工智能甚至在第一次通过时就很有希望。
用不那么博弈论的术语来说:如果你看起来离解决对齐问题还差得很远,那么就尽你所能努力成为解决对齐问题的人——尤其是如果这意味着你有更少的时间来解决问题这样做,虽然我没有在这里讨论——可能是不明智的。如果你没有办法让这些人实施足够的安全性以实际不死,那么让更多在意识形态上支持安全的 AI 设计师赢得与不太关心的团队的“军备竞赛”是徒劳的,这似乎是一个非常现实的可能性。 (Robby Bensinger 和 Andrew Critch 可能在某处提出了相似的观点。)
与我的朋友就此类话题进行的对话可以是这样的:

我:如果奖品是共同死亡,就没有真正的比赛动机
他们:当然,但事实并非如此——如果有一线希望在未结盟的 AI 中幸存下来,并且如果你方在这种情况下取​​得控制权的预期会更好一些,并且如果他们无论如何都要构建强大的 AI,那么它就是值得赛车。整个未来都悬而未决!
我:你把自己的努力引向安全不是更好吗,因为你的安全努力也将帮助每个人最终拥有一个安全的人工智能?
他们:这可能只会对他们有所帮助——你不知道对方是否会使用你的安全研究。而且,这不仅仅是因为他们的安全研究较少。按照你的说法,他们的价值观可能更糟。
我:如果他们成功对齐,外国价值观真的比当地价值观差吗?可能任何拥有丰富智慧的人都有类似的机会来创造一个光荣的人类乌托邦,不是吗?
他们:不,即使你是对的,同样的人最终会让你拥有相似的价值观,但其他各方可能比我们这边更愚蠢,并锁定 7 他们想要的价值观的一些未经深思熟虑的版本目前,或者即使所有项目都如此愚蠢,我们这边可能会有更好的未经深思熟虑的价值来锁定,并且更有可能使用安全理念。即使赛车很可能导致死亡,而生存很可能导致浪费大部分价值,但在那片幸福的世界里,无论是我们还是其他人在浪费,都关系重大!
我:嗯,看起来很复杂,我需要纸来做这个。

复杂的种族/反种族
这是一个模型电子表格,您可以复制并使用。
第一个模型是这样的:

每个玩家在安全和能力之间分配他们的努力
一个玩家“获胜”,即首先构建“AGI”(人工智能)。
P(Alice wins) 是 Alice 的能力投资相对于 Bob 的逻辑函数
每个玩家的总安全是他们自己的安全投资加上对方安全投资的一小部分。
对于每个参与者,如果他们达到安全,就会有一些结果分布,如果他们没有达到安全,就会有一组结果,这考虑了例如他们实施愚蠢的近期锁定的倾向。
结果是赢家和对齐状态的分布,每个都是世界的分布(例如乌托邦,近期良好锁定……)
这一切都给了我们很多实用程序(美味的实用程序!)

第二个模型是相同的,除了不是在安全和能力之间分配努力,而是选择一个速度,并且每一方完成的对齐量是一个外生参数。
这些模型可能不是很好,但到目前为止支持我想在这里提出的一个关键主张:在这种情况下应该走得更快还是更慢并不明显——它对许多不同的参数很敏感范围。
此外,我认为定量分析的结果与人们的直觉不符。
例如,这是一个我认为直觉上听起来像是你应该比赛的世界的情况,但在上面的第一个模型中,你实际上应该尽可能慢地走(这应该是现在插入电子表格的那个):

AI 非常安全:未结盟的 AGI 只有 7% 的几率导致厄运,另外还有 7% 的几率导致短期锁定一些平庸的东西
你的对手冒着糟糕的锁定风险:如果“锁定”了一些平庸的东西,你的对手有 5% 的机会锁定在一些积极可怕的东西上,而你总是会选择好的平庸的锁定世界(和平庸的锁-ins 要么是乌托邦的 5%,要么是 -5%)
你的对手冒着破坏乌托邦的风险:如果 AGI 一致,你将可靠地获得最佳结果,而你的对手也有 5% 的机会最终陷入“平庸的糟糕”场景。
安全投资抹杀了你首先获得 AGI 的机会:从完全没有安全到完全安全意味着你成为第一个的机会从 50% 变为 0%
您的对手正在赛车:您的对手正在将一切都投入到能力上,而没有投入到安全性上
安全工作以极大的折扣帮助他人:您的安全工作为其他玩家的安全贡献了 50%

你在这里(在这个模型上)最好的选择仍然是最大化安全投资。为什么?因为积极追求安全,可以让对方半途而废,这比失去的获胜机会更有价值。特别是如果 y如果你“赢”了,你是在没有太多安全保障的情况下这样做的,而你在没有安全保障的情况下取得的胜利比对手在安全保障的情况下取得的胜利更糟糕,即使这也远非完美。
因此,如果您处于这个空间的情况下,而另一方正在赛车,那么以牺牲安全为代价来加快速度甚至符合您在游戏中的狭隘利益并不明显,尽管它可能是。
这些模型在很多方面都有缺陷,但我认为它们比支持军备竞赛的直观模型要好。我的猜测是下一个更好的模型仍然存在细微差别。
其他均衡和其他博弈
即使如果其他人在比赛,你也有兴趣参加比赛,“(什么都不做,什么也不做)”在这些游戏中通常也是一种平衡。至少对于参数的各种设置。如果你知道你的对手是错误的并且无论如何都要参加比赛,那么为了达到这种平衡而什么都不做并不一定有意义,但结合与你的“对手”的沟通,这似乎是一个理论上的好策略.
这一切都假设了游戏的结构。我认为对军备竞赛情况的传统反应是要记住,你身处一个更复杂的世界,拥有各种未建模的可供性,并试图摆脱军备竞赛。
与冒险者做朋友
谨慎是合作
另一个大问题是,推动较慢的 AI 进展正在“背叛”AI 研究人员,他们是 AI 安全社区的朋友。
例如史蒂文伯恩斯:

“我认为试图通过监管来减缓对 AGI 的研究将会失败,因为每个人(政治家、选民、游说者、企业等)都喜欢科学研究和技术发展,它创造就业机会,治愈疾病等等,等等,你是说我们应该少吃点。所以我认为这种努力会失败,而且还会适得其反,因为它会让 AI 研究人员社区将 AGI 安全/对齐人员社区视为他们的敌人、白痴、怪人、勒德分子等等。”

(这也是之前批评的观点的一个很好的例子,即对创造就业机会和治愈疾病的事物进行监管并没有发生。)
或者 Eliezer Yudkowsky,担心传播对 AI 的恐惧会疏远顶级 AI 实验室:

这是我没有,也告诉其他人不要,及早将人类从 AGI 灭绝的观点与 AI 实验室联系起来的主要原因。克里正确地描述了他所反对的立场,IMO。我自己估计公众将对 AGI 实验室负责人无牙。— Eliezer Yudkowsky (@ESYudkowsky) 2022 年 8 月 4 日

我不认为这是一种自然或合理的看待事物的方式,因为:

研究人员自己可能不想毁灭世界。他们中的许多人实际上也同意人工智能是一种严重的生存风险。因此,以两种自然的方式,推动谨慎与许多(如果不是大多数)AI 研究人员合作。
人工智能研究人员没有道德权利危及世界,有人会要求他们更加谨慎地采取行动。比如,为什么“合作”看起来像是安全人员向人们想要的更鲁莽的能力低头,以至于害怕代表他们的实际利益,而能力人员通过继续建设来维护他们的“合作”方面危险的人工智能?作为不同人在这种情况下的力量的自然结果,这种情况可能是有道理的。但也不要称之为“合作”,如果以安全为导向的各方考虑行使他们拥有的任何权力,他们将可耻地“背叛”。

控制人工智能能力的人可能会对推动缓慢进展的人工智能安全人员做出负面反应。但这应该被称为“我们可能会受到惩罚”而不是“我们不应该叛逃”。 “背叛”具有不当的道德内涵。称一方推动他们想要的结果为“背叛”,通过错误地设定常识性道德来反对他们,不公平地剥夺了他们的权力。
至少在安全方面是这样。如果任何可用的行动是全世界应该谴责的“背叛”,我声称它可能是“建造可能会毁灭世界的机器,或者在它发生时袖手旁观”。
(如果相关人员有信心他们不会毁灭世界,而我只是不同意他们的看法,情况会更加复杂。但大约一半的受访研究人员实际上比我更悲观。而且在中等人工智能研究人员认为的情况下该领域有 5-10% 的机会导致人类灭绝,任何负责人对自己判断其安全的信心有多大?)
最重要的是,我担心强调想要更谨慎的进展是背叛的叙述会进一步破坏,因为如果有人参与,这使得人工智能能力人员更有可能认为人工智能安全人员认为自己背叛了人工智能研究人员。任何此类努力。这使得e 努力更积极。比如,如果每次你见到朋友时,你都称其为“欺骗我的伴侣”,你的伴侣可能会合理地因你不断想见朋友而感到受伤,即使这种行为本身是无害的。
“我们”不是美国,“我们”不是人工智能安全社区
“如果‘我们’试图放慢 AI 的速度,那么对方可能会获胜。” “如果‘我们’要求监管,那么它可能会损害‘我们’与人工智能公司的关系。”这些“我们”是谁?为什么人们特别为这些群体制定战略?
即使放慢 AI 是不合作的,并且 AI 安全社区与 AI 功能社区合作很重要,但 AI 安全社区以外的众多人中的一个不能参与其中吗?
长期以来,我一直对轻描淡写地谈论“我们”应该做什么而感到恼火,而不考虑集体代表的是什么。所以我可能对这里太敏感了。但我认为由此产生的混乱会产生真正的后果。
我认为当人们在这里说“我们”时,他们通常认为他们是在代表 a) 人工智能安全社区、b) 美国、c) 他们自己或 d) 他们和他们的读者制定战略。但这些人只是一小部分人,甚至显然不是演讲者最能影响的人(你坐在美国的事实真的让美国比爱沙尼亚更愿意听你的建议吗?是的,平均而言可能,但不是无限多。)如果这些自然认同的群体没有好的选择,那并不意味着没有选择,或者没有与其他方沟通的选择。说话者可以和不同的“我们”说话吗?也许说话者心目中的“我们”中的某个人认识不在该组中的某个人?如果世界上任何人都有策略,并且您可以交谈,那么很可能有适合您的策略。
在我看来,这些方面最明显的错误是将 AI 的放缓视为对 AI 安全社区与其他 AI 研究人员之间关系的内在破坏。如果我们承认这样的活动将被视为背叛(这对我来说似乎不合理,但也许),那么肯定只有在 AI 安全社区执行时才可能是背叛。有相当多的人不在 AI 安全社区,但与此有利害关系,所以也许他们中的一些人可以做点什么。放弃人工智能进展的所有放缓似乎是一个巨大的疏忽,因为你只考虑了人工智能安全社区可用的功能。
再举个例子:如果世界处于有时想象的基本军备竞赛局面,美国愿意制定法律来降低人工智能风险,但不能因为中国会闯入,那么这意味着中国处于一个很好的地方减轻人工智能风险。与美国不同,中国可以提议相互放慢速度,而美国会同意。也许向中国相关人士传达这一点并非不可能。
这种感觉相关的讨论的一个奇怪之处在于,坚持认为一个人的行动能力仅限于美国。也许我无法理解亚洲在多大程度上是一个不适用代理的陌生而遥远的土地,但例如我只是写信给那里的一千名机器学习研究人员,也许有一百人回信,而且很多喜欢在美国与人打交道。
我对哪些干预措施在包括美国在内的任何特定国家/地区会起作用一无所知,但我只是认为假设您基本上只能影响一个国家/地区的事情,来到谈判桌前是很奇怪的。特别是如果你认为你对其他国家人民的利益有独特的了解。就像,公平地说,如果你想让一个亚洲政府选出你的领导人或其他什么的,我会是交易破坏者级别的悲观主义者。但如果你认为先进的人工智能极有可能毁灭世界,包括其他国家,那么情况就完全不同了。如果你是对的,那么大家的动机基本上是一致的。
我更怀疑一些相关的思维捷径正在扭曲关于军备竞赛的讨论。认为某事是一场“比赛”的想法似乎比其他选择更具吸引力,即使真正的动机并没有真正使它成为一场比赛。就像,违反博弈论的规律,人们有点希望敌人试图相信谎言,因为这会更好地促进他们的比赛。这感觉就像现实主义。数十亿人们几乎不了解的不确定细节,有着各种各样的利益和关系,只是真的想在零和博弈中把自己塑造成一个“我们”和一个“他们”。这是一条可能真正杀死我们的思维捷径。
我的印象是,在实践中,对于上文“极具价值的技术”一节中提到的许多因风险或道德问题而放缓的技术,具有相当不同文化的国家已经采用类似的谨慎方法。我拿这个作为证据表明,道德思想、社会影响、政治权力或理性实际上都不是国家孤立的,而且一般来说,“国家竞争”模式并不是很好。
易处理性说明
说服人们似乎并不难
当我说“协调”看起来像是惩罚一项活动的流行观点,或者其他国家没有太多真正的动机去建造会杀死他们的机器时,我认为一个普遍的反对意见是让人们相信真实情况是绝望。情况似乎是,关于 AI 风险的论点极其复杂,而且只有知识精英中的最精英才能理解——例如在 Twitter 上说服教授已经够难的了,所以群众肯定是它无法企及的,外国政府也是如此。
这与我在各个方面的整体经验不符。
一些观察:

正如我提到的,接受调查的 ML 研究人员的中位数似乎认为人工智能将以 5-10% 的几率毁灭人类
通常人们已经在理智上相信了,但还没有将其融入到他们的行为中,并且不难帮助他们组织起来按照他们暂定的信念采取行动
正如 Scott 所指出的,许多 AI 安全人员已经涉足 AI 功能,包括运行 AI 功能组织,因此这些人大概认为 AI 已经存在风险
我不记得在与随机的陌生人讨论 AI 风险时遇到过任何困难。有时他们也相当担心(例如,丝芙兰的一位化妆师对高级人工智能的危险进行了长时间的咆哮,我在圣地亚哥的司机兴奋地同意并向我展示了他前排座位上打开的 Homo Deus)。关注的形式可能与 AI 安全社区的关注形式有些不同,但我认为更接近于“AI 代理将杀死我们所有人”而不是“算法偏差会很糟糕”。我不记得我试过多少次了,但在大流行之前,我经常和优步司机交谈,因为不知道如何避免这种情况。我最近向我的治疗师解释了 AI 风险,除了他认为我可能会造成灾难性后果的感觉之外,我觉得一切顺利,尽管我们可能需要再次讨论。
我的印象是,大多数人甚至没有接触过可能使人们完全同意 AI 安全社区的论点。例如,我的猜测是,很多人假设有人实际上编写了现代人工智能系统,如果你告诉他们事实上它们是随机连接,在一个有收益的方向上多次摇摆不定,就像它们的制造者一样神秘,他们可能也怕错位。
Nick Bostrom、Eliezer Yudkokwsy 和其他早期思想家在说服其他人担心这个问题方面取得了不错的成功,例如我。据我所知,如果不写任何令人信服且易于理解的解释来说明为什么应该这样做,阅读起来将花费不到两个小时。
我傲慢地认为我可以写一个广泛引人注目且易于理解的 AI 风险案例

我的猜测是,不可动摇的 AI 风险怀疑论者集中在 AI 风险人群附近的知识界,尤其是在 Twitter 上,而且在知识地位竞赛中马匹较少的人更容易喜欢,’哦,是的,超级智能机器人可能是坏的’。目前尚不清楚大多数人是否甚至需要说服存在问题,尽管他们似乎并不认为这是世界上最紧迫的问题。 (尽管所有这些在我所远离的文化中可能有所不同,例如在中国。)我对此非常不自信,但略读调查证据表明,美国公众对 AI 的担忧虽然不是压倒性的,但也有实质性的。
你需要说服所有人吗?
我可能是错的,但我想说服 AI 实验室的十位最相关的领导者这是一件大事,值得优先考虑,实际上会让你放慢脚步。我没有太多证据证明这一点。
购买时间大
您可能不会永远避免 AGI,也许巨大的努力可以为您争取几年的时间。9 这值得吗?
似乎很合理:

无论人们在做什么其他人工智能安全研究或政策工作,每年都可能以不可忽略的速度发生。 (连同所有其他改善情况的努力——如果你购买一年,那就是多出 80 亿人年的时间,所以只需要花费一点点有用的钱就可以使它变大。如果很多人担心,这似乎并不疯狂。)
地缘政治经常变化。如果你真的认为决定事情进展到何种程度的一个重要因素是无法与某些群体协调,那么每年都会为你提供不可忽视的机会,让情况以有利的方式发生变化。
舆论可以很快改变很多。如果您只能购买一年,那么您可能仍然购买了一些不错的人选,并为您提供更多年限。也许特别是如果新的证据正在积极涌入——人们 ch2020 年 2 月激怒了他们的想法。
其他事情随着时间的推移而发生。如果你能在今天或在随机事件发生几年后接受你的厄运,总的来说后者似乎要好得多。

这些是桌面上的时间尺度对我来说也不是很明显。我的感觉是,由于监管或普遍的社会厌恶而放慢速度的事情通常会放慢一两年以上,而埃利泽的故事假设世界上到处都是集体,要么试图摧毁世界,要么对世界产生严重误解,这还不是定局。
默认情况下延迟可能是有限的
虽然有些人担心任何延迟都会如此之短以至于可以忽略不计,但其他人似乎担心如果人工智能研究停止,它永远不会重新开始,我们将无法进入太空或其他什么。这对我来说听起来太疯狂了,以至于我认为我错过了太多有用的反驳理由。
障碍不需要明辨
试图放慢速度的另一个据称的风险是,它可能涉及监管机构的介入,而他们可能对未来人工智能的细节一无所知,因此顽固地制定了错误的规定。与此相关的是,如果你号召公众为此担心,他们可能会产生不准确的担忧,要求解决方案无能为力,从而分散对真正灾难的注意力。
我不买。如果你只想放慢广泛领域的活动,我的猜测是无知的法规每天都可以做到这一点(通常是无意的)。特别是,我的印象是,如果你把事情搞砸了,通常的结果是很多事情随机地比希望的慢。如果您想加快特定事情的速度,那就完全不同了,可能需要了解所讨论的事情。
社会反对派也是如此。没有人需要了解基因工程如何运作的细节,因为不喜欢它的人会严重损害它的优势。也许在他们的灯光下,它还没有被最佳地破坏,但只是不喜欢附近的任何东西确实有很长的路要走。
这与监管或社会羞辱无关。你需要更少地了解汽车、国家或谈话来搞砸它,而不是让它运行良好。这是一般规则的结果,即事物功能失调的方式比功能多得多:破坏比创造容易。
回到对象层面,我暂时希望努力广泛减缓 AI 进展附近的事情,以减缓 AI 在网络上的进展,即使目标不佳。
速度带来安全,同谋带来影响力
由于各种原因,目前让 AI 快速运行实际上可能对安全性更好。尤其:

尽快实施可以实施的可能意味着更顺利的进展,这可能更安全,因为 a) 它使一方更难抢在所有人之前获得权力,以及 b) 人们在周围做出更好的选择,如果他们是正确的发生了什么(例如,他们不相信事实证明比预期强大得多的系统)。
如果减缓 AI 进展的主要目的是为安全研究留出更多时间,并且在更先进的 AI 背景下进行安全研究会更有效,并且可以进行一定程度的放慢(例如,因为一个实际上是在军备竞赛中,但比竞争对手有一些领先),那么以后最好使用一个人放缓的预算。
如果有一些潜在的进步曲线(例如,如果可能花在硬件上的钱每年只增长一定数量),那么也许如果我们现在向前推进,那自然会要求他们以后放慢速度,所以它不会影响强大人工智能的总体时间,但意味着我们将在信息丰富的灾难前人工智能时代花费更多时间。
(我认为更多的东西在这里)

也许目前进行能力研究是值得的,例如因为:

作为一名研究人员,研究能力可以让您做好安全工作的准备
您认为出现 AI 的房间将为关心安全的人提供不错的选择

这些似乎都有道理。但也似是而非的错误。我不知道对这些考虑因素中的任何一个进行决定性分析,我不打算在这里做一个。我的印象是,他们基本上都可以选择任何一种方式。
我实际上特别怀疑最后一个论点,因为如果你相信我认为是人工智能风险的正常论点——超人人工智能体将不会有可接受的价值,并且会积极地表现出他们拥有的任何价值,到或者后来人类灭绝——那么打开这种机器的人的情绪似乎是一个非常小的因素,只要他们仍然打开机器。而且我怀疑“让一个拥有我的价值观的人做某事”通常被高估了。但世界比这些模型更混乱,我仍然会付出很多代价才能在房间里接受治疗y。
情绪和哲学、启发法和态度
目前尚不清楚这些心理特征在理性评估如何行动时应该扮演什么角色,但我认为它们确实扮演了角色,所以我想就它们展开争论。
技术选择不是低俗主义
有些技术比其他技术更好 [不需要引用]。我声称,最好的支持技术的愿景应该不成比例地涉及令人敬畏的技术并避免低劣的技术。如果你认为 AGI 极有可能毁灭世界,那么它就是一种技术的狗屁巅峰。反对将其纳入您的技术乌托邦就像拒绝在那里使用放射性牙膏一样。通俗地说,勒德分子反对以技术形式出现的进步。10 即使这是一个糟糕的立场,其明智的逆转并不是对所有“技术”的认可,无论它是否以进步的形式出现。
近期繁荣的非 AGI 愿景
也许减缓人工智能的进步意味着放弃我们这一代人对改变生活的技术的希望。因此,一些人发现很难在心理上瞄准较少的 AI 进步(以其实际的个人成本),而不是追求可能不太可能的“安全 AGI 很快”的场景。
我不确定这是一个真正的困境。我们已经看到的狭义人工智能进展——即当前技术在当前规模上的进一步应用——似乎有可能对长寿和其他医学有很大帮助。在某种程度上,人工智能的努力可以集中在例如。医学上相关的狭隘系统创造了代理诡计之神,想象在抗衰老等方面取得更多进展听起来并不疯狂(甚至在考虑代理诡计之神没有像希望的那样优先考虑你的身体健康的可能性之前) ).其他人不同意我的看法。
稳健的先验与特定的星系脑模型
世界上有些东西非常好,有些东西在高度特定的内部视图模型上很好,但如果这些模型错误则很糟糕。减缓危险技术的发展似乎是前者,而在世界超级大国之间推动危险技术的军备竞赛似乎更像是后者。11 有一个普遍的问题是,在多大程度上相信你的推理并冒着银河系大脑计划的风险。12 但无论你接受这一点,我想我们都应该同意,你对它的思考越少,你就越应该倒退到强有力的良好行动上。就像,如果你只是想借一大笔钱买一辆高档汽车,你可能不应该这样做,因为大多数时候这是一个糟糕的选择。然而,如果你已经考虑了一个月,你可能会非常确定你处于这种罕见的情况下会得到回报。
在这个特定主题上,感觉就像人们正在使用特定的银河系大脑内部视图,如果是错误的模型,那就太糟糕了,然后就不再考虑它了。
Cheems心态/不能做的态度
假设你有一个朋友,你对他们说“我们去海滩吧”。有时朋友会说“是的”,然后即使你没有毛巾、交通工具、时间或海滩,你也能做到。其他时候,即使你拥有所有这些东西,而你的朋友名义上想去海滩,他们也会注意到他们稍后会有包裹,而且可能有风,他们的夹克需要清洗。当你解决这些问题时,他们会注意到离晚餐时间不远了。您可能会推断,在后一种情况下,您的朋友只是不想去海滩。有时这是主要的事情!但我认为态度上也存在更广泛的差异:有时人们正在寻找使事情发生的方法,有时他们正在寻找无法发生的原因。这有时被称为“cheems 态度”,或者我喜欢(更通俗易懂)称之为“做不到的态度”。
我在与人谈论放慢 AI 速度时的经验是,他们似乎有一种做不到的态度。他们不希望这是一个合理的过程:他们想取消它。
这似乎都不是最理想的,并且与历史上对更多技术问题解决的态度形成鲜明对比。 (正如我在帖子开头的对话中所强调的那样。)
在我看来,如果将同样程度的不能做的态度应用于技术安全,就不会有 AI 安全社区,因为在 2005 年 Eliezer 会注意到对齐的任何障碍并放弃并回家。
引用一位朋友的话说,如果我们*实际尝试过*会是什么样子?
结论
这是对我遇到的一堆不考虑减缓 AI 进步的原因的各种批评。我认为我们在这里没有看到太多理由对放慢 AI 的速度感到非常悲观,更不用说甚至不考虑它的理由了。
我可以选择任何一种方式来判断在短期内减缓人工智能的任何干预措施是否是一个好主意。我的初步猜测是肯定的,但我的主要兴趣这里只是我们应该考虑一下。
在我看来,很多关于这个问题的观点都没有经过深思熟虑,是错误的,并且错误地排斥了可能纠正它们的进一步想法。我希望通过研究一些足以证明没有充分理由立即解雇的此类考虑来在这里有所帮助。存在困难和问题,但如果在这里和其他地方采用相同的雄心标准,我想我们会看到答案和行动。

作者 east

上一 1 … 44 45 46 … 93 下一个

关注公众号“大模型全栈程序员”回复“小程序”获取1000个小程序打包源码。回复”chatgpt”获取免注册可用chatgpt。回复“大数据”获取多本大数据电子书

标签

AIGC AI创作 bert chatgpt github GPT-3 gpt3 GTP-3 hive mysql O2O tensorflow UI控件 不含后台 交流 共享经济 出行 图像 地图定位 外卖 多媒体 娱乐 小程序 布局 带后台完整项目 开源项目 搜索 支付 效率 教育 日历 机器学习 深度学习 物流 用户系统 电商 画图 画布(canvas) 社交 签到 联网 读书 资讯 阅读 预订

官方QQ群

小程序开发群:74052405

大数据开发群: 952493060

近期文章

  • spark内存溢出怎样区分是软件还是代码原因
  • MQTT完全解析和实践
  • 解决运行Selenium报错:self.driver = webdriver.Chrome(service=service) TypeError: __init__() got an unexpected keyword argument ‘service’
  • python 3.6使用mysql-connector-python报错:SyntaxError: future feature annotations is not defined
  • 详解Python当中的pip常用命令
  • AUTOSAR如何在多个供应商交付的配置中避免ARXML不兼容?
  • C++thread pool(线程池)设计应关注哪些扩展性问题?
  • 各类MCAL(Microcontroller Abstraction Layer)如何与AUTOSAR工具链解耦?
  • 如何设计AUTOSAR中的“域控制器”以支持未来扩展?
  • C++ 中避免悬挂引用的企业策略有哪些?

文章归档

  • 2025年7月
  • 2025年6月
  • 2025年5月
  • 2025年4月
  • 2025年3月
  • 2025年2月
  • 2025年1月
  • 2024年12月
  • 2024年11月
  • 2024年10月
  • 2024年9月
  • 2024年8月
  • 2024年7月
  • 2024年6月
  • 2024年5月
  • 2024年4月
  • 2024年3月
  • 2023年11月
  • 2023年10月
  • 2023年9月
  • 2023年8月
  • 2023年7月
  • 2023年6月
  • 2023年5月
  • 2023年4月
  • 2023年3月
  • 2023年1月
  • 2022年11月
  • 2022年10月
  • 2022年9月
  • 2022年8月
  • 2022年7月
  • 2022年6月
  • 2022年5月
  • 2022年4月
  • 2022年3月
  • 2022年2月
  • 2022年1月
  • 2021年12月
  • 2021年11月
  • 2021年9月
  • 2021年8月
  • 2021年7月
  • 2021年6月
  • 2021年5月
  • 2021年4月
  • 2021年3月
  • 2021年2月
  • 2021年1月
  • 2020年12月
  • 2020年11月
  • 2020年10月
  • 2020年9月
  • 2020年8月
  • 2020年7月
  • 2020年6月
  • 2020年5月
  • 2020年4月
  • 2020年3月
  • 2020年2月
  • 2020年1月
  • 2019年7月
  • 2019年6月
  • 2019年5月
  • 2019年4月
  • 2019年3月
  • 2019年2月
  • 2019年1月
  • 2018年12月
  • 2018年7月
  • 2018年6月

分类目录

  • Android (73)
  • bug清单 (79)
  • C++ (34)
  • Fuchsia (15)
  • php (4)
  • python (45)
  • sklearn (1)
  • 云计算 (20)
  • 人工智能 (61)
    • chatgpt (21)
      • 提示词 (6)
    • Keras (1)
    • Tensorflow (3)
    • 大模型 (1)
    • 智能体 (4)
    • 深度学习 (14)
  • 储能 (44)
  • 前端 (4)
  • 大数据开发 (491)
    • CDH (6)
    • datax (4)
    • doris (31)
    • Elasticsearch (15)
    • Flink (78)
    • flume (7)
    • Hadoop (19)
    • Hbase (23)
    • Hive (41)
    • Impala (2)
    • Java (71)
    • Kafka (10)
    • neo4j (5)
    • shardingsphere (6)
    • solr (5)
    • Spark (100)
    • spring (11)
    • 数据仓库 (9)
    • 数据挖掘 (7)
    • 海豚调度器 (10)
    • 运维 (34)
      • Docker (3)
  • 小游戏代码 (1)
  • 小程序代码 (139)
    • O2O (16)
    • UI控件 (5)
    • 互联网类 (23)
    • 企业类 (6)
    • 地图定位 (9)
    • 多媒体 (6)
    • 工具类 (25)
    • 电商类 (22)
    • 社交 (7)
    • 行业软件 (7)
    • 资讯读书 (11)
  • 嵌入式 (71)
    • autosar (63)
    • RTOS (1)
    • 总线 (1)
  • 开发博客 (16)
    • Harmony (9)
  • 技术架构 (6)
  • 数据库 (32)
    • mongodb (1)
    • mysql (13)
    • pgsql (2)
    • redis (1)
    • tdengine (4)
  • 未分类 (7)
  • 程序员网赚 (20)
    • 广告联盟 (3)
    • 私域流量 (5)
    • 自媒体 (5)
  • 量化投资 (4)
  • 面试 (14)

功能

  • 登录
  • 文章RSS
  • 评论RSS
  • WordPress.org

All Rights Reserved by Gitweixin.本站收集网友上传代码, 如有侵犯版权,请发邮件联系yiyuyos@gmail.com删除.