Files

admin 94b2b2ed24 backup 2026-05-15-10-52-04

2026-05-15 10:52:39 +08:00

12 KiB

Raw Blame History

知识库 Agent 构建方案

本次执行开始时间：2026-05-15-10-48-07

参考原文：https://gist.githubusercontent.com/karpathy/442a6bf555914893e9891c11519de94f/raw/ac46de1ad27f92b28ac95459c782c07f6b8c964a/llm-wiki.md

本地归档：文档知识库构建流/llm-wiki.md

一、核心思想

Karpathy 的 LLM Wiki 方案不是传统的一次性 RAG：不是每次提问时临时从原始文档里找片段、再重新拼答案，而是让 LLM 持续维护一个持久化的 Markdown Wiki。每加入一份材料，Agent 都要阅读、抽取、归类、交叉引用，并把新信息写入已有知识结构。

对当前材料汇总任务来说，最佳形态是：

个人事迹材料文档_MD、其他事迹材料文档_MD：作为既有写作风格、表达结构、过往申报口径的基础语料。
个人事迹支撑材料汇总：作为完整素材库和证据库，里面的图片、截图、链接、证书、项目材料是事实依据。
待完善内容：作为草稿处理区，只用于待补充材料的阅读、写作和迭代，不作为需要推送到 Gitea 的正式库内容。
文档知识库构建流：用于存放知识库构建方法、原始参考文档，以及后续可扩展的 Wiki、索引、日志、证据卡片等。

目标不是只“搜索材料”，而是逐步形成一个可复用的个人事迹知识库：每个成果、奖项、项目、论文、任职、荣誉都有稳定页面、证据路径、可引用表述和与其他材料的关系。

二、推荐目录结构

建议后续在 文档知识库构建流 下逐步形成如下结构：

文档知识库构建流/
  llm-wiki.md                         # Karpathy 原始方法文档
  wiki/
    index.md                          # 知识库总索引
    log.md                            # 处理日志，按时间追加
    人物画像.md                       # 个人总体画像、主线叙事、关键词
    事实清单.md                       # 可复用事实与证据索引
    写作口径.md                       # 常用表述、风格、注意事项
    材料任务/
      ...                             # 针对待完善内容的任务页
    成果/
      ...                             # 论文、专利、项目、转化、典型案例
    荣誉竞赛/
      ...                             # 奖项、荣誉、竞赛
    任职与社会服务/
      ...                             # 学校任职、学术协会、代表身份
    来源卡片/
      ...                             # 每个文本/图片/视频来源的摘要卡

原始材料不搬动、不改写，Wiki 只保存 Agent 生成的结构化摘要、索引和交叉引用。原始文件仍以现有目录为准。

三、三层架构

第一层是原始来源层。包括 PDF 转换出的 Markdown、支撑材料库中的图片、截图、链接文本、HEIC、视频等。这一层是事实源，不应由 Agent 随意修改。

第二层是 Wiki 层。它由 Agent 维护，包含主题页、人物页、成果页、证据卡、写作口径、任务页、对照表。每次新增材料或产生重要分析，都应沉淀到 Wiki。

第三层是 Schema/工作规范层。也就是这份 知识库Agent构建.md 以及后续可能新增的 AGENTS.md、index.md、log.md。它规定 Agent 如何入库、如何回答问题、如何撰写材料、如何引用证据。

四、文本材料入库方式

文本材料包括：

个人事迹材料文档_MD/**/*.md
其他事迹材料文档_MD/**/*.md
个人事迹支撑材料汇总/**/*.txt
PDF 转换后得到的 Markdown、JSON 辅助信息
后续 待完善内容 中的待补充文本

每份文本入库时应提取：

