Probuck Workspace

嗨，Product Hunters 👋

经过两年的研究和数月的开发，Probuck Workspace（probuck.ai）正式上线。我想分享背后的「为什么」，因为我认为这正是大多数 AI 文档工具做错的地方。

一切的起点：那个问题

我曾使用各种 AI 工具来实现文档处理用例，主要涉及从非结构化 PDF 中提取准确的数值数据点。我尝试过的所有工具，都是标准向量 RAG 的实现——将文档分块、嵌入分块、检索最近邻，再让大语言模型写出答案。

对于「总结这份合同」或「这份报告里关于 X 说了什么」这类问题，这种方法没问题。但当你问「第 47 页成本表中第 14 行第 3 列的值是多少？」时，它就垮了——因为模型看到数据的时候，表格已经被扁平化成了一锅文字汤，行列关系早已消失，大语言模型基本上是在猜哪个数字对应哪个标签。在施工进度报告或财务报表里，「猜」是一种不可接受的失败模式。

于是我打造了我自己想要的东西。

Probuck 真正的不同之处

两个核心想法，其他一切都由此延伸而来。

1. 保留结构的文档摄取。文件由视觉模型逐页处理，像人类一样阅读文档——保留表格结构、布局以及传统文本提取会破坏的上下文关系。表格以其原始的行列形式存储，而非被扁平化为文本，随后每份文档都会被双重索引，同时支持语义向量搜索和全文关键词搜索。正是这种双重索引让其他一切成为可能。

2. 混合检索引擎，采用「确定性优先」的回退链。三种 AI 驱动的策略，一条链路，完全可审计：

DTR——确定性表格检索。AI 智能体识别候选表格及正确的行列映射，然后通过纯编程方式查找并提取单元格的值。数值本身不再涉及任何 AI 处理。

GTR——引导式表格检索。同样由智能体识别表格和映射，但读取环节由 AI 引导的检索步骤处理。用于 DTR 在格式不一致、单元格合并或扫描质量差时力不从心的场景。

RAG——检索增强生成。高级混合搜索将最相关的内容喂给 AI 智能体，生成自由文本式的回答。最适合叙述性问题，也作为表格检索失败时的语义回退方案。

查询按此顺序遍历整条链路，每一步都会被记录——检索尝试、候选表格、匹配的行/列、所选策略、最终答案。每一个答案都可追溯，每一步检索都可审查。你可以为自己的工作流程辩护，而不仅仅是那个数字。

还有第四种模式——PRT（编程式表格检索）——用于你已知确切行列措辞的可重复提取场景。无需大语言模型，没有回退，零 token 消耗。这是面向「审计级、无 AI 风险」工作流的选项，适用于跨数百份文档运行相同查找的工作流。

在整体工作流中的位置

引擎之上承载着三个界面：

文档浏览器（Document Explorer）——通过自定义元数据、分组和细粒度访问控制来浏览、搜索和管理文档库。

文档聊天机器人（Document Chatbot）——基于你的语料库进行自然语言问答，回答有引用支撑，每个答案背后都附带完整的诊断轨迹。

智能体工作流（Agentic Workflows）——构建多步骤工作流，并跨数百份文档运行，将用于结构化/可审计步骤的混合检索与用于推理步骤的生成式 AI 相结合。

当某个工作流需要将内部文档智能与更新鲜的数据融合时，这三个界面都可以选择性地引入外部实时数据（网页、API、直接上传到上下文中的文件）。

技术栈——献给好奇的 Product Hunters

TanStack Start 运行在 Cloudflare Workers 上，Supabase（Postgres + pgvector）作为数据库并实现 RLS，Cloudflare R2 用于对象存储，AI 层采用 BYOK（Google AI、Vertex AI 或 OpenRouter），让客户掌控自己的支出和数据驻留。Paddle 作为全球计费的商户记录方。

我期待从 Product Hunt 社区得到……

反馈。关于网站（probuck.ai）——尤其是「它是否真的讲清楚了自己在做什么」这个问题。关于产品本身。它有用吗？它擅长做什么？哪些地方可以做得更好？

引荐。介绍任何正在被非结构化 PDF 淹没的人（金融、法律、建筑、研究领域）。

实战故事。来自任何尝试让 RAG 表现得更确定性的人——我真心想交流对比心得。

欢迎随时问我任何关于架构、BYOK 决策、或为什么我认为纯向量 RAG 在数值提取上是一条死胡同的问题。

感谢阅读 🙏