PromptQL:从乐高到数据块的管理工具
介绍 PromptQL 框架如何模块化管理 prompt 组件,提升 prompt 工程效率。
介绍 PromptQL 框架如何模块化管理 prompt 组件,提升 prompt 工程效率。
你有没有想过,在所有乐高星球大战套装中,总共用到了 9113 种独特的积木块?
如果你要拼砌每一套星球大战乐高,那么你会用到 63,269 块"淡蓝灰色"(#A0A5A9)的积木块。
我偶尔会发现一些有趣的独特数据和数据集,想要深入探索。通常我会把它们扔进 SQL 数据库,摸索数据库schema,然后进行一些 SQL 查询。有时我也会通过 grep 文件中的关键词,然后对结果进行分析,也能学到不少东西。
既然我喜欢玩数据,LLM 和 RAG(检索增强生成)这些天似乎无处不在。利用 LLM 的能力在向量空间中提出更深入的问题,有时候能得到令人惊讶的结果。但我很难在基础发现和玩具级用例之外相信它。别误会我,我确实在觉得有帮助的地方使用这些工具,但我在向任何特性或流程中添加新工具时也会谨慎,尤其是那些可能"幻觉"(也就是说:"对着你的脸撒谎,然后毫不在意")的工具。
我最近发现 Rebrickable 的乐高数据可以批量下载,包含关于乐高套装、积木块、小人仔及其他更多信息的各种数据。
这里有大量 CSV 数据。数百万条记录。鉴于其中大部分只是数字和关系,RAG 似乎不是合适的工具。我们不是在尝试从标题、评论或描述之类的东西中搜索或提取语义含义。我们没有太多文本嵌入来获取向量的用途。在这种情况下,我们试图从由 id 连接和聚合定义的众多关系之间的含义中提取含义。不过,一切都没有失去。LLM 领域 Agent 和 Agentic 工具活动频繁。基本上是赋予 LLM 执行代码、创建代码和某种程度"自主权"来解决问题的能力。
我一直在玩一个来自 Hasura 的叫做 PromptQL 的新工具,它利用了他们所谓的"Agentic 数据访问",对事物有一个有趣的转折。(注:我获得了早期访问权限,正在与团队合作提供反馈,他们赞助了我一些时间来试用该工具)。PromptQL 建立在 Hasura 已经启用的标准化数据访问层之上,是一个数据访问 Agent,可以理解你的数据 schema,然后生成查询计划来访问数据并即时执行计算。PromptQL 不仅仅是在向量空间中的 RAG。它是直接从 Postgres、MongoDB,甚至完全非 SQL 的源(如 GitHub API)中查询数据。生成最优查询计划而不是遵循严格的检索管道的能力正是 PromptQL 真正强大的地方。
回到我们的乐高数据。schema 相当简单,只是大量数据组织成有意义的关系。
我写了一个简单脚本,从 Rebrickable 网站下载所有内容并将其转储到 Postgres 数据库。如果你想自己尝试一些东西,应该相当容易获取和运行。
完成后,我将 PromptQL 指向该数据库。PromptQL 文档在解释这一点方面相当不错。
完成后,我启动了 PromptQL 界面,如果你用过任何聊天界面(或类似 ChatGPT 的应用),你会感到宾至如归。
例如,我想知道有多少个星球大战套装包含那种淡蓝灰色积木块?
那么我怎么知道我甚至可以信任这些结果呢?很简单。我不必信任。PromptQL 执行的所有 Agentic 操作都由它展示给我的代码支持。
问题"有多少种不同的颜色?"回复了以下内容:
要回答你关于不同颜色数量的问题,我需要查询数据库中的 Colors 表。让我为你获取该信息。查询计划
查询 Colors 表来计数不同颜色的数量。
检索颜色总数。
将结果存储在 artifact 中以供参考。
向用户展示信息。
然后它写入并执行以下代码:
# Query to count the number of distinct colors
sql = """
SELECT COUNT(DISTINCT id) as color_count
FROM app.Colors
"""
# Execute the query
result = executor.run_sql(sql)
# Extract the color count
color_count = result[0]['color_count']
# Store the result in an artifact
executor.store_artifact(
'color_count',
'Total Number of LEGO Colors',
'table',
[{'Total Colors': color_count}]
)
# Print the result for verification
executor.print(f"Total number of colors: {color_count}")
输出:SQL 语句返回 1 行。存储的表 artifact:identifier = 'color_count',title = 'Total Number of LEGO Colors',行数 = 1,样本行 = [{'Total Colors': 267}] 总颜色数:267
我不必信任它从某些语义搜索和 RAG 中生成的东西。我可以查看它组建的实际 SQL,如果需要确认事情,我可以查看实际数据源。我有一个习惯是相当经常地检查执行的代码块来理智检查事情。在我看来,这个级别的透明度对于调试 Agentic 应用至关重要。
我最喜欢的事情之一是,因为它了解你的 schema,你可以问 PromptQL 你应该甚至问什么样的问题。对于我拥有的乐高数据,它建议尝试以下事情:
- Historical evolution of LEGO sets, tracking how piece counts and complexity have changed across decades
- Analysis of rare minifigures and unique parts that only appear in a single set
- Comparison between licensed themes (Star Wars, Harry Potter) and original LEGO themes in terms of popularity and complexity
- Distribution patterns of colors across sets, particularly looking at sets with the most diverse color palettes
- Deep dive into the most epic sets ever produced, ranked by piece count and build complexity
我实际上尝试了第一个问题,PromptQL 产生了一些有趣的要点。
积木块数量爆炸:从 1950 年代的每套仅 18.5 块,到 2020 年代的 363.3 块——增长了惊人的 1,863.8%
色彩多样性:套装从使用 2.7 种颜色(1950 年代)增加到 13.9 种颜色(2020 年代)——增长了 414.8%
生产高峰:2010 年代见证了最多的套装发布数量,共 6,074 套不同的套装
临时下降:与 1970 年代相比,1980 年代在积木块计数和色彩复杂性方面都显示出异常下降
近期加速:最戏剧性的两个指标增长发生在 2010 年代和 2020 年代
你也不仅仅局限于数据中直接可回答的问题。例如,以 GitHub issue 之类的东西为例。你仍然可以利用典型的 LLM 用例,并请求 PromptQL 按 GitHub issue 内容分类。要求它将事物排序到各种优先级(高、中、低)或不同的 issue 类型(支持、bug、特性)。然后 PromptQL 将合并从你的源中拉取的东西,然后使用 LLM 对其进行分类,并在你的输出 artifact 或附加步骤中使用这些结果。
我实际上已经用 GitHub issue 和其他一些数据源试验过挂接这个。虽然它有一些粗糙的地方,但我已经能够完成各种有趣的事情。比如要求 PromptQL 使用来自 GitHub issue 的实际内容来识别改进项目的重点区域。或者将其连接到支持工单系统和计费数据,并要求 PromptQL 识别有流失风险的客户,并帮助我为每一个客户写定制化电子邮件。
我会提一下,有时候它对特定数据源的特定 SQL 特性或语法支持理解有误。其他时候它可能在特别大或长期运行的查询上超时。不过,一个非常巧妙的特性是 PromptQL 会捕捉这些问题,并通过反馈循环,它会尝试自我纠正,这很酷。其他时候,你的温和引导可以绕过此类问题。
能够理解 Agent 正在做什么和为什么这样做,这令人难以置信的有用。同样有用的是有类似于第二双眼睛的东西来帮助你提问和探索,更不用说几乎是与你的 schema 相关的专家级 SQL。
就像乐高砖块一样,我发现 PromptQL 给了我从数据中构建含义的构建块。无论你是在分析塑料砖块还是生产指标,有一个展示其工作和适应你的 schema 的工具是无价的。我鼓励任何对 LLM、RAG 或 Agentic 流程感兴趣的人试一试。而且,即使你只是想探索数据集或考虑为你的用户提供一种更自然的方式来提问他们的数据,你可能会发现自己用 PromptQL 构建一些相当有用的东西!
一些评论可能仅对已登录的访问者可见。登录以查看所有评论。
对于进一步的操作,你可以考虑阻止该人或报告滥用行为