最新

嗨，HN， 我是 Nazim，Koinju.io 的创始人。我想在这里分享我们最近推出的一个探索性选项：通过 SQL 访问我们的数据库，该数据库包含所有加密货币市场数据。REST 提供了直接检索的访问方式，但我们越来越认为，通过 SQL 访问统一的加密货币市场数据层进行分析工作可能会有所作为，这要归功于 LLM。 这部分是由 OpenBB 的首席执行官 Didier Lopes 最近发表的关于金融公司拥有金融工作发生的基础设施的论文（https://www.linkedin.com/pulse/how-did-we-end-up-here-didier-rodrigues-lopes-hgeqe/）触发的，特别是工作流程执行和 AI 推理发生的运行时。 大多数数据 API 都是为已经知道自己想要什么软件而设计的。调用一个端点，获取 JSON，解析它，然后在其他地方进行计算。这种模式运行良好，并且仍然运行良好。但我不确定它是否很好地映射到 LLM 驱动的工作流程，尤其是在大数据方面。 语言模型可以调用 API / 读取 JSON 或编写 Python 来实现这一点（Claude 代码可以强制 JSON 输出）。但这并不意味着该模型在通过标记化行摄取、重塑、连接、聚合、验证或推理大型结构化数据集方面是高效的。在小规模时，它适合上下文限制。在大规模时，它变得复杂，并且小细节可能会悄无声息地消失，就像它们是异常值一样…… 因此，我们正在测试的假设是： 对于大型数据集，面向 AI 的原语应该从“返回 JSON”切换到“对数据集执行一个有界、可检查的操作”，你可以规划、重放甚至精确地跟踪。在这种情况下，LLM 承担规划者/控制器的角色。它应该能够检查模式、理解约束、表达一个操作、检查限制甚至 AST，通过执行层运行计算，然后对紧凑的类型化结果进行推理。 因此，SQL 是我们目前在该层进行的尝试。 这真的不是什么新鲜事 :-) 甚至不是神奇的“AI 原生”。但它是显式的、可检查的、可组合的，并且可以在数据附近执行。REST 对于简单的检索仍然有意义。但对于大型市场数据集的分析问题，JSON 分页感觉就像是错误的工作单元。 这里还有一个治理问题：在金融领域，许多公司不希望他们的整个工作流程转移到供应商的黑盒界面中。这似乎是正确的。内部上下文、权限、模型策略、审计日志和决策工作流程可能应该存在于公司环境中，当然。但这并不一定意味着在提出任何问题之前，应该将每个外部数据集复制到本地。 也许更好的界限是： - 公司拥有工作流程和推理运行时 - 数据提供商公开一个受控的执行表面 - LLM 发出有界操作 - 查询引擎执行实际计算 - 结果返回 我对从事此类工作的人（市场数据、量化研究、分析等）的任何反馈都感兴趣。我试图回答的问题是： - 今天，LLM 处理大数据的正确接口是什么？ - 模型应该对原始数据、JSON、模式、SQL、类型化工具、语义层或其他东西进行操作吗？ - 客户拥有的运行时和提供商端数据执行之间的界限应该在哪里？ 当调用者可能是代理时，查询限制、成本预览、试运行、权限和审计日志应该如何工作？ 我不仅仅寻求验证。如果答案是“不要发明一个新的 AI 类别；只需提供干净的数据、稳定的模式、SQL、文档和可预测的限制”，那也会很有用。

所以，如果因为其他任何原因丢掉工作，我都无所谓。市场不好、公司转型，甚至是我自己犯的蠢… 没关系，这就是生活。但如果因为我投入到开源项目中的热爱而丢掉工作？拜托，这真的让我火大。 我像其他人一样，周末做一些好玩的副业项目，凌晨两点为素未谋面的陌生人解答 Stack Overflow 上的问题，还有一些没人给我钱的仓库… 说实话，这种文化氛围是作为一名开发人员最棒的地方，而现在它却成了训练集。我讨厌 OpenAI/谷歌/Anthropic 等公司抓取了所有这些内容，从中学习，然后把我们的热爱当作产品卖给我们。当然，我明白，这就是资本主义，随便吧，但我觉得自己像个最大的傻瓜。我想我只能接受它，埋头苦干。但我最不喜欢的是：周围那些美化 AI/LLM 的人。高层迟早会因为 AI 而进一步裁员，我们 90% 的人都会受到影响。人们，不是所有事情都只关乎技术细节！

一个 API，支持 WhatsApp、短信和电子邮件<p>www.sendapi.co