Agent 与工作流01
LangChain 把自家开源工具 OpenWiki（一个把原始文档编译成带引用维基页面的命令行工具）当作 Agent 的长期记忆层，并额外用一张"证据图谱"把维基里的结论和它背后的原文段落连起来。原来的问题是：Agent 每次回答跨文档的问题都要临时检索、拼凑，既慢又容易答错。这次的做法是提前把 111 份模拟保险文档编译成约原体积十分之一的维基，再让 Agent 顺着图谱找到支撑证据。结果显示，涉及多来源关联的问题准确率比只用关键词搜索高约 5 倍；加上证据图谱后准确率再提升 27%，引用一致性翻倍，每个正确答案的成本降低 58%。不过对于简单的单段查找，带记忆反而更慢、准确率没提升，所以这套方案更适合需要反复跨来源推理的场景。该工具已开源，文中未说明证据图谱是否单独开放。
文中可用工具
- OpenWiki开源命令行工具，把原始文档编译成带引用、可随源文档变化自我更新的维基页面，用作 Agent 的持久记忆层
- Deep AgentsOpenWiki 构建所基于的框架，原文未详细说明其用途
- 证据图谱把维基中的结论与支撑原文段落、相关文档用边连接起来，供 Agent 追溯引用来源
Agent 与工作流02
英伟达在 GTC 柏林大会上把一组开源组件加入 Agent Toolkit，组成了 Agent Knowledge Foundation。它包含 Nemotron Retriever 检索模型、Auto-Ontology 本体库、处理表格数据的 Kumo 模型系列和 CUDA-X 数据处理库。问题在于：企业把智能体接上 Snowflake、邮箱或知识库后，模型仍难以理解跨系统的整体业务背景，面对多标签页的表格也容易找错数据。这次的做法是让数据留在原处、沿用企业已有的访问规则，用更好的检索和知识图谱补上下文——英伟达称其检索模型在 OpenSearch 测试中相关性提升 65%。对读者的意义是：企业多了一种不替换现有数据平台、自建智能体数据层的新选择，但相关组件刚发布，实际效果还需验证。英伟达表示只做模型、不与 Snowflake、Databricks 等数据平台竞争，权限控制仍交给合作伙伴；文中未说明各组件的具体可用时间和价格。
文中可用工具
- Agent Knowledge Foundation英伟达新推出的开源组件集合，帮企业智能体理解公司数据
- Agent Toolkit英伟达的智能体开发工具包，本次新增了上述组件
- Nemotron Retriever检索用的嵌入模型，让智能体搜得更准、少查几次
- Auto-Ontology从企业数据表自动构建知识图谱，把原始数据对应到客户、产品等业务概念
- Kumo面向表格等结构化数据的模型系列，用于预测分析
- CUDA-X英伟达的数据处理库
- OpenSearch开源搜索服务，文中用作测试检索效果的基准环境
- Model Context Protocol (MCP) server让智能体查询 Auto-Ontology 的接口方式
- Palantir Foundry英伟达内部供应链团队用来使用 Agent Knowledge Foundation 的平台
- Snowflake NotebooksSnowflake 客户可在此运行 Kumo 模型
- Genie OntologyDatabricks 的上下文层，与 Kumo 异常检测模型搭配使用
- Hugging Face英伟达发布开放权重模型的平台
工具与应用03
Spring AI 社区发布了一个模块化 RAG 示例，把 TypeSafe 的 Jev 模型接入检索增强生成流程。传统做法直接把用户问题和相似文档片段塞给模型，问题在于用户口语化提问会带入噪音、相似文档未必有用、检索内容可能被人恶意植入指令。新方案在检索前用两次大模型调用改写并扩展问题，检索后用 JevDocumentFilter 和 JevDocumentReranker 过滤、重排文档，再交给模型生成答案。整套流程通过一个 advisor builder 配置，配套有可运行的 05-1-modular-rag 示例模块，方便与朴素版本对比。需要 TypeSafe API Key，过滤和重排依赖 Jev 模型。
文中可用工具
- Spring AI构建 RAG 管道的 Java 框架
- TypeSafe提供类型化输入输出和 Jev 模型
- JevDocumentFilter过滤检索到的无用文档片段
- JevDocumentReranker对检索结果重新排序并保留前几条
- RetrievalAugmentationAdvisor模块化 RAG 的 advisor 入口
- RewriteQueryTransformer把口语化问题改写成适合检索的查询
- MultiQueryExpander把一个查询扩展成多个不同查询
- VectorStoreDocumentRetriever从向量库中做相似度检索
- ContextualQueryAugmenter把上下文和问题拼进提示词
- PagePdfDocumentReader读取 PDF 文档用于入库
- TokenTextSplitter把文档切分成小块
研究与技术04
文章作者做了一个实验：给 GitLab 公开文档做了一个聊天问答系统，拿一句包含五个不同问题的话去测试。主流做法是把复杂问题拆成五个小问题分别检索，再合并、重排、塞进有限的上下文窗口。结果五个正确答案虽然都被检索到了，但最终只有一条被保留，另外四条被排在前面的答案挤掉了；不拆分反而能保留三条。作者把这种现象叫“上下文饥饿”：某个子问题虽然找到了答案，却在最后分配上下文空间时被挤掉，而且常规召回率指标完全看不出来。文章指出，查询分解只解决了检索阶段的问题，分配阶段仍由“谁分高谁上”的不公平策略决定，需要引入公平性约束。目前这是作者在 GitLab 公开文档上做的实验，配套评测方法尚未说明是否开放使用。
文中可用工具
- LlamaIndex SubQuestionQueryEngine把复杂问题拆成多个子问题并分别检索、再汇总答案
- LangChain MultiQueryRetriever为同一个问题生成多种查询改写，合并去重后返回检索结果
- RAG-Fusion用倒数排名融合把多次查询的检索结果合并成一个列表
知识库与 RAG05
mahdidjemaci/production-rag · 🔍 Enhance retrieval accuracy with a production-ready RAG system that integrates semantic and lexical search for optimal results.
production-rag 是一个生产级检索增强生成（RAG）系统，将语义搜索与词法搜索结合以提升检索准确度。它提供多策略检索（可在不同搜索方法间切换）以及内置评估框架，用于评估不同策略的输出质量，面向真实应用场景。README 中说明系统要求为 Windows、macOS 或 Linux，最低 4 GB 内存（推荐 8 GB），至少 500 MB 存储空间。