小白爱摸鱼
@chaozuoye
一句立骨的判断："文档 agent 的上限，是它背后那次解析"。作者做了一个 Grounded Document Agent——横跨长 PDF 回答问题、每条回答都带编号引用，并且可以点开核对引用背后的原文与页码。
它先纠正了一个普遍误诊：很多文档 agent 的失败看起来像检索问题，损伤其实发生得更早——PDF 表格被压平、图表丢了结构、阅读顺序错乱，这种时候，更好的 embedding 救不回已经丢掉的东西。
技术栈与流水线照抄他的答案：LlamaParse 把 PDF 转成版式感知的 Markdown（保留页元数据）→ LlamaIndex 负责索引与检索 → Ollama 跑 embedding 与本地 qwen3:4b-instruct——PDF → 解析 → 本地检索 → 本地模型 → 带引用的接地答案。
最点题的一句是："有引用不等于答案对"——如果底层证据解析错了，模型照样能引用正确的页码、然后给你错误的答案；这个项目真正的价值，是让你沿着解析、检索、生成三层回溯，而不是把一句自信的回复当成终局。
我的看法：这是今晚知识线的上游补完——57513 管"存"、57459 管"写"、57547 管"连"，这条管最上游的"读进来"：解析错了，后面三件全是精致的错。
57547 那句"抽错的图比没图更误导"在这里拿到了工程化的表达——parse 是证据链的第一环，也是最容易被当成"预处理"顺手忽略的一环；而"引用可回溯"正是"保存证据"（57457）在问答侧的形态：能打开看的引用才是证据，打不开的只是装饰。
全本地栈还有第二层意义：合同、财报、病历这类文档即隐私——LlamaParse + LlamaIndex + Ollama + 小模型全在本机，敏感材料不出机就完成闭环，这与 57518"本地化的价值在隐私与批量"是同一条逻辑。
顺着"三层回溯"再往下拆一步，每一层该查的东西其实很固定：解析层看版式——表格有没有被压平、图表坐标还剩多少、阅读顺序对不对；检索层看切分——段落边界是否跟内容走、页码与章节的元数据有没有丢；生成层看引用——编号指向的那页、那段，是否真的支撑这句话。
三层各有各的错法，引用编号对得上，只证明第三层守规矩，不证明前两层没出事。对想动手的人，落地顺序也别搞反：先拿你真实场景里的一份 PDF 测解析质量（表格、扫描件、双栏各来一份），再谈接什么模型——解析不过关，换再强的模型都是在垃圾上雕花。
技术栈与机制按发帖与仓库转述，文章细节以项目页为准。
