返回首页
一周热榜
嗨，HN，
我是Nazim，Koinju.io的创始人，我想在这里分享一个我们最近开启的探索性选项：通过SQL提供对我们数据库的访问，该数据库包含所有加密货币市场数据。虽然REST可以直接检索数据，但我们越来越认为，针对统一的加密市场数据层提供SQL访问对于分析工作可能会很有价值，尤其是在大语言模型（LLM）的背景下。
这一想法部分受到OpenBB首席执行官Didier Lopes最近关于金融公司拥有金融工作基础设施的文章的启发，特别是工作流执行和AI推理发生的运行时环境。
大多数数据API是为那些已经知道自己想要什么的软件设计的。调用一个端点，获取JSON，解析它，然后在其他地方进行计算。这种模型运作良好，并且仍然有效。但我不确定它是否适合LLM驱动的工作流，尤其是在大数据的情况下。
语言模型可以调用API、读取JSON或编写Python代码来实现（Claude代码可以强制输出JSON）。但这并不意味着模型在处理、重塑、连接、聚合、验证或推理大型结构化数据集时是高效的，尤其是通过标记化的行。在小规模时，它适合上下文限制；但在大规模时，它变得复杂，小细节可能会悄然消失，仿佛它们是异常值。
因此，我们正在测试的论点是：
对于大数据集，面向AI的基本操作应该从“返回JSON”切换为“在数据集上执行一个有限的、可检查的操作”，这是一个你可以计划、重放甚至精确追踪的操作。在这种情况下，LLM承担了规划者/控制者的角色。它应该能够检查模式、理解约束、表达操作、检查限制甚至抽象语法树（AST），通过执行层运行计算，然后对紧凑的类型化结果进行推理。
因此，SQL是我们在这一层的当前尝试。
这其实并不新颖，也不是什么神奇的“AI原生”。但它是明确的、可检查的、可组合的，并且接近数据可执行。REST在简单检索时仍然有意义。但对于大型市场数据集的分析问题，JSON分页似乎不是合适的工作单位。
这里还有一个治理问题：在金融行业，许多公司不希望他们的整个工作流迁移到供应商的黑箱接口。这似乎是合理的。内部上下文、权限、模型政策、审计日志和决策工作流当然应该存在于公司的环境中。但这并不一定意味着每个外部数据集在提出任何问题之前都应该被本地复制。
也许更好的边界是：
- 公司拥有工作流和推理运行时
- 数据提供者暴露一个受控的执行表面
- LLM发出有限的操作
- 查询引擎执行实际计算
- 结果返回
我对从事类似工作的人提供的任何反馈都很感兴趣，包括市场数据、量化研究、分析等。我试图回答的问题是：
- 今天，LLM处理大数据的正确接口是什么？
- 模型应该在原始数据、JSON、模式、SQL、类型化工具、语义层或其他什么上操作？
- 客户拥有的运行时与提供方数据执行之间的边界应该在哪里？
当调用者可能是一个代理时，查询限制、成本预览、干运行、权限和审计日志应该如何运作？
我并不只是寻求验证。如果答案是“不要创造一个新的AI类别；只需提供干净的数据、稳定的模式、SQL、文档和可预测的限制”，那也是有用的。
我在手臂上绑上伺服器，这样我就能模拟引擎震动通过手腕传递的感觉，以及通过肘部传递的方向盘拉力。<p>请原谅我糟糕的驾驶，哈哈。
我喜欢Hacker News，但我也喜欢深色模式。我希望在我的iPhone上使用深色模式的Hacker News，而不想使用任何扩展、第三方应用或代理，所以我制作了这个书签小工具。只需点击 news.ycombinator.com，深色模式就会在页面导航中保持有效。我相信之前有人做过这个，但我找不到让我满意的解决方案。想分享一下，以防有人也有同样的需求。
它的工作原理是：书签小工具通常在第一次导航时失效。这个小工具用一个指向Hacker News的同源iframe替换页面，然后在每次iframe加载时重新注入CSS。由于iframe是同源的，一切（包括cookies等）应该都能正常工作。我在Chromium/Linux和Safari/iOS上进行了测试。