retrieval. Article 7 (retrieval) introduces the unified retrieve_context(question, line_df, *, method, top_k, ...) → RetrievalResult dispatcher that routes to keyword / embedding / TOC / hybrid behind a single signature, and returns a typed RetrievalResult instead of two tuples. We use the raw retrieve_pages and reason_on_toc here to keep this article incremental on top of Article 1 (minimal RAG); production code calls retrieve_context or the shared dispatch_page_retrieval helper. A useful check before trusting that table. The first matching line column scans line by line, one line at a time. That works for single-token keywords. A multi-word keyword like positional encoding can be broken across a line break in the PDF, with positional at the end of one line and encoding at the start of the next. Each line on its own contains neither phrase. The line-by-line scan finds nothing, even when the keyword is right there on the page. Count the misses across the document: The line is a PDF rendering artifact. The text the parser sees as one line is whatever fits between two visual line-break decisions made by the PDF generator. There is no semantic reason the unit of detection should map to that arbitrary boundary. The fix is to detect on a passage instead, where a passage is a small window of adjacent lines joined with a space. Any keyword that exists in the passage will be found, no matter where the line breaks fall. The page-level match_count was already correct, because retrieve_pages joins all lines on a page before scanning. The fix targets the line-grained helpers that the snippet column, the highlighting, and any later chunking step need. From here on, every helper that scans below the page level uses a passage window, not a single line. The LLM TOC router fills the other gap exposed above. Same toc_df from parsing, but the LLM reads it whole and reasons about which section answers the question, returning the picked section ids plus a one-sentence rationale. The function itself is short (format each TOC row, drop it in a prompt with the question, parse a typed SectionSelection back); Article 7B (anchor detection) shows it in full. Run on the noisy question against the paper’s 22 TOC entries: One LLM call, the whole TOC inside the prompt, a typed list of section_ids back with a sentence of reasoning. The substring matcher this article used to ship would have caught 3.5 Positional Encoding on this specific question because encoding appears in the title. It would have missed every question phrased differently from the author. “What happens if we exit early?” against a contract whose section is titled “Termination” : substring zero, LLM one. The cost is a small LLM call (a few thousand tokens for a typical TOC, a few hundred milliseconds), and it is cached forever on identical inputs. This view is what an expert reads. Not a flat page list with cosine scores, but the document’s own outline, with the parsed-question keywords marked where they land. Article 7C (the LLM arbiter) consumes exactly this shape as a structured brief, one row per candidate, and ranks them with per-candidate roles + reasons. That arbiter is an upgrade on top of the LLM TOC router walked above, kept out of scope here to stay incremental on Article 1 (minimal RAG). For the retrieval code in detail, see the three articles that develop the brick: Generation fills a typed schema from the retrieved lines. It is controlled execution against a contract, not free-form prose.

In: the GenerationBrief (question and answer shape, from question parsing), filtered_line_df (from retrieval), and the answer schema. Out: a typed AnswerWithEvidence , or a ListAnswer when the question asks for a list. Article 1 (minimal RAG)’s AnswerWithEvidence returns one answer: str , one contiguous evidence span, a few quotes. Good for a question with a single answer ( “What dataset was used?” ). The running question asks for options , plural. The baseline schema can list them inside the string, but the caller has no clean way to iterate over the items or to attribute one citation per option. Article 8 makes the schema match the shape of the expected answer. When the question parser flagged expected_answer_shape = "listing" (Article 12 (listing) develops these in depth), the generation brick returns a ListAnswer with one entry per item, each carrying its own evidence span and its own verbatim quote. The shape is what matters: one AnswerItem per option (its text , a start/end line-range span, and a verbatim quote ), wrapped in a ListAnswer that also carries the answer-quality flags ( answer_found , complete_answer_found , context_structured , confidence , caveats ). Article 8 (generation) develops the schema in full. Filled in on the noisy positional-encoding question, the schema returns two items and the full set of quality indicators: { "items": [ { "text": "Sinusoidal positional encodings (sine and cosine functions of different frequencies).", "start_page_num": 6, "start_line_num": 33, "end_page_num" "quote": "we use sine and cosine functions of different frequencies" }, { "text": "Learned positional embeddings.", "start_page_num": 6, "start_line_num": 39, "end_page_num" "quote": "we also experimented with using learned positional embeddings" } ], "complete_answer_found": true, "confidence": 0.98, "caveats": [] } The four indicators carry the answer’s trust profile . complete_answer_found says whether the answer covers every option the document mentions or only a subset. context_completeness says how well the retrieved lines covered the question, separate from whether the answer itself is right. context_structured flips to false when the LLM cannot follow the reading order, the canonical OCR-failure signal. A downstream router reads them: high confidence + complete + structured = ship the answer; low completeness or unstructured context = retry retrieval, or fall back to a deeper parse (the path Article 10 develops). context_structured is the indicator the article does not get to see fire on a clean paper. To prove the LLM uses it, the same lines fed in random order should flip it to false: { "clean context": { "complete_answer_found": true, "confidence": 1.0, "caveats": [] }, "shuffled context (same lines, random order)": { "complete_answer_found": true, "confidence": 0.95, "caveats": [] } } In production, scrambled context comes from a different source than . PDFs with two-column layouts that the parser read column by column instead of row by row, scanned documents OCR’d by a model that lost the layout, exports from Word that broke long tables across hidden anchors. The pipeline cannot self-correct on those, but the answer schema tells the caller something went wrong, and a separate code path takes over. Compare with the baseline RAG output. Same question, same paper, but the caller now gets a structured object: number of items known up front, each item independently citable, four quality indicators that route the answer to

