最新

嗨，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、文档和可预测的限制”，那也是有用的。

所以我不介意因为几乎任何其他原因而失去我的工作。糟糕的市场、公司的转型，甚至我自己的愚蠢错误……好吧，这就是生活。但因为我在开源项目中投入的热情而失去工作？拜托，这真的让我很生气。 我像其他人一样，周末做一些副项目只是为了好玩，凌晨两点在Stack Overflow上为陌生人解答问题，做一些没人付我钱的代码库……老实说，这种文化是作为开发者时最好的事情，而现在却成了训练数据。我讨厌OpenAI、谷歌、Anthropic等公司抓取这一切，学习其中的内容，然后把我们的热情作为产品卖回给我们。没错，我明白，这是资本主义，随便吧，但我感觉自己是个最大的傻瓜。我想我只能接受这一切，低下头继续前行。不过，有一件事我最不喜欢：这里的人们美化人工智能和大型语言模型。高层们迟早会正常化因为人工智能而进一步裁员，90%的人都会受到影响。人们，事情并不只是关于技术细节！

一个用于WhatsApp、短信和电子邮件的API <p>www.sendapi.co