知识库设计.md 7.0 KB

需求介绍

这段内容是给你看的,有助于你更清晰的了解开发目的,不用把我说的话都写到程序中:

  • 知识库是用户上传的有参考价值的历史资料,我们要对知识库进行整理分析,以便之后生成标书技术方案的时候,可以参考之前的资料。

知识库功能

  • 页面应该是类似文件夹的样子,用户可以创建文件夹,并在文件夹内上传.doc.docx.wps.pdf.md文档。
  • 将用户上传的任何文档都整理成markdown格式保存,这个要落到文件,以免之后丢失。
  • 调用AI将文档内容整理成json格式,包括标题、简述和原文。

    [{
    "id":"",
    "title":"",
    "resume":"",
    "content":""
    }]
    - 解析最好能有真实的进度条
    

知识库用法(这个先不用实现,只是便于你理解)

  • 在生成目录阶段,传入[{"title":""}]给AI参考
  • 生成正文的编排阶段,把[{ "id":"", "title":"", "resume":"" }]传给AI,让AI在编排阶段,确定每个子节点是否能应用到知识库中的内容,如果能用到,记录ID
  • 在生成正文的时候,通过ID找到资料的正文,然后以参考资料的形式提供给生成正文的AI

优化1

上传资料时,用AI分析成知识条目库,这是现在的方案。但是分析的条目不准确,且丢失了很多内容。 我希望在分析阶段做以下处理:

  1. 先让AI提取出有意义的知识条目(舍弃掉封面、目录等对写标书无意义的条目)。
  2. 给正文按自然段编号,提交给AI
  3. 让AI输出每个条目对应的段落编号
  4. 程序根据AI输出结果,处理知识条目

目前我能想到的困难点有两个:

  1. 第三步,AI分析条目对应段落编号时可能会漏掉部分段落,即有部分段落不属于任何条目,如何能做到让AI尽可能分析出所有段落所对应的条目
  2. 如果AI能分析出所有段落对应的条目,那输出的内容会不会太多,超过AI输出上限?如何让AI分步执行以保证分析全面

结合你的方案我设计的流程如下:

  1. 用程序筛掉封面、目录、页码、空行、页眉页脚、签章页等,直接筛掉,无需标记,不提交给AI就行了
  2. 筛后的文档按自然段/表格/列表块编号 例如:P000001P000002P000003

  3. 提交给AI,先让AI输出知识条目数组,仅包含ID、标题和摘要

  4. 在页面中展示出AI返回的知识条目,总共多少条,用户录入一批分析多少条(因为我们现在不知道AI的能力上限,一次性提取所有段落,可能会有大量丢失,一次提取的太少又会有资源浪费,所以这是开发调试阶段的一个临时页面,让我们更好的测试出AI的能力)

  5. 按照用户输入的条数,将知识条目分批,循环询问AI,投入分好段的全文、提取的部分id、标题、摘要json数组。然AI给这些数组匹配段落,仅返回id+段落号就行

  6. 所有批次都执行完后,进行一次检查,判断是否有遗漏的段落,如果有,将完整知识条目id、标题、摘要和遗漏段落提交给AI,让AI再匹配一次,这次让AI返回匹配好的id+段落,再额外返回一个推荐舍弃段落和一个新增知识条目,即让AI分析这些遗漏短时是否有必要保留,被遗漏是否是因为没有合适的知识条目,如果是就新增条目,如果段落质量低没必要保留,就放到舍弃段落。这样所有遗漏段落就都有明确的标识了。

  7. 把第五步和第六步的结果合并,看是否还有遗漏段落,如果还有再重复执行一次第六步。最多重复执行一次,再有遗漏就直接标记为舍弃。

  8. 把前面执行返回的所有结果拼接成完整json

  9. 用程序根据json进行正文提取,形成最终结果


定版流程

方案可以成立,我按你的取舍调整后,建议定版为下面这个流程。

定版流程

  1. 程序预处理
    直接筛掉封面、目录、页码、空行、页眉页脚、签章页等明显无价值内容。
    同时保存 filtered_blocks.json,只用于调试,不进入 AI 分析。

  2. 生成 block
    对筛选后的正文生成 block 编号,例如 P000001
    block 类型包括 paragraphtablelist 等。

  3. 第一次 AI 抽取知识条目
    输入编号后的全文 block。
    AI 只返回候选知识条目:标题、摘要,不返回正文,不返回 ID。
    程序生成 ID,例如 K000001

  4. 第二次 AI 补充知识条目
    输入全文 block + 第一次抽取出的条目标题摘要。
    让 AI 判断是否有遗漏主题,并返回补充条目。
    程序合并两次抽取结果,再统一编号。

  5. 页面展示调试入口
    展示:总 block 数、候选知识条目数、用户输入“每批分析多少条”。
    这是开发调试阶段非常有必要的,可以用来摸模型能力上限。

  6. 分批匹配段落
    每批提交:全文 block + 当前批次知识条目。
    AI 只做强相关匹配,不要求覆盖全部 block。
    AI 返回 id + ranges

  7. 检查遗漏 block
    程序合并所有批次结果后,找出没有被任何知识条目引用的 block。

  8. AI 兜底补漏
    输入:完整知识条目列表 + 遗漏 block。
    AI 必须把遗漏 block 分成三类:匹配已有条目、新增知识条目、推荐舍弃段落。

  9. 最多补漏两轮
    第一次补漏后再检查遗漏。
    如果仍有遗漏,再重复一次补漏。
    第二次后仍遗漏的 block 放入 system_discarded_after_retry

  10. 程序生成最终结果
    程序合并所有 AI 返回结果,根据 block 编号回填正文,生成最终知识条目库。

AI 返回格式建议 分批匹配返回:

{
  "matches": [
    {
      "id": "K000001",
      "ranges": [["P000012", "P000018"], ["P000026", "P000030"]]
    }
  ]
}

补漏返回:

{
  "matches": [
    {
      "id": "K000001",
      "ranges": [["P000080", "P000083"]]
    }
  ],
  "new_items": [
    {
      "title": "项目风险应对措施",
      "summary": "描述风险识别、响应机制和应急处理流程",
      "ranges": [["P000090", "P000095"]]
    }
  ],
  "discarded": [
    {
      "ranges": [["P000100", "P000102"]],
      "reason": "内容为低价值格式文本"
    }
  ]
}

我建议额外保留的处理报告

  • total_blocks
  • filtered_blocks_count
  • candidate_items_count
  • matched_blocks_count
  • discarded_blocks_count
  • system_discarded_after_retry_count
  • new_items_from_recovery_count
  • coverage_rate

需要注意的一点 第 5 步“全文 block + 当前批次知识条目”会反复提交全文,成本和上下文压力较大,但开发调试阶段可以接受。等效果验证后,再优化成“全文摘要索引 + 相关 block 候选”也不迟。

我的结论 这个方案可以作为下一版知识库分析流程实施。关键点是:AI 只负责抽条目和匹配编号,程序负责编号、合并、补漏、回填、报告,避免正文丢失。