一个8GB显存的笔记本GPU，128K的上下文窗口，没有向量数据库，没有分块器，没有检索器。Yash Saini花了五天时间，用约500行Python写了一个叫DeepRead的工具，直接把PDF页面塞进Gemma 4 E4B的上下文里做问答。
这个项目的核心假设很直接：对于他实际阅读的文档——研究论文、内部备忘录、某个项目的API文档——RAG是过度工程。
DeepRead的工作流程是这样的。右侧边栏有个Papers选择器，预装了五篇经典CS论文（Attention、GFS、MapReduce、Raft、Bitcoin），也可以上传自己的PDF。点击后约半秒完成加载，边栏的Plotly进度条变绿，显示128K窗口已被占用多少。然后直接提问，回答会带脚注标记[^1]、[^2]，指向具体论文的具体页面。模型在提示构建阶段就被约束只能使用已知列表中的页面ID——所以它物理上无法编造页码。
诊断功能也集成在同一个聊天界面里，用斜杠命令触发。/bench show渲染最新的"大海捞针"测试结果，三张Plotly图表分别显示通过率、每秒token数、首token时间。/bench run --ctx 5000 20000 60000 --needles 5启动新一轮测试。不用切标签页，不用另开会话，不用清空聊天记录。
为什么选E4B？作者在README里写了四个性质的交集：128K上下文窗口，足以在单次调用中容纳完整研究论文加补充材料；原生视觉能力，能处理150 DPI渲染的PDF页面，无需OCR流水线；原生音频输入（为下一版本预留）；以及约9.6GB的磁盘占用，能在8GB笔记本GPU上运行。26B和31B变体或许能提升推理质量，但会杀死"笔记本本地运行"这个故事——而DeepRead的全部意义就在于数据不出本机。E2B更便携，但在长上下文的多步推理上损失精度。E4B是精确的平衡点。
作者把"不用RAG"列为最自豪的决定。过去两年用过的"AI文档助手"都是同一个形状：分块、嵌入向量库、检索top-k、用检索到的块提示托管LLM。RAG能工作，但也是一座需要持续对齐的活动部件山：块大小、重叠度、嵌入模型版本、top-k值、重排序阈值。而且走完这套流程，你的文档已经被送到了某个地方的服务器上。
热门跟贴