来源路径：必须保留相对路径，方便追溯。
材料类型：事迹材料、申请表、通讯稿、征文、链接说明、获奖证明说明等。
时间信息：年份、月份、事件发生时间、获奖/发表/授权/立项时间。
主体身份：第一负责人、一作、共同一作、参与、主持、理事、委员、代表等。
关键事实：奖项等级、项目名称、论文题目、专利号、组织单位、金额、平台名称。
可复用表述：适合写进申报材料的凝练句子。
风格信号：政治性、学术性、创新创业、社会贡献、组织服务等叙事倾向。
证据关系：哪些图片、链接、证书可以支撑这条事实。

入库产物建议为“来源卡片”：

---
type: source
source_path: 个人事迹材料文档_MD/...
source_kind: past_material
year: 2026
tags: [党员, 荣誉, 事迹材料]
confidence: high
---

# 来源标题

## 摘要

## 可抽取事实

## 可复用表述

## 相关证据

## 关联页面

五、图片与多模态材料入库方式

个人事迹支撑材料汇总 中大量材料是图片、截图、证书、网页截图、设备照片和视频。多模态知识库的关键不是只记录文件名，而是把图片中可见的信息结构化成可检索、可引用、可校验的证据。

图片入库步骤：

先从文件路径和文件名抽取初始信息，例如年份、奖项名、项目名、身份、级别。
使用视觉读取图片内容，识别证书/截图上的标题、落款、单位、时间、奖项等级、姓名、项目名。
将“文件名信息”和“图中可见信息”分开记录，避免把推断当成证据。
给每张图片生成证据卡，标注可信度和可引用范围。
把证据卡链接到对应主题页，例如“国家奖学金”“数据要素典型案例”“专利转化”“ACS 会议论文”。

图片证据卡建议格式：

---
type: evidence_image
source_path: 个人事迹支撑材料汇总/竞赛获奖/...
media_type: image
year: 2024
tags: [竞赛获奖, 省赛一等奖, 项目]
confidence: medium
---

# 图片证据：标题

## 文件名提供的信息

## 图中可见信息

## 可支撑事实

## 不能直接证明的内容

## 关联主题页

对 HEIC、视频等材料：

HEIC：如当前工具无法直接读取，应优先转换为 PNG/JPG 副本后再视觉入库，原文件保持不动。
视频：不建议整段作为文本证据直接使用。应抽取关键帧，记录视频文件路径、时长、关键帧时间点、画面内容、可支撑事实。
项目设备照片：重点记录设备代际、使用场景、临床/动物实验/汇报场景，而不是过度推断技术性能。

多模态调用时的原则：

先读 Wiki 中的证据卡，再打开原图复核关键事实。
写正式材料时，只有“图中明确可见”或“文件名与上下文共同支持”的事实才可作为强证据。
对仅从文件名推断的信息，要写成“待核验”或“弱证据”，避免误写。

六、索引与日志

index.md 是内容索引，应按主题组织：

个人主线与总体画像
过往事迹材料
荣誉表彰
竞赛获奖
论文会议
专利软著
项目与科技查新
创新创业与成果转化
任职与社会服务
媒体报道与典型案例
待完善材料任务

每个条目建议包含：页面链接、一句话摘要、年份、证据数量、可信度。

log.md 是时间日志，应追加记录，不覆盖历史。建议格式：

## [2026-05-15-10-48-07] ingest | llm-wiki 方法文档

- 动作：下载并阅读 Karpathy 的 LLM Wiki 方法文档。
- 产物：知识库Agent构建.md
- 备注：建立文本+图片知识库构建规范。

后续每次执行前都记录开始时间，格式保持 {Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}，便于追踪每轮处理做了什么。

七、Agent 调用方法

1. 入库调用

适用场景：新增支撑材料、转换了新 PDF、补充了链接或证书。

流程：

记录开始时间。
用 git status --short --ignored 检查新增内容和被忽略内容。
用 find 或 rg --files 定位新增材料。
文本材料直接阅读；图片材料打开视觉检查；视频材料必要时抽关键帧。
为每个来源生成或更新来源卡片。
更新相关主题页、index.md、log.md。
标注冲突、待核验、证据强弱。

