LumaBrowser 如何让 AI 基于本地文档知识库生成带来源的回答？

LumaBrowser 的本地知识库把 PDF、Markdown、HTML 和纯文本加入指定 AI Agent，在本机完成解析、分块、索引和检索。提问时，Agent 先搜索自己的文档，再基于命中的段落回答，并附文件名及页码等来源信息。它采用 BM25 全文排序和本地 SQLite 索引，不需要云端向量数据库或额外的嵌入模型。

先理解一次回答经过哪些步骤

1. 用户把文件加入某个 Agent 的知识库。
2. 应用提取文本，并把内容切分为带重叠的短段落。
3. 段落写入本机全文检索索引。
4. 提问时，Agent 调用知识库搜索工具查找相关段落。
5. 模型使用检索结果生成回答，并返回来源映射。
6. 聊天界面把来源显示为可点击引用，供用户回到原文复核。

这里的关键不是让模型“记住”整个文件夹，而是每次回答前找出少量相关证据。索引与生成模型承担不同职责：BM25 负责匹配文本，模型负责综合和表达。

第一步：为知识领域创建专用 Agent

在 Agents 页面创建一个用途清晰的 Agent，例如产品规范助手、内部政策助手或代码库指南。提示词应说明回答范围、冲突处理方式和证据要求，例如：只根据知识库回答；找不到依据时明确说无法确认；多个文档冲突时列出差异。

不要把人事制度、工程手册和客户合同全部放进同一个 Agent。LumaBrowser 的知识库按 Agent 隔离，一个 Agent 默认看不到另一个 Agent 的文档。按权限、读者和任务边界拆分，可以降低错误检索和越权引用的风险。

第二步：准备可检索的文档

当前支持的主要格式包括 PDF、Markdown、HTML 和纯文本。导入前建议：

• 删除重复导出件和失效草稿，保留明确版本。
• 使用能表达内容的文件名，包含主题与版本日期。
• 让标题、章节和关键术语出现在正文中。
• 检查扫描 PDF 是否真正包含可提取文字。
• 将极大且混杂的文件按稳定章节拆分。

PDF 按页提取，因此引用可以指向具体页码；HTML 会先转换为干净的 Markdown。系统把文本切成约 500 token 的重叠段落，以降低答案跨分块边界时丢失上下文的概率。

第三步：添加文件并验证索引

打开目标 Agent，选择添加文档，再通过系统文件选择器选取文件。应用在本机解析和建立索引。相同内容再次加入时会根据内容哈希去重，避免同一证据重复提高排名。

导入完成后不要立即询问复杂总结，先做三类检查：

1. 定位题：询问一个只出现在单一文件中的术语。
2. 精确题：询问带数字、日期或限定条件的规则。
3. 否定题：询问文档完全没有描述的事项。

前两类应返回正确来源，否定题应承认缺少依据。若否定题仍生成确定答案，应收紧 Agent 提示词，而不是把流畅回答当作检索成功。

BM25 全文检索适合什么内容

BM25 根据查询词在文档和语料中的出现情况排序，确定性强、资源占用低，适合政策名称、产品术语、错误码、函数名、合同条款和其他有稳定词汇的资料。它不需要下载嵌入模型，也不占用 GPU 进行向量化。

它的限制同样明确：当提问与原文使用完全不同的表达，纯词法匹配可能漏掉语义相关段落。遇到这种情况，可以在查询中加入文档可能使用的术语，或在资料中补充术语表和别名。不要假设“本地 RAG”必然等同于向量检索。

怎样提出更容易得到证据的请求

问题应包含对象、时间范围和期望输出。例如，与其问“退款怎么办”，不如问“年度套餐首次扣款后多少天内可以全额退款，请列出条件和来源”。对于跨文档任务，可以要求：

• 分别列出每份文件的规定，不要提前合并。
• 标出相互冲突或版本不一致的段落。
• 每个结论后附对应文件与页码。
• 区分原文事实、计算结果和推断。

清晰的请求既改善检索关键词，也限制模型在证据之外发挥。

如何验证带来源回答

“附引用”并不自动保证结论正确。点击引用后至少检查四点：

1. 引用段落是否真的支持前面的具体结论。
2. 模型是否忽略了例外、适用范围或否定词。
3. 数字、日期和单位是否被准确转述。
4. 是否存在更新版本覆盖当前来源。

高风险的法律、人事、财务或安全决定仍需要责任人复核。知识库能缩短查找证据的时间，不能取代审批和专业判断。

本地处理的隐私边界

官方说明中，文档解析、索引和检索均在设备上完成，文件不会上传到云端索引或嵌入服务，索引存储在应用数据目录的本地 SQLite 数据库中。这保护的是知识库处理链路。

生成回答所用模型仍需单独判断：若 Agent 连接云端模型，被检索出的段落可能作为上下文发送给该模型；若要求完整离线，应同时选择本地模型并检查网络配置。还应保护本机账户、磁盘备份和应用数据目录，因为本地索引本身也可能包含敏感文本。

通过 REST 接口批量管理文档

界面操作对应普通 REST 请求。开发者可以列出某个 Agent 的知识库、提交本机绝对路径进行导入，以及按文档 ID 删除条目。典型流程是：

{
  "paths": [
    "/absolute/path/policy.pdf",
    "/absolute/path/runbook.md"
  ]
}

管理接口位于 Agent Manager 扩展 API 下，分别支持列出、导入和删除。自动化脚本应在导入前验证路径，在导入后检查文件名、页数和文档 ID，并记录来源版本。绝对路径只指向本机文件，不应把它误解为文件内容已经上传到远端。

Agent 实际使用的检索工具

当 Agent 至少拥有一个文档时，系统才为它提供知识库搜索工具。工具接收查询字符串，返回排名靠前的段落，每段附来源文件、页码和供界面渲染的引用映射。没有文档时不暴露该工具，可以减少无效工具调用。

调试回答时，可以把问题拆成“检索是否找对”和“模型是否总结正确”两部分。若结果没有相关段落，调整查询或文档结构；若段落正确但结论错误，调整提示词并加强引用复核。

建立可维护的知识库更新流程

环节	建议检查
导入前	版本、权限、可提取文字、重复文件
导入后	文档清单、页数、定位题、否定题
日常使用	引用支持度、例外条件、来源新旧
资料更新	移除旧版本、加入新版本、回归问题
权限变更	Agent 边界、本机访问、备份副本

为每个知识库维护一组固定回归问题，文档更新后重新询问并比较来源，可以及时发现解析失败、术语变化或旧文档残留。

适合与不适合的使用场景

它适合内部运行手册、产品规范、研究笔记、合同查询和个人资料整理，尤其适合要求本机索引、低资源消耗和逐页引用的场景。若任务依赖大量图片、扫描件、复杂表格或跨语言语义匹配，应先验证文本提取与召回质量。

完整闭环应是：按职责创建 Agent，整理并导入文档，用定位题验证索引，提出带范围的问题，点击来源复核，再通过回归问题维护更新。只有把检索命中和引用核查都纳入流程，本地知识库才能从“会聊天的文件夹”变成可靠的证据入口。