从乐高积木到数据块：用PromptQL玩转数据分析

你知道吗？在所有的乐高星球大战套装中，共有9113种不同的组件。

如果你把每个《星球大战》的模型套装都搭建起来，你会用到63,269块“淡蓝灰色”（颜色代码是#A0A5A9）的乐高。

偶尔，我会遇到一些独特和有趣的数据集，想要进行探索。通常我会把这些数据放进一个SQL数据库中，看看它的结构，并偶尔做一些查询。有时候，通过在文件中搜索关键词并分析结果也能学到很多东西。

因为我喜欢玩弄数据，最近这些日子大型语言模型（LLM）和检索增强生成（RAG）似乎不可避免。利用LLM的力量在向量空间中提出更深入的问题，已经带来了不少令人惊讶的结果，但我很难完全信任它，除了基本的探索和玩具用例之外。别误会，确实，当我发现这些工具有助于我的工作流程时，我会使用它们，然而，我总是很谨慎地添加任何可能“瞎编”的新工具，因为这些工具可能会“对你撒谎且毫不在乎”。

最近我才发现可以从Rebrickable 数据批量下载乐高数据，这些数据包含了乐高套装、零件、人仔等的各种信息。

这里有很多CSV数据。成百万的记录。而且由于其中大部分只是数字和关联，RAG似乎不是一个合适的工具。我们并不试图从诸如标题、评论或描述之类的内容中搜索或提取语义意义。我们也没有太多可以利用像文本嵌入这样的策略来获取向量的内容。在这种情况下，我们试图在大量通过ID连接和聚合定义的关联中推断意义。然而，并非一切都失去了希望。在大型语言模型（LLM）领域，智能代理和代理工具出现了一波活跃。基本上，赋予大型语言模型创建和运行代码的能力，以及一定程度的“自治性”来解决问题。

我一直在使用一个新的工具叫做PromptQL，这是来自Hasura的一个工具，它利用所谓的“代理式数据访问”，这种方式对数据访问有很有趣的创新。（注意：我提前获得了试用权限，并与团队合作提供了反馈，他们还赞助了我一些时间来测试这个工具。）PromptQL建立在Hasura已经实现的标准化数据访问层之上，它可以理解你的数据模式，并根据你的数据模式生成查询计划来访问数据并执行实时计算。PromptQL不仅仅限于向量空间的检索。它可以直接从Postgres或MongoDB等数据库，甚至是像GitHub API这样的非SQL数据源查询数据。与遵循固定的检索流程不同，PromptQL能生成最优的查询计划，这是它的强大之处。

回到我们的乐高数据，这个结构很简单，只是将大量的数据组织成有意义的结构。

我写了一个简单的脚本来从Rebrickable网站下载所有东西并导入到Postgres数据库。如果你想自己玩一玩，应该很容易下手并运行。

做完那事后，我将 PromptQL 设置为指向数据库。这方面的解释在 PromptQL 的文档里很清晰。PromptQL 的文档对此解释得很清楚。

完成之后，我就打开了PromptQL界面，如果你用过像ChatGPT这样的聊天应用，你会觉得很熟悉。

例如，我想知道有多少套《星球大战》积木中有这种浅蓝灰色的零件？

那我怎么知道这些结果是否可信呢？很简单，让我来告诉你。我不需要去相信，因为 PromptQL 的每一个代理行为都有配套的代码支持，而且这些代码它都会展示给我看的。

对于“一共有多少种不同的颜色？”这个问题，回答如下：

回答你关于不同颜色的数量的问题，这需要我查询数据库中的Colors表。让我为你获取这些信息。

查询计划

1. 查询Colors表以计算不同颜色的数量。
2. 获取总颜色数量。
3. 将结果存放在一个便于参考的地方。
4. 展示这些信息给你。

