最新

有其他人在场，他们的摄像头开着，麦克风关着，会让你更有效率。就像去咖啡馆或图书馆工作一样。

我最大的恐惧是死亡。我最大的恐惧不是害怕失败或其他任何事情。你呢？

我发布了一个针对 AI 助手的维基层，它使用 Markdown + Git 作为事实来源，并在此基础上构建了 bleve (BM25) + SQLite 索引。目前还没有使用向量数据库或图数据库。 它在本地运行于 ~&#x2F;.wuphf&#x2F;wiki&#x2F; 目录下，你可以通过 git clone 将你的知识带走。 这个架构是 Karpathy 一直以来所设想的：一个 LLM 原生的知识库，助手可以从中读取和写入，这样上下文信息就能在会话之间累积，而不是每天早上重新粘贴。大多数实现这种想法的方案都采用了 Postgres、pgvector、Neo4j、Kafka 和一个仪表盘。 我想回归基础，看看在添加任何更复杂的东西之前，Markdown + Git 能走多远。 它的功能： * -> 每个助手都有一个私人的笔记本，位于 agents&#x2F;{slug}&#x2F;notebook&#x2F;.md，并且可以访问团队共享的维基，位于 team&#x2F;。 * -> 草稿到维基的推广流程。笔记本条目经过审查（助手或人类），然后被提升到规范的维基，并带有反向链接。一个小的状态机驱动过期和自动归档。 * -> 每个实体的事实日志：在 team&#x2F;entities&#x2F;{kind}-{slug}.facts.jsonl 中进行追加写入。一个合成工作者每 N 个事实就会重建实体摘要。提交内容使用一个独特的 "Pam the Archivist" git 身份，因此可以在 git log 中看到来源。 * -> [[维基链接]]，带有红色显示的坏链检测。 * -> 每日 lint cron 作业，用于检查矛盾、过时条目和坏维基链接。 * -> &#x2F;lookup 斜杠命令，以及一个用于引用检索的 MCP 工具。一个启发式分类器将短查询路由到 BM25，将叙述性查询路由到引用答案循环。 底层技术选择： Markdown 用于持久性。维基的生命周期比运行时更长，用户可以带着每一个字节离开。Bleve 用于 BM25。SQLite 用于结构化元数据（事实、实体、边、重定向和取代）。目前还没有使用向量数据库。目前的基准测试（500 个工件，50 个查询）仅使用 BM25 就能达到 85% 的 recall@20，这是内部的发布门槛。如果查询类别低于该值，sqlite-vec 是预先提交的备用方案。 规范 ID 是第一类公民。事实 ID 是确定的，并包含句子偏移量。规范 slug 仅分配一次，通过重定向存根合并，并且永不重命名。重建在逻辑上是相同的，而不是字节相同的。 已知限制： * -> 召回率调整正在进行中。85% 的基准测试结果并不能保证普遍适用。 * -> 合成质量受限于助手观察质量。输入垃圾事实，输出垃圾摘要。lint 过程有所帮助，但它不是一个判断引擎。 * -> 仅限于单办公室范围。没有跨办公室的联合。 演示。一个 5 分钟的终端演练，记录了五个事实，触发合成，调用用户的 LLM CLI，并使用 Pam 的身份提交结果：<a href="https:&#x2F;&#x2F;asciinema.org&#x2F;a&#x2F;vUvjJsB5vtUQQ4Eb" rel="nofollow">https:&#x2F;&#x2F;asciinema.org&#x2F;a&#x2F;vUvjJsB5vtUQQ4Eb</a> 脚本位于 .&#x2F;scripts&#x2F;demo-entity-synthesis.sh。 背景。维基作为 WUPHF 的一部分发布，WUPHF 是一个用于 AI 助手（如 Claude Code、Codex、OpenClaw 和通过 OpenCode 的本地 LLM）的开源协作办公室。MIT 许可，自托管，自带密钥。你不需要使用整个办公室来使用维基层。如果你已经设置了助手，只需将 WUPHF 指向它，维基就会附加。 源代码：<a href="https:&#x2F;&#x2F;github.com&#x2F;nex-crm&#x2F;wuphf" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;nex-crm&#x2F;wuphf</a> 安装：npx wuphf@latest 很乐意深入探讨底层技术权衡、推广流程状态机、BM25 优先检索的策略，或者规范 ID 的稳定性规则。也很乐意接受“为什么不使用带有插件的 Obsidian 库”这样的合理问题。

标准的 AI 能源讨论将服务器端 LLM 推理与服务器端的 Google 查询进行比较。我认为这忽略了在真实的搜索会话中，移动设备上实际发生的大部分情况。 我建立了一个完整的端到端移动搜索会话的参数模型：4G/5G 无线电能耗、2.5MB 页面的 SoC 渲染成本、后台运行的程序化广告 RTB 竞价，以及双方的网络传输成本。然后，我将其与等效的 LLM 会话进行了比较。 主要发现在 10,000 次蒙特卡洛抽样中：在移动设备上，标准的 LLM 会话平均比传统的、广告支持的网页搜索会话少消耗 5.4 倍的能量。仅程序化广告就占了每次会话设备电池消耗的 41%。 我试图明确说明的注意事项： * 在固定 Wi-Fi/光纤网络上，优势消失 * 对于推理模型，结果相反 * 参数模型，而非经验性设备测量。Greenspector 已经提出为 v2 运行终端测量 * 适用杰文斯悖论 SSRN 工作论文，未经同行评审。方法论和蒙特卡洛分布在论文中已完全记录。乐于为这些假设辩护。 DOI: 10.2139/ssrn.6287918

嘿，Hacker News！ 我一直想讨论这个话题很久了，我觉得现在我掌握了足够的证据，可以安全地谈论它了。 我一直在尝试将音乐与电影同步播放，并记录其效果。 它们似乎能完美同步，电影就变成了一首歌曲的音乐视频。 我不确定谁观看这些视频是否重要，但我感觉这可能会影响最终的结果。 举个例子，在这里（20:55）就能很明显地看出来：<a href="https://x.com/KyleSerbov/status/2044696810095255732" rel="nofollow">https://x.com/KyleSerbov/status/2044696810095255732</a> 我从未听说过有人真正谈论过这个，所以我很好奇你们对此的看法。 我经常想，电影制作人是否会对我录制的他们的电影感兴趣。 我真的很喜欢这个人在这里（2:22）做的视觉效果：<a href="https://x.com/KyleSerbov/status/2046164265502212137" rel="nofollow">https://x.com/KyleSerbov/status/2046164265502212137</a> 我发现即使音乐倒放也有效。 这里是另一个例子：<a href="https://www.youtube.com/watch?v=w40MXiiXosY" rel="nofollow">https://www.youtube.com/watch?v=w40MXiiXosY</a> 请注意，该视频在澳大利亚、日本、新西兰和英国被地区屏蔽。