最新

大家好，我们是 Lewis 和 Edgar，正在构建 Captain，以简化非结构化数据搜索 (<a href="https:&#x2F;&#x2F;runcaptain.com">https:&#x2F;&#x2F;runcaptain.com</a>)。Captain 自动化构建和维护基于文件的 RAG 管道。它索引云存储，如 S3 和 GCS，以及 SaaS 来源，如 Google Drive。这里有一个快速演示：<a href="https:&#x2F;&#x2F;youtu.be&#x2F;EIQkwAsIPmc" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;EIQkwAsIPmc</a>。 我们还搭建了一个名为“Ask PG 的文章”的演示网站，您可以在其中搜索 PG 的文章语料库，以了解它的工作原理：<a href="https:&#x2F;&#x2F;pg.runcaptain.com">https:&#x2F;&#x2F;pg.runcaptain.com</a>。设置这个 RAG 部分 Captain 大约花了 3 分钟。 以下是一些示例提示，让您感受一下体验： “我们什么时候做那些不可扩展的事情？我们什么时候应该更谨慎？” <a href="https:&#x2F;&#x2F;pg.runcaptain.com&#x2F;?q=When%20do%20we%20do%20things%20that%20don&#x27;t%20scale%3F%20When%20should%20we%20be%20more%20cautious%3F">https:&#x2F;&#x2F;pg.runcaptain.com&#x2F;?q=When%20do%20we%20do%20things%20...</a> “给我一些建议，我正在融资” <a href="https:&#x2F;&#x2F;pg.runcaptain.com&#x2F;?q=Give%20me%20some%20advice%2C%20I&#x27;m%20fundraising">https:&#x2F;&#x2F;pg.runcaptain.com&#x2F;?q=Give%20me%20some%20advice%2C%20...</a> “Lisp 最大的优势是什么” <a href="https:&#x2F;&#x2F;pg.runcaptain.com&#x2F;?q=what%20are%20the%20biggest%20advantages%20of%20Lisp">https:&#x2F;&#x2F;pg.runcaptain.com&#x2F;?q=what%20are%20the%20biggest%20ad...</a> 一个好的生产级 RAG 管道需要付出大量努力来构建，尤其对于文件工作负载而言。您必须处理 ETL 或文本提取、分块、嵌入、存储、搜索、重新排序、推理，并且通常还需要合规性和可观察性——所有这些都需要在优化延迟和可靠性的同时进行。这需要大量管理。grep 在某些情况下效果很好，但对于代理来说，语义搜索提供了明显更高的性能。Cursor 同时使用这两种方法，并报告向量搜索比 grep 提高了 6.5%–23.5% 的准确性 (<a href="https:&#x2F;&#x2F;cursor.com&#x2F;blog&#x2F;semsearch" rel="nofollow">https:&#x2F;&#x2F;cursor.com&#x2F;blog&#x2F;semsearch</a>)。 在过去的四年里，我们一直在为公司扩展 RAG 管道，Edgar 在普渡大学 NLP 实验室的工作直接影响了我们的分块技术。在与数十位工程师的交流中，我们反复看到 DIY 管道产生不一致的结果，即使在经过数周的调整之后。许多团队不清楚哪种检索策略最适合他们的数据。 我们意识到，一个可以提供存储和嵌入、处理索引并持续更新管道以反映最新搜索技术的系统，可以消除每个团队自己重建 RAG 的需求。这个想法变成了 Captain。 实际上，一个 API 调用就可以索引 URL、云存储桶、目录或单个文件。在幕后，我们将所有内容转换为 Markdown。为此，我们在图像方面使用 Gemini 3 Pro 取得了良好的效果，Reducto 用于复杂文档，Extend 用于基本 OCR。对于嵌入模型，'gemini-embedding-001' 最初表现良好，但后来我们切换到了来自 'voyage-context-3' 的 Contextualized Embeddings。它产生了比甚至更新的 Voyage 4 模型更相关的结果，因为它的块嵌入是使用对周围文档上下文的感知进行编码的。然后，我们应用了 Voyage 的 'rerank-2.5' 作为第二阶段的重新排序，将 50 个初始块减少到最终的 15 个（可在 Captain 的 API 中配置）。密集嵌入只是部分内容，而具有 RRF 的全文搜索完成了我们的混合检索。在 Captain API 中，这些技术通过单个 /query 端点公开。访问控制可以通过元数据过滤器进行配置，并且会自动返回页码引用。 技术栈在不断变化，但 Captain API 为此创建了一个标准接口。您可以免费试用 Captain 1 个月，并在 <a href="https:&#x2F;&#x2F;runcaptain.com">https:&#x2F;&#x2F;runcaptain.com</a> 上构建您自己的管道。我们正在寻找坦诚的反馈，特别是任何可以使其更有用的东西，并期待您的评论！

大家好，我是 Ryan，一个会写代码的产品设计师，我开发了 Mesa。现在的 IDE 感觉不太适合现在这种开发方式——它们仍然以文件为中心。<p>Mesa 关注的是完整的开发流程：你的代理、终端、浏览器和文件都作为同等节点存在于一个画布上，并支持完全的多人协作。（想象一下 Figma，但它是为代码设计的）<p>我厌倦了在多个项目中切换窗口、标签页和终端的麻烦。受到 TouchDesigner 和 Factorio 的启发，我想要一些更流畅、更可视化的东西。现在每天在工作中都用它完全替代了 Cursor。能够同时查看多个代码库，并在每个代码库上控制代理，而无需切换窗口，这解放了我的思维空间，提高了工作效率。<p>可以免费试用——很想知道你们的想法！

我构建了一个小型网络工具，尝试自动将混乱的提示词重构为结构化的提示词规范。 动机很简单：大多数人编写的提示词结构都很差，这通常会导致 AI 响应不稳定。 因此，我实现了一个提议者-评论者-验证者优化流程： * 提议者重构提示词。 * 评论者评估清晰度、结构和任务定义。 * 验证者检查一致性。 * 仲裁者检测收敛。 系统运行多次迭代，生成结构化的提示词规范。 通常需要大约 30-40 秒来运行完整的优化循环。 该工具还包括： * 提示词质量分析 * 解释模式 * 版本历史 * 提示词差异查看器 演示： [https://how-to-grab-me.vercel.app/](https://how-to-grab-me.vercel.app/) 很想知道构建 AI 工具的人是否觉得类似的东西有用。

上周五，我开始和 Claude 聊操作系统。那次对话变成了一场设计讨论。设计讨论又变成了一个原型。从那以后，我几乎就没停下来过。 核心想法是：你的文件存在于应用程序内部。应用程序决定你如何查看内容、可以对内容做什么以及你的工作保存在哪里。如果操作系统可以直接理解你的文件——渲染它们、索引它们、跟踪它们的历史——并且编辑器只是在你需要更改某些内容时才使用的工具，会怎么样呢？没有“打开方式”。没有保存按钮。默认情况下是查看，编辑是深思熟虑的行为。 一周后的成果：一个用 Rust 从头开始编写的基于 QEMU (aarch64) 的内核，27 个系统调用，带有 4 个 SMP 核心的 EEVDF 调度器，完整的显示管道（合成器、子像素 TrueType 渲染、alpha 混合、PNG 图像查看器），通过共享内存环形缓冲区的结构化 IPC，一个编辑器进程模型（操作系统服务是唯一的写入者），一个文件系统原型，900 多个测试，包括正式的错误审计，以及大约 2200 行的设计文档，其中包含 13 个已确定的架构决策。而我周五之前甚至都没见过 Rust 代码。 完整的故事，包括演示、逐日时间线、我如何与 AI 合作以及我学到了什么：[https://github.com/jonathanrtuck/os/discussions/1](https://github.com/jonathanrtuck/os/discussions/1) 代码库：[https://github.com/jonathanrtuck/os](https://github.com/jonathanrtuck/os) 我不是想构建下一个 Linux。这是一次设计探索——如果从内核开始重新思考整个堆栈，OpenDoc 和 Xerox Star 尝试的以文档为中心的模型是否真的可行？我真的很好奇这个社区的想法。