SQL 访问加密货币市场数据：LLM 驱动分析的新范式

数据交互的格局正在发生演变，特别是随着大语言模型 (LLMs) 的兴起及其在分析任务中的潜力。虽然传统的交付 JSON 的 REST APIs 对于具有预定义数据需求的软件来说表现良好，但当 LLMs 处理庞大且结构化的数据集时，其效率就会下降。Koinju.io 正在开创一种新方法，为其广泛的加密货币市场数据提供直接的 SQL 访问，并将其定位为 LLM 驱动分析的更优原语。

这一举措部分受到了 Didier Lopes 关于金融公司拥有其基础设施（尤其是 AI 推理发生的运行时）的论文的启发。其核心思想是使 LLMs 不仅仅能够检索数据，而且能够直接在数据集上执行复杂的、可检查的操作，从而将 LLM 的角色从单纯的数据解析器转变为规划者和控制器。

LLMs 与大数据的挑战

传统的、为直接检索而设计的数据 API 通常以 JSON 格式返回数据。这种模式虽然对许多应用有效，但在 LLMs 执行大规模数据集上的分析工作时，会面临重大障碍：

• 上下文窗口限制：当以标记化 (tokenized) 的 JSON 行形式呈现时，LLMs 难以高效地摄取、重塑、连接、聚合、验证或对大型结构化数据集进行推理。在大规模应用时，这会迅速超出上下文限制。
• 效率与准确性：在客户端处理大型 JSON 负载可能会导致计算密集型任务，并容易出现无声的数据丢失或误解，因为微小的细节可能会作为离群值消失在庞大的上下文中。
• 缺乏可检查性：LLM 解析和操作 JSON 的过程通常是一个黑盒，这使得精确地规划、重放或追踪计算变得困难。

作为面向 LLM 的原语的 SQL

Koinju.io 的论点是，对于大数据集，面向 AI 的原语应该从“返回 JSON”转变为“在数据集上执行受限的、可检查的操作”。SQL 脱颖而出成为这一角色的有力候选者。虽然这不是一个新概念，但 SQL 在这种背景下具有若干优势：

• 显式性与可检查性：SQL 查询是显式的，允许 LLMs 检查模式 (schemas) 、理解约束、表达操作，甚至检查抽象语法树 (ASTs)。这种透明度对于调试和验证至关重要。
• 组合性与可执行性：SQL 允许复杂的操作被组合并在靠近数据的地方直接执行，利用查询引擎的力量。这减轻了 LLM 上下文窗口的重度计算负担。
• 紧凑的结果：LLM 接收到一个紧凑的、带类型的结果，在此基础上它可以进行更有效的推理，而不是在原始的、标记化的数据中进行筛选。

在这种模式下，LLM 充当规划者/控制器，生成 SQL 查询，然后由提供商端的查询引擎执行。REST APIs 对于简单的检索仍然相关，但 SQL 将处理大规模市场数据集上的分析性问题的重重重担，而 JSON 分页在这些场景下被证明是低效的。

治理与架构边界

对于金融领域，治理是至关重要的。公司通常倾向于维护对其整个工作流的控制权，包括内部上下文、权限、模型策略、审计日志和决策工作流，而不是将其让渡给供应商的黑盒接口。这并不一定意味着在进行任何查询之前必须将所有外部数据集复制到本地。

Koinju.io 提出了一种精细化的架构边界：

• 公司所有权：客户公司拥有工作流和 AI 推理运行时。
• 提供商执行面：数据提供商暴露一个受控的执行面（例如，SQL 接口）。
• LLM 操作：LLM 发出受限的操作（SQL 查询）。
• 查询引擎：提供商的查询引擎执行实际的计算。
• 结果交付：一个紧凑的结果被返回到公司的环境。

这种模式允许公司在保留对其核心流程控制权的同时，从外部专业的化数据基础设施中获益，而无需进行大规模的本地数据复制。

未来关键问题

这一探索性路径为行业提出了几个关键问题：

• 目前对于处理大数据的 LLM 来说，什么是最佳的接口？
• LLMs 是否应该在原始数据、JSON、模式 (schemas) 、SQL、带类型的工具、语义层或它们的组合上运行？
• 客户拥有的运行时与提供商端的数据执行之间，精确的边界应该在哪里？
• 当调用者是一个自主代理 (autonomous agent) 时，查询限制、成本预览、试运行 (dry runs) 、权限和审计日志应该如何运作？

最终，目标是找到一种最有效且受治理的方式，让 AI 代理与大型、复杂的数据集进行交互并从中获取洞察。无论是这涉及发明全新的 AI 类别，还是仅仅提供干净的数据、稳定的模式 (schemas) 、健壮的 SQL 访问、全面的文档和可预测的限制，这一探索都突出了 AI 时代数据交互的一个关键演变。