2. 查询调用

适用场景：询问“某个奖项能怎么写”“某段经历有哪些证据”“这份申报表应突出什么”。

流程：

先读 wiki/index.md，确定相关主题页。
用 rg 搜索年份、项目名、奖项名、关键词。
阅读主题页和来源卡片。
必要时打开原图或原始 Markdown 复核。
输出答案时附相对路径引用，区分“已证实事实”和“建议表达”。
如果答案形成了新分析，应沉淀到 Wiki 的任务页或主题页。

3. 撰写待完善内容

适用场景：补写 待完善内容 中的申请表、事迹材料、通讯稿、汇总表。

流程：

读取待完善文件，识别栏目、字数、语气、约束。
读取过往 MD 材料，提取可沿用结构和表达口径。
从支撑材料 Wiki 中拉取事实清单与证据。
先生成“事实-证据-可写角度”对照表。
再写正文，避免把证据不足的内容写成确定事实。
完稿后做一致性检查：年份、角色、奖项等级、项目名称、单位名称是否一致。
待完善内容 是处理空间，不作为需要推送到 Gitea 的正式内容。

4. 健康检查调用

建议周期性运行：

查找同一奖项/项目在不同页面中的年份或等级冲突。
查找只有结论没有证据路径的事实。
查找证据图片未入卡、主题页未链接的孤立材料。
查找过往材料中已经陈旧的表述。
查找可合并的重复主题。
查找适合补充外部网页链接的事实缺口。

八、面向当前材料库的主题页设计

建议优先建立这些主题页：

人物画像.md：总体身份、主线叙事、关键词、材料写作定位。
学术科研成果.md：论文、会议、科技查新、研究方向。
创新创业与成果转化.md：公司、专利转化、典型案例、项目落地。
竞赛获奖.md：按年份、级别、负责人身份组织。
荣誉表彰.md：国家奖学金、优秀研究生、专项奖学金等。
专利软著.md：专利号、授权状态、作者顺位、软件著作权。
社会服务与任职.md：学术协会、校内任职、代表身份。
媒体报道与社会影响.md：官媒报道、典型案例、链接证据。
写作素材库.md：可复用句式、段落、标题、过渡语。
事实清单.md：所有高可信事实的总表。

九、证据强度分级

建议每条事实都标注证据强度：

high：证书/公示/正式表格/网页截图中明确可见，且与文件名一致。
medium：文件名、上下文、截图部分信息共同支持，但图片中关键信息不完整。
low：仅来自文件名或过往材料表述，尚未找到直接证据。
needs_check：存在冲突、截图不清、年份不确定、角色不确定。

正式撰写时优先使用 high 和 medium，low 只作为提示，不直接写成确定事实。

十、提交与同步约束

个人事迹材料文档_MD、其他事迹材料文档_MD、个人事迹支撑材料汇总 可以作为知识库来源。
文档知识库构建流 和 知识库Agent构建.md 可以作为知识库方法和结构产物。
待完善内容 是处理空间，后续不应推送到 Gitea。
每次提交前必须检查 git status --short --ignored，确认是否误包含 待完善内容。
已从机制上防止误推：本仓库 .gitignore 已加入：

待完善内容/

十一、每次运行后的 Gitea 备份规则

后续每次执行材料处理、知识库更新、草稿撰写或素材整理后，都要在收尾阶段执行 Gitea 备份。

固定流程：

记录本次执行开始时间，格式为 {Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}。
执行任务并完成必要核验。
提交前运行 git status --short --ignored，确认 待完善内容/ 只作为被忽略处理空间，不进入提交。
将需要备份的正式材料、知识库产物、构建规范加入 Git。
使用包含时间的提交信息，例如：

git commit -m "backup 2026-05-15-10-52-04"

推送到 Gitea：

git push

12 KiB Raw Blame History Unescape Escape