PostgreSQL与AI:Postgres.AI 机器人,迈向 Postgres 的 LLM OS

翻译自 https://postgres.ai/blog/20240127-postges-ai-bot

前言

我很高兴向您介绍我们的新产品 Postgres.AI Bot(网址:https://postgres.ai/bot)。它由OpenAI 的 GPT-4 Turbo提供支持,旨在帮助工程师改善使用 PostgreSQL 时的体验


该机器人拥有庞大的知识库,拥有超过110,000个条目,包括文档、不同 PostgreSQL 版本的源代码以及 PgBouncer、Patroni 和 pgvector 等相关软件。它还集成了专家文章和博客。


此外,机器人可以进行两种类型的实验来验证想法:

1. 对Postgres.AI DBLab引擎提供的精简克隆进行单会话,以检查SQL语法和PostgreSQL 规划器(planner)和执行器(executor)的行为。

2. 在 Google Cloud 中的不同虚拟机上进行全面的基准测试(pgbench),用于研究 Postgres 在各种工作负载下的行为。对于每次迭代,机器人会自动收集70+个工件,并使用他们来分析和可视化实验结果。

我们 2024 年的雄心勃勃的目标——在共享和专用环境中进行 100 万次数据库实验,帮助机器人了解和改进这些项目,尤其是在性能方面。为了实现这一目标,我们加入了 Google Cloud 的 AI 创业计划(相关链接:https://cloud.google.com/startup/ai?hl=en)。

在这篇博文中,我们讨论了机器人如何实现的一些细节,包括它的功能,分享第一个令人兴奋的成就,并谈论一下未来。


概念

GPT-4 于 2023 年 3 月推出,在各个领域开辟了新的可能性。我们在 Postgres.AI 的使命是增强工程师使用 Postgres 的体验,使其更快地熟练掌握。

通常,成为“Postgres 专家”大约需要 10 年的时间,我总是说不应该这样。在 2023 年之前,我们开发了多种工具来应对这一挑战,其中 DBLab Engine 是关键工具。该工具有助于数据库分支,并允许工程师使用全尺寸、经济高效的可写 Postgres 克隆进行开发和测试。有了全尺寸的可写数据库,任何工程师都可以更快地开始学习 SQL 和 Postgres 的方方面面。


有了LLM,我们可以走得更远,更远……

这个概念很简单:工程师的任何问题都可以由LLM回答,但我们需要确保答案是可靠和有根据的,我们需要将误报(又名“幻觉”)的风险降到最低。这就是 RAG(检索增强生成)的用武之地。我们的 RAG 知识库(RAG KB) 目前拥有超过 110,000 个项目,包括 Postgres 及其主要软件的文档、源代码和高质量的操作方法文章。

2023 年 11 月,Andrej Karpathy 发布了一段富有洞察力的 1 小时介绍视频(相关链接:https://www.youtube.com/watch?v=zjkBMFhNj_g),他在视频中讨论了“LLM OS”的概念:


这引发了我们的“啊哈”时刻。它与我们已经在做的事情完全一致:将 LLM 置于核心位置,周围环绕着工具,以简化 Postgres 工程师的各种任务。这些任务包括检查文档、在必要时深入研究源代码、跨不同 Postgres 版本测试 SQL 查询、重现错误以及进行基准测试。受此启发,我们开始为 Postgres 制作 LLM OS 原型。


基本原则

在开发这个系统时,我们坚持我在Postgres咨询生涯中建立的两个关键咨询原则。


咨询原则#1:高质量的资源

我们始终需要依靠可靠的知识来源。这些包括:

1. 文档:Postgres 文档几乎完美无缺。

2. 源代码:这里的质量被认为是完美的,符合我们的目的。尽管存在bug,但检查源代码对于理解内部工作原理非常宝贵。Postgres 源代码得到了很好的注释,并包含全面的自述文件。

3. 可信的文章和博客文章:仅来自经过验证的作者。

我们知识来源的透明度至关重要。我们始终注明作者并提供原始材料的链接。这种做法不仅仅是尊重;它还可以建立信任。将我们的推理建立在如此坚实的基础之上,可以更有效地说服他人。


咨询原则#2:用数据库实验进行验证

一个基本的方法是始终质疑想法并通过实验来验证它们。这对我来说尤为重要。建立信任,尤其是在工作关系开始时,可能具有挑战性。通过实验展示概念一直有助于建立这种信任。

验证我自己的想法一直很重要,这通常会带来改进或发现缺陷。

虽然实验很丰富,但它们通常需要付出巨大的努力。这一挑战通过自动化来解决。我们新的 Postgres.AI 机器人将 Postgres 的实验提升到一个新的水平,节省了大量时间和资源。


IVO(immediately validatable output)–可立即验证的输出

另一个原则是我们在 Google AI 创业学校从 Zack Akil 那里学到的第一课:如果你正在构建的系统有 IVO——可立即验证的输出——那么你就走在正确的道路上这意味着生成式 AI(GenAI)输出应该可以快速轻松地进行验证。这个想法接近左移测试概念,并且完全符合上述第二个咨询原则。


注:左移测试是一种软件测试和系统测试的方法,其中测试在生命周期的早期执行(即在项目时间轴上左移)。左移测试旨在防止因测试延迟而导致以下类型的损害:

1. 分配给测试的资源不足。

2. 需求、架构和设计中未被发现的缺陷,以及在实施它们时浪费的大量精力。

3. 随着更多软件的生产和集成,调试(包括识别、定位、修复和回归测试缺陷)变得困难。

4. 由于封装阻碍了白盒测试,测试期间的代码覆盖率降低。

5. 可能导致项目失败的技术债务的“弓形波浪”。


这一原则为我们的案例得出了两个重要结论:

1. 了解 LLM 答案中误报风险(在 GenAI 领域称为“幻觉”)和准备迭代的用户会获得更好的结果。因此,我们的目标是向用户解释这一点,并为他们提供方便的迭代路径。

2. 使用编程代码的LLM 辅助系统(例如GitHub Copilot:https://github.com/features/copilot)相对容易地遵循 IVO 原则,因为验证生成的代码或代码更改通常并不困难——不需要时间。但对于数据库领域来说,存在“状态性”:为了可靠地验证一个想法,我们需要处理大型的、现实的数据集。Postgres.AI 针对这个问题的解决方案是 DBLab 引擎(相关链接:https://github.com/postgres-ai/database-lab-engine)提供的数据库分支——有了它,机器人可以迭代,在几秒钟内获得数 TB 数据集的克隆/分支,而无需额外费用。


架构

以下是机器人系统的简单概述,然后是一些细节:


在系统的核心,我们有带“superprompt”的 LLM(在所有对话中使用标准化提示以保持一致性),以及用 Python 编写的机器人主模块。在选择 LLM 时,我们决定使用目前市场上最好的:GPT-4 Turbo,结合 OpenAI 的 Assistants API这提供了一个状态机,其中每个活动对话都处于多种状态之一(或请参阅文档),例如 queued、in_progressre、quires_action 等。

关键状态是requires_action。在此状态下,助手 API 正在等待机器人主模块的响应,该模块可以执行各种功能。目前,我们有这些:

  • get_extra_content– 用于搜索 RAG KB 和编译结果的主要 RAG 函数。

  • debug_mode– 打开或关闭会话线程的调试模式。

  • run_db_experiment_shared_env– 在共享环境(DBLab克隆)中进行数据库实验。

  • run_db_experiment_dedicated_env– 在专用环境(基准)中执行数据库实验。

  • run_db_experiment_wait– 等到正在进行的实验结束并分析结果。

  • make_a_plot– 可视化实验结果。

  • fetch_whole_web_page– 从特定域中检索整个网页以包含在响应中(仅限于特定网站)。

每个函数都由自己的提示和参数驱动。有趣的是,LLM 决定在每个对话步骤中调用哪个函数,这可能涉及对单个答案的多次调用,或者根本没有调用。下面是一个示例:


在这种情况下:

  • 查询是为了查找 PostgreSQL 16 中的文档和pg_stat_statements源代码。机器人正确地解释了我使用的术语。

  • 还标识了对调试模式的请求,尽管该请求不是显式的。

  • 因此,它触发了三个函数:debug_mode,然后是两个get_extra_content调用。

  • 在“超级提示”的指导下,该机器人建议进行测试更改,并提出进行实验,可能会探索pg_stat_statements.track_utility = on对某些工作负载的影响。


检索增强生成(RAG:Retrieval Augmented Generation)

RAG 是使用以下组件实现的:

  • 数据库:Postgres 和 pgvector,在 Google Cloud 的 GKE 上运行。

  • API:PostgREST 提供了一种方便高效的方法,可以将我们的 Postgres 数据库转换为 RESTful API。这允许无缝交互和数据检索。

  • 自定义爬行器和刮板:这些工具旨在有条不紊地收集和处理各种材料。这包括Postgres和相关软件(如PgBouncer、pgBackRest、WAL-G、Patroni、pgvector)的文档和源代码。这确保了我们的知识库是全面和最新的。

  • 矢量化/向量化器:使用 OpenAI API,它为所有内容片段生成向量,它们用于 pgvector 的相似性搜索。


相似性搜索

对于目前知识库的规模,我们对 pgvector 提供的相似性搜索的性能感到满意——并且有很大的增长空间:我们仍然使用 IVFFlat 和旧版本的 pgvector。我们计划在 KB 达到 1M 条目之前升级并开始使用 HNSW。我们还与 Timescale 团队进行了谈判,他们开发了自己的解决方案 Timescale Vector,为性能提供了额外的功能

先关链接:

IVFFlathttps://github.com/pgvector/pgvector?tab=readme-ov-file#ivfflat

HNSWhttps://github.com/pgvector/pgvector?tab=readme-ov-file#hnsw

Timescale Vector

https://www.timescale.com/blog/how-we-made-postgresql-the-best-vector-database/?utm_campaign=vectorlaunch&utm_source=timescale-ai&utm_medium=direct&utm_content=timescale-ai


邮件列表

在我们推出 alpha 1 之后,我们收到了多个请求,要求将邮件列表添加到知识库中。这是有道理的:很多深入的讨论、原因、诀窍、建议、错误报告——所有这些都存在于 Postgres 邮件列表存档中。Postgres 专家在解决某些问题时在邮件列表中搜索的情况并不少见。

我们正在努力将邮件列表存档添加到 RAG KB。其中具有挑战性的部分是 UGC 总体上的信任程度——与文档和源代码不同,来自邮件列表和类似其他地方的消息质量未知(除非我们知道是 Tom Lane 在说话)。为了缓解这种情况,我们开始将内容分成几组:

  • 最高可信度:源代码

  • 高级:文档、经过验证的帖子和文章、知名人士的消息

  • 未知级别:其他任何内容


作者

从一开始,作为各种帖子和文章的作者,我就意识到了作者身份的问题。因此,我们为那些创建与 Postgres 相关的精彩内容的人开发了一种特殊的方法:

1. 我们的承诺是,机器人在使用某些内容(例如博客文章)时,会提及作者并提供指向原始页面的链接——这与“赤裸”的 ChatGPT 不同,后者“记住了某些内容”,并且从不提及它从哪里学到的。这要归功于 RAG KB 和嵌入。

2. 对于博客和文章,我们仅在获得作者明确许可后才会使用其内容。

下面是一个机器人使用我自己的帖子的示例

这种方法完全符合我们上面讨论的第一个咨询原则。

我们从这些伟大的来源开始:

  • CYBERTEC 博客https://www.cybertec-postgresql.com/en/blog/

  • 也许是 Postgres howto 文章的最大来源,强烈地面向实际任务(我自己在工作中使用它多年)


  • OnGres 博客https://ongres.com/blog/

  • 我们的合作伙伴,构建 StackGres 等伟大的东西


  • 创作精彩内容的个人作者

  • Haki Benita:https://hakibenita.com/

  • Franck Pachot:https://dev.to/franckpachot


数据库实验

为了实现第二个咨询原则,即验证,我们决定构建两种类型的自动化。


共享环境试验

要检查 SQL 或规划器的行为,当一个或两个数据库连接就足够时,最好在共享环境中使用 Postgres.AI DBLab 引擎提供的精简克隆进行实验。我们为当前支持的每个 Postgres 主要版本(从 12 到 16)设置了 5 个 DBLab 引擎,机器人可以随时请求新的克隆,这需要 大约1 秒才能提供,这得益于数据写入时复制(相关链接:https://en.wikipedia.org/wiki/Copy-on-write)。


专用环境实验

为了将 Postgres 作为一个整体进行研究,分析其所有组件(如缓冲池、锁管理器)的行为,我们需要在 GCP 中的单独虚拟机上进行实验。计算机配置和软件安装由 postgresql_cluster(相关链接:https://github.com/vitabaks/postgresql_cluster/) 管理;它安装所需的 Postgres、Patroni 版本、各种扩展,包括用于可观察性的扩展。根据需要使用pgbench或psql进行实验。机器人(bot)还可以请求安装任意软件、从源代码编译修补版本、调整 Postgres 等等。

尽管postgresql_cluster可以预配由多个节点组成的 Patroni 集群,但试验目前仅限于一个节点,即主节点。一个实验可以包含多个迭代。在每次迭代之前,缓存(页面缓存和 Postgres 缓冲池)都会自动刷新,累积统计系统也会重置。每次迭代后,都会自动收集工件并将其存储在 Postgres.AI 数据库中,以供进一步分析。

所有自动化都是通过 GitLab 管道完成的。对于每个实验步骤,我们收集了70多个工件,例如关于机器的信息,Postgres版本,所有设置,所有pg_stat_***视图的内容。您可以在这个GitLab管道的数据中找到一个示例。


Google Cloud AI 初创公司计划

最近,Postgres.AI 被 Google Cloud 的 AI 创业计划录取,获得了 35 万美元的云积分,并获得了其他好处。这对我们来说是一个很大的帮助,使我们能够在机器人开发、研究和知识库增长方面更快地发展。


100 万次数据库实验

我们已经启动了“100万次数据库实验”项目。我们已经进行了数百次实验,目前正准备在各个领域进行扩展:

  • 研究 Postgres 规划器行为(各种版本、设置、工作负载)

  • 比较 Postgres 在不同平台(例如 Intel、AMD 和 ARM)、操作系统、文件系统等上的性能

  • 了解使用各种扩展的开销,尤其是可观测性工具,如 pg_stat_statements

  • 在连接池、备份、消息队列等领域对各种 Postgres 相关的开源工具进行基准测试

  • 收集各种边缘和极端情况的数据库,展示潜在问题 - 例如,子事务的行为或 LWLock:LockManager 峰值。


获得的首批结果之一是在具有 360 个 vCPU 的第 4 代 AMD EPYC上运行的单个 Postgres 16 节点上实现 200 万 TPS:

相关链接:https://postgres.ai/chats/018d1878-a9bd-7734-95bb-f3ef73cdb077


在处理这个问题时,与机器人聊天,我们获得了 2 个有趣的发现:

首先,我们需要删除扩展pg_stat_kcache,它为查询分析提供物理级别的指标(CPU、磁盘 IO)。扩展维护人员很快对这一发现做出了反应,并进行了修复——版本 2.2.3 没有这种开销。当然,我们要求机器人再次测试它(可通过推特获取更多测试信息)。

第二个问题与pg_stat_statements有关,pg_stat_statements是Postgres中用于查询分析的标准工具,实际上在我们处理的每个数据库中都使用。令人惊讶的是,在与机器人合作时,我们发现在某些情况下(当许多后端执行相同的查询时),第 4 代英特尔至强( Intel Xeon)可扩展处理器(“Sapphire Rapids”)和第 4 代 AMD EPYC 的性能开销截然不同。为了理解这一点,我们查看了火焰图(FlameGraphs)(详情见本期;点击火焰图来探索它们):

相关链接:https://gitlab.com/postgres-ai/postgresql-consulting/tests-and-benchmarks/-/issues/52


正如我们所看到的,在英特尔上很多时间都花在s_lock了。这个问题需要进一步调查和讨论;我与几位 Postgres 贡献者进行了简短的讨论,其中两位独立表达了为pg_stat_statements实现采样的想法。


默认为公共

我们坚信开源在技术进步中起着关键作用,PostgreSQL作为开源生态中的关键项目之一,应该有更多的材料被开放。如果在与机器人交谈时,我们产生了一个有趣的结果,那么值得与他人分享(当然,如果讨论中不涉及敏感数据)。

这就是为什么默认情况下,所有通信都记录到Postgres.AI数据库,并公开可用,如上面的例子:https://postgres.ai/chats/018d42c9-3a42-7c6d-a72e-364a7651fc1c。不仅公开问答环节与机器人合成实验(那些不包括敏感数据)也共享。


付费版本 – “PRO”

我们尝试各种商业模式。我们开发的第一个选项是“PRO”计划,目前每月收费 500 美元(当前促销优惠为 300 美元),非常适合较小的团队。

它包括以下内容:

  • Slack 中的私人频道

  • 私人通信

  • 最多 10 名队友可以加入频道并参与与机器人的讨论

  • 消息总限制上限:1,000 个请求/月

  • 机器人和 Postgres 相关主题的人工支持,响应时间长达 3 个工作日

要了解更多信息,请联系 bot@postgres.ai 的团队。


首次反馈

我们从早期采用者那里收到了非常积极的反馈。他们中的许多人不断根据 ChatGPT 提供的答案检查机器人的答案,注意到机器人的答案更加有用和精确。

值得一提的是,我们的早期采用者向机器人提出的问题的质量非常高——这要归功于这些工程师本身就是来自 AWS、EDB、GitLab、Timescale 等公司的专家。

有些人非常期待并提出有趣的想法。这里展示了其中的两个:

  • 能够为 Postgres 创建补丁(我们计划添加这个 - “黑客工具集”)

  • 希望为所有主要的开源生态系统建立一个类似的系统(我们没有计划,至少现在是这样)。


今后的计划

这篇文章已经很大了,所以提供我们更多的想法和计划是没有意义的(它像滚雪球一样增长)。

相反,让我以这样一种观点来结束,即我们看到两个大的视野,它们将定义机器人的开发路线图。


测试

与数据库相关的各种测试。从数据库的角度考虑自动拉取请求审查,突出所有潜在问题:架构更改的长独占锁风险、查询中忘记索引或 LIMIT、SELECT+1 模式机器人检测潜在问题,在高效的环境中对其进行测试,向开发人员演示,解释,提出修复建议。


教育

学习任何东西(包括数据库和 SQL)的最好方法是通过练习。对于数据库和 SQL,这意味着使用大型数据集。这是通过 Postgres.AI DBLab 引擎解决的。有了 Postgres.AI 机器人,就可以根据用户选择的一些计划和方便的速度在大型数据集上进行练习。如果有什么不清楚的地方,机器人总是会解释。


加入!

  • 加入 alpha 测试计划:https://postgres.ai/bot

  • 如果您有合作的想法,请与我联系:nik@postgres.ai


本文分享自微信公众号 - 开源软件联盟PostgreSQL分会(kaiyuanlianmeng)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部