最新

我做了一个简单的应用，帮你掌控自己的时间。Alnuo。 你选择时间。你选择时长。它会提醒你。 无需账号。就这么简单。 欢迎反馈。

我喜欢从黑客马拉松活动中获得酷炫的周边，也喜欢设计 PCB，所以当我的朋友问我是否愿意为在新加坡举办的大型游戏创作马拉松活动设计黑客马拉松徽章时，我毫不犹豫地答应了！ Overglade 的主题是“游戏中的游戏”，这概念很酷吧！来自世界各地的高中生在 Hack Club 的资助下参加了这次活动，此前他们花了大约 70 个小时设计自己的游戏。 这些徽章需要非常便宜和简单，因为我们要在很短的时间内制造大约一百个。我采用了零功耗方案，这意味着使用电子墨水屏，并且我决定加入 NFC 功能，如果组织者想将其引入活动的角色扮演中，参与者也可以选择添加他们的网站或 GitHub！ 我使用了基于 RP2040 的架构，因为它非常容易且便宜，而且第一次尝试就能成功，然后添加了一个 ST25 无源 NFC 标签，配置起来非常简单。徽章的形状像一张票，因为你花了大量时间设计游戏来获得资格后，就得到了参加活动的“门票”！如果遇到黑客马拉松活动的紧急情况，边缘有 20 个 GPIO 可用，而且我希望徽章看起来真的很有趣，所以有很多由社区里不同的人设计的艺术作品！ 徽章运行得非常好，我在此过程中学到了很多东西。我的经验是制造大量的备用徽章，因为有些最终会损坏；在 3D 模式下考虑你的 PCB，因为其中一个电感器有点高，导致更多的徽章损坏；并且对你的最终产品有一个清晰的愿景，因为它真的帮助我创造了一些独特而美丽的东西 :D 我喜欢记录我所有的项目，所以如果你想阅读我的完整设计过程，请随时查看我的日志 (<a href="https://github.com/KaiPereira/Overglade-Badges/blob/master/JOURNAL.md" rel="nofollow">https://github.com/KaiPereira/Overglade-Badges/blob/master/J...</a>)。如果你也有任何问题或反馈，我很乐意回答！

你觉得呢？

我构建这个工具，是因为我反复遇到同样的难题——在应用程序代码中没有好的方法来强制执行 token 预算。服务提供商的限制是账户级别的，只能告诉你发生了什么，而不是正在发生什么。 两种添加方式： ``` # 直接客户端封装 client = tokencap.wrap(anthropic.Anthropic(), limit=50_000) # LangChain, CrewAI, AutoGen 等 tokencap.patch(limit=50_000) ``` 在可配置的阈值下，有四种操作：WARN（警告）、DEGRADE（透明的模型切换）、BLOCK（阻止）和 WEBHOOK（网络钩子）。开箱即用支持 SQLite，Redis 用于多代理设置。 一个值得一提的设计决策：tokencap 跟踪的是 token，而不是美元。Token 计数直接来自服务提供商的响应，并且不会随着价格变化而改变。 欢迎随时提问。

在为一家旧金山初创公司构建金融助手时，我们了解到，人工智能框架并不能带来价值，反而增加了复杂性。当我开始使用 GraphRAG 构建个人助手时，我吸取了这一教训，但仍然尝试了 LangChain 的 MongoDBGraphStore。它在 10 分钟内为我提供了一个可用的知识图谱。 然后我查看了数据。仅仅从 5 份文档中，我就得到了 17 种节点类型和 34 种关系类型，其中包括三个版本的“属于”。GraphRAG 实际上是一个数据建模问题，而不是一个检索问题。 附图展示了我最终使用的 11 步流程。以下是每个步骤的详细介绍。 基本上，在数据流程的第 1 步和第 2 步中，原始数据源会经历一个提取、转换、加载 (ETL) 过程。它们作为文档存储在 MongoDB 数据仓库中。每个文档都存储了源类型、URI、内容和元数据。 然后在第 3 步中，我们清理文档并将其分割成以 token 为界限的块。我们最初使用 512 个 token，并有 64 个 token 的重叠。但我们仍然需要对此进行更多测试。 关键是，第 4 步处理图谱提取。我们定义了一个严格的本体。本体只是一个正式的协议，定义了数据中确切存在的类别和关系。我们使用了 6 种节点类型和 8 种边类型。大型语言模型 (LLM) 只能提取本体允许的内容。 例如，如果它输出了一个 PERSON 到 TASK 的连接，并带有 EXPERIENCED 边，流程就会拒绝它。EXPERIENCED 必须将 PERSON 连接到 EPISODE。 我们还将 LLM 提取与确定性提取分开。我们创建结构化条目，如 Document 或 Chunk 节点，而无需调用 LLM。 事实证明，第 5 步的规范化是最难的部分。我们使用一个三阶段的去重过程。我们进行内存模糊匹配、针对 MongoDB 的跨文档解析和边重新映射。 总而言之，在第 6 步中，我们批量嵌入节点。系统使用模拟进行测试，使用 Sentence Transformers 进行开发，并使用 Voyage API 进行生产。 最终，在第 7 步和第 8 步中，节点和边被存储在单个 MongoDB 集合中，作为统一的内存。我们使用确定性的字符串 ID，如“person:alice”来防止重复。MongoDB 在一个聚合管道中处理文档、$vectorSearch、$text 和 $graphLookup。$graphLookup 函数原生遍历数据库中连接的图数据。对于大多数代理用例，你不需要 Neo4j + Pinecone + Postgres。像 MongoDB 这样的单个数据库就能很好地完成任务。通过分片，你可以将其扩展到数十亿条记录。 总而言之，第 9 步到第 11 步涵盖了检索。代理通过 MCP 服务器调用工具。它使用混合向量、文本和图谱扩展的搜索内存，以及用于自然语言到 MongoDB 聚合的查询内存。代理还使用摄取工具写回数据库以进行持续学习。 以下是我仍在努力解决的一些问题，我很想听听你的意见： * 你如何处理跨文档的实体/关系解析？ * 什么对你优化使用 LLM 提取实体/关系最有帮助？ * 在图谱更新后，你如何保持嵌入的同步？ 此外，在构建我的个人助手时，过去几个月我一直在 LinkedIn 上撰写关于这个系统的文章。以下是更深入介绍每个部分的帖子： * 运行嵌入模型的 3 种方法：[https://www.linkedin.com/feed/update/urn:li:activity:7443288346153480192](https://www.linkedin.com/feed/update/urn:li:activity:7443288346153480192) * LangChain 在 10 分钟内为我提供了一个知识图谱：[https://www.linkedin.com/feed/update/urn:li:activity:7440751582381494272](https://www.linkedin.com/feed/update/urn:li:activity:7440751582381494272) * Palantir 凭借本体优先的人工智能建立了 4000 亿美元的帝国：[https://www.linkedin.com/feed/update/urn:li:activity:7434591082367320064](https://www.linkedin.com/feed/update/urn:li:activity:7434591082367320064) * 数字孪生代理的摄取架构：[https://www.linkedin.com/feed/update/urn:li:activity:7432054336589021184](https://www.linkedin.com/feed/update/urn:li:activity:7432054336589021184) * 大多数人工智能代理不需要三个数据库：[https://www.linkedin.com/feed/update/urn:li:activity:7426981104227856385](https://www.linkedin.com/feed/update/urn:li:activity:7426981104227856385)