然后它编写并运行了以下代码：

    # 查询颜色的数量
    sql = """
    SELECT COUNT(DISTINCT id) as color_count
    FROM app.Colors
    """

    # 执行这个查询
    result = executor.run_sql(sql)

    # 获取颜色数量
    color_count = result[0]['color_count']

    # 保存结果为工件
    executor.store_artifact(
        'color_count',
        '乐高颜色数量',
        '表格',
        [{'总颜色数': color_count}]
    )

    # 打印结果进行验证
    executor.print(f"颜色总数: {color_count}")

点击全屏模式，退出全屏

输出:

SQL 语句返回了 1 行数据。

存储表标识：identifier = 'color_count'，标题：乐高颜色总数，行数 = 1，样本行：总颜色数为 267

总颜色数为 267

我不必信任它从某种语义搜索和RAG中生成的任何内容。我可以查看它实际编写的SQL代码，如果需要确认具体信息，还可以查看实际的数据源。我经常习惯于检查执行的代码块，以确保没有问题。在我看来，这种透明度对于调试代理型应用来说是非常重要的。

我最喜欢的事情之一就是，因为它知道你的数据结构，你可以让PromptQL帮你确定应该问哪些问题。对于我拥有的积木数据，它给我提了以下建议：

- 乐高积木的历史演变过程，追踪各年代零件数量和复杂程度的变化
- 分析罕见的迷你人偶及其仅在一套中出现的独特零件
- 比较授权系列（星球大战、哈利波特）与原版乐高系列在受欢迎的程度和建造难度方面的差异
- 不同套装中颜色分布的模式，特别关注颜色种类最丰富的套装
- 深入探讨有史以来最宏伟的套装，按零件数量和建造难度排名

点击进入全屏，再次点击退出全屏

我试了第一个问题，PromptQL给出了几个有趣的要点。

• 件数激增：从20世纪50年代的每套18.5件到2020年代的363.3件，增加了1863.8%
• 颜色种类从20世纪50年代的2.7种增加到2020年代的13.9种，增长了414.8%
• 生产高峰：2010年代发布的不同套装数量最多，达到了6,074个
• 暂时下降：20世纪80年代，件数和颜色复杂度相比20世纪70年代有所下降
• 这两个指标在2010年代和2020年代增长最为显著

你也不仅仅局限于只能直接从数据中找到答案的问题。比如GitHub问题，你可以让PromptQL根据GitHub问题的内容，像通常的LLM用例一样进行分类。你可以要求它将这些问题按优先级（高、中、低）或问题类型（支持、错误、功能）进行排序。PromptQL会从你的数据源提取内容，利用LLM进行分类，然后将分类结果用于生成输出文件或进行其他操作。

我实际上尝试将其连接到GitHub问题和其他数据源，比如。尽管它还有一些粗糙的地方，我还是完成了不少有趣的事情。比如让PromptQL根据GitHub问题中的内容来识别项目需要重点关注的领域。或者将其连接到工单系统和账单数据，让PromptQL来识别可能流失的客户，并帮我为每一个人撰写定制化的邮件。

我会提到，有时候它会把你的数据源中的某些特定SQL功能或语法搞错。其他时候，它可能会在处理特别庞大的或运行时间很长的查询时超时。不过，有个很酷的功能是PromptQL会捕捉到这些问题，并通过反馈循环尝试自我修正，这个过程真的很酷。其他时候，你也可以稍微引导一下，绕过这些问题。

了解智能代理为何如此行动及其行为方式是非常有用的。同样有用的是，仿佛多了一双眼睛来帮你提问和探索过程中，更不用说几乎达到了与你数据库架构相适应的专家级SQL知识。

就像乐高积木一样，我发现PromptQL为我提供了从数据中构建意义的构建模块。无论是分析生产指标，还是拥有一个能展示其工作并适应你数据结构的工具，都是无价的。我鼓励任何对LLM、RAG或Agentic flows感兴趣的人试试看。即使你只是想探索某个数据集，或者让用户的查询数据更自然，你可能会发现PromptQL能帮你构建一些非常有用的东西！