the right next step. A UI renders the items as a clickable list. A SQL pipeline writes one row per item. An annotated PDF highlights each quote on its source page. None of those consumers had to parse prose, and none of them ships a confidently-wrong answer because the schema makes the failure modes visible. Four bricks, four upgrades. Side by side, the same pipeline before and after, one brick per row: The four upgrades are independent. A team running Article 1 (minimal RAG)’s pipeline can adopt them one at a time: a TOC at parsing, a corpus-vocab spell-check at question parsing, an LLM TOC router + keyword fallback at retrieval, a list-shaped schema at generation. Each one is a small drop-in, none of them rewrites the surrounding code. The four bricks now speak in typed contracts: Each upgrade earned its place against a concrete failure of the baseline: the typo that missed the page, the TOC the keyword search ignored, the list flattened into prose. What the bricks do not have yet is a single entry point and a feedback path between them. The second part wires them into one call and runs it on real documents, including one whose TOC is broken, in Composing the four RAG bricks into one pipeline, tested on real documents (link to come). It helps to see where this pass

Wayflow

开发者可以快速将完整的工作流编辑器集成到产品中，只需一个函数调用即可挂载画布、节点面板、配置面板和运行控制面板，无需自行构建基础界面。Wayflow 内置真实执行引擎，支持在浏览器中无需后端运行原型，并可在生产服务器上执行相同的工作流。该工具在 AI 与传统逻辑之间实现灵活切换，内置 LLM、工具调用、分支等节点，可与精确的确定性步骤混合使用，按需选择 AI 强度。系统原生支持人工介入，可在审批或决策时暂停工作流，之后继续执行。Wayflow 采用供应商中立的 LLM 与图像适配器，避免锁定单一模型。编辑器支持可定制主题，并适配亮色与暗色模式。该工具适用于客户支持工单处理、内容生成与翻译、AI 代理自主规划执行，以及数据管道构建等场景。 #Wayflow #开源 #AI #工作流引擎 #LLM #人机协同 #DevTools #自动化 #数据管道

Prizmi 发布主动式 AI 助手，自动代劳日常任务

一款名为 Prizmi 的主动式 AI 助手正式发布。它可连接用户的手机与电脑，在获得授权后自动执行邮件回复、家人关怀提醒、跨设备编码协助、网页表单填写、文件整理等任务。Prizmi 强调用户对数据的完全掌控：所有操作需经批准，敏感任务采用端到端加密，数据不会用于 AI 训练，用户可随时删除账户。目前 Prizmi 提供 5 美元免费额度供试用，无需绑定信用卡，且已推出 Linux、Windows、macOS 桌面应用。 #AI助手 #Prizmi #主动式AI #隐私保护 #自动化 #效率工具 #科技新闻

Signal for LLM 调制器架构发布，理论部分宣告完成

Signal for LLM 项目于Hacker News亮相，其专为大型语言模型设计的调制器架构（Modulator Architecture）理论部分现已告竣。该项目集成SignalEngine（信号引擎）文档、面向LLM的 README，以及SignalEngine/TGR 框架文档中心。TGR全称为Thixotropic Generative Recursion（触变性生成递归），旨在统一信号工程与生成递归技术。整套文档托管于GitHub Pages，并可在Termux环境下运行。该架构为LLM信号处理与交互模式提供了新的理论框架，有望推动相关技术发展。 #HackerNews #SignalEngine #LLM #调制器架构 #TGR #信号工程 #生成递归 #GitHub #Termux

Declaw 凭据保险库

传统的 AI 代理安全方案通常将 API 密钥等凭据以环境变量形式放入运行代理的沙箱中，但沙箱正是不可信代码的执行环境，一旦代理被提示注入或依赖遭入侵，凭据极易泄露。Declaw 的新设计将凭据彻底隔离在沙箱之外：代理运行于 Firecracker 微虚拟机中，出口代理位于主机端网络命名空间，成为 VM 唯一的网络出口路径。秘密仅在一次请求期间存在于代理内存中，从不写入虚拟机内的文件、环境变量或日志。每个沙箱拥有专属临时 CA，代理为每个上游主机签发短期证书，并利用系统信任链实现 HTTPS 请求的凭据透明注入。即使代理被完全攻陷，攻击者也只能看到占位符，无法获取真实凭据。但该方案对固定上游证书的客户端存在限制。 #AI安全 #凭据管理 #Declaw #沙箱 #代理 #Firecracker #虚拟化 #信息安全 #技术架构