技术研究：超长视频内容沉淀为知识库的方法（一）

背景

大型模型的 AI 知识能力现今基本可以被认为“溢出”了，他的编码能力，知识都很强，但是上下文限制或者无法和用户偏好对其导致效果无法如人意，因此留给我们这种普通研发者的重要工作就是教会 AI 做事儿。

给 AI 当老师是一个非常困难的事情，难度不亚于你去教一个通用知识能力远超自己的学生，但是受限于他没有完善的记忆系统，周边生态配套缺乏。在做这件事儿的过程中，我们的认知也发生了很大变化。

需求诞生

我们只做了一套任务执行系统，并且认为只要告诉 AI 方法论与骨架，AI 就可以按照我们的构想去构建任务，并且执行任务，交付结果：

实际我们确实这么做了，马上遇到了第一个问题，任务越来越复杂，需要的背景知识越来越多？如何稳定，并且分阶段提供给AI对应的知识呢？这些知识可能来自 GB 编号的文件，可能来自一个五小时的教学视频，也可能来自于某一个公司的内部文件，不至于我们每一次都需要构建对应的方法论吧？

知识系统

因为上面的核心需求，我们需要实现一个知识系统，帮助 AI 在规划任何任务的时候，都有所依据。这就回到了我们一开始的诉求：“我们有大量的专业系统的知识，这些知识是我们做事儿的指引，如何让这些知识在 AI 没有系统训练的情况下，也成为 AI 做事儿的指引？”

知己知彼

如何将离散的、碎片化的信息和经验，系统性地构建成一个可计算、可推理、可演化的知识体系。这一过程的起点，也是其最重要的第一性原理，便是对“知识”本身进行建模。若要实现真正的“知己知彼”，我们首先必须回答一个根本问题：知识从何而来，其本质又是什么？

知识源与密度

任何知识系统的构建都始于其源头。从工程角度看，我们可以将知识的原始载体按其信息密度和结构化程度，初步划分为两类：一是高密度知识载体，如技术文档、研究论文、书籍等，其特点是信息密度高、语言凝练，但往往呈现为半结构化或非结构化文本；二是低密度知识载体，如教学视频、操作录屏、语音交流等，其特点是信息冗余度高，包含大量非核心内容，知识点散布于时序媒体流之中。

在市面上见到的大部分 RAG 系统或者知识库系统中，大家倾向于只处理高密度知识载体，高密度知识载体太多了，处理起来很方便，我们就不在赘述了，在补充完知识后我们倾向于给大家主动讲解一下我们在低密度知识载体的处理上的一些工作。

知识建模的“通用语言”: 实体-属性-关系模型

为了应对上述挑战，我们需要一种具备普适性的建模语言。语义网（Semantic Web）理论中的“语义三元组”（Subject-Predicate-Object）为此提供了强大的理论基础。在长期的工程实践中，这一思想演化出了一个更具可操作性且本质等价的模型：实体-属性-关系（Entity-Attribute-Relation）。

我们在此重申一个核心论断：“实体-属性-关系”这一模型组合，提供了一个足够灵活且完备的框架，足以将几乎所有领域的信息进行逻辑化和结构化。

它构成了我们从看似混乱的原始信息中，提炼出知识核心单元的基本准则。我们定义：

• 实体（Entity）：代表一个独立存在且可被明确识别的事物、对象或概念。例如，“Yakit”、“SQLMap”、“SQL注入漏洞”都是实体。
• 属性（Attribute）：描述一个实体内在的、固有的特性或状态。例如，“Yakit”的属性可以是“版本号：1.0”、“开发者：Yaklang Team”。
• 关系（Relation）：定义不同实体之间存在的、具有明确语义的联系。例如，“Yakit”与“SQLMap”之间存在“协同工作”的关系；“SQLMap”与“SQL注入漏洞”之间存在“检测”的关系。

实体建模（Entity Modeling）定义为一个系统性的方法论过程，其核心目标是将源自高/低密度信息载体中的非结构化或半结构化知识，通过识别核心实体（Entity）、解析其内在属性（Attribute）、并厘清实体间的交互关系（Relation），最终将其转化为一个形式化的、机器可读且可计算的知识网络结构。

实体建模实践论证：日志的实体建模

我们建立了“实体-属性-关系”这一知识建模的通用语言，并将其形式化地定义为“实体建模”。理论的健壮性最终需要由实践来检验。我们的定义必须能跨越不同的领域壁垒，对各种各样的信息进行统一有效的结构化处理：

我们在本节将会讲解对不同的领域下，我们的模型具有一定的普适性。

当前业界主流的 RAG 等知识库系统，其处理对象大多局限于技术文档这类高密度知识载体，因其处理相对直接且资源丰富。然而，知识的版图远不止于此。我们认为，对视频、录屏、语音等低密度知识载体的有效萃取与建模，是构建下一代知识系统的关键挑战。在后续内容中，我们将深入探讨在这一前沿领域的工作。当前，我们首先通过对多种文本形态的建模来夯实基础。

案例一：服务器日志实体化

日志是信息系统中最常见数据源之一，大部分是半结构化的文本形式，忠实记录了系统的每一次交互、事件与异常。然而，原始的日志行对于机器而言是孤立的、难以理解的字符串。实体建模的目标，就是将其转化为一个蕴含丰富上下文关系的知识网络。

我们以一行标准的 Nginx 访问日志为例：

127.0.0.1 - - [10/Oct/2023:13:55:36 +0000] "GET /api/v1/user?id=123 HTTP/1.1" 200 512 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36"

这行文本对于人类管理员来说一目了然，但对于机器来说，它仅仅是一个长字符串。

我们遵循“实体-属性-关系”的框架进行拆解：

1、识别核心实体 (Entity)：

2、解析实体属性 (Attribute)：3、厘清实体关系 (Relation)：

案例二：代码实体建模

代码不仅是文本，它是一种形式化语言，内含了严谨的逻辑、数据流和层级结构。传统的代码分析依赖于抽象语法树（AST）等编译器技术，这些技术侧重于语法解析。而实体建模则提供了一个更高维度的视角，旨在捕捉代码的语义和组件间交互关系，从而构建一个可用于深度分析的“代码知识图谱”。

我们以一个简单的 Python 类为例，该类用于从一个 API 获取用户信息：

import requests # 引入外部依赖
class UserAPIClient:
    def __init__(self, base_url="https://api.example.com"):
        self.api_endpoint = base_url
    # 根据用户ID获取数据
    def get_user_data(self, user_id):
        # 构造请求URL
        full_url = f"{self.api_endpoint}/v1/users/{user_id}"

        # 发起HTTP GET请求
        try:
            response = requests.get(full_url, timeout=5)
            response.raise_for_status() # 如果状态码不是200-299，则抛出异常
            return response.json()
        except requests.exceptions.RequestException as e:
            print(f"请求失败: {e}")
            return None

这段代码虽短，但五脏俱全，包含了类、方法、参数、变量、外部调用和数据流等多种核心要素。我们将再次运用 “实体-属性-关系” 框架，将代码的内在逻辑结构化。

1、识别核心实体 (Entity)：2、解析实体属性 (Attribute)：3、厘清实体关系 (Relation)：

案例三：指导性法律条文的实体化解析

在前两个案例中，我们处理了由机器（日志）和人类（代码）为机器执行而创建的文本。现在，我们将模型应用到一个截然不同的领域：由人类为规范人类（或组织）行为而创建的指导性法律条文，例如国家标准（国标）。这类文本具备高度的范式化结构和极强的逻辑性，但其语义往往蕴含在规定、要求、禁止等指令性语言中。实体建模的目标，正是要将这些合规性要求，从静态的文本条款，转化为可动态查询和自动判定的知识单元。

原始数据：以《网络安全等级保护基本要求》（GB/T 22239-2019）为例

条款原文 (Level 3 Requirement):
8.1.3.3 身份鉴别 a) 应在登录时采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术。

这段文本简洁地规定了一个具体的安全控制措施，包含了责任主体（隐含）、操作对象、行为、技术手段和约束条件。

应用“实体-属性-关系”框架，我们可以将这项合规要求进行精确的解构。

1、识别核心实体 (Entity)：2、解析实体属性 (Attribute)：3、厘清实体关系 (Relation)：

特殊：从高冗余视频中萃取知识

在现实世界中，大量的知识以视频、录屏、语音等低密度、高冗余的形式存在。这些载体看似信息量巨大，但其核心知识点往往稀疏地散布于大量的时序性、重复性或非关键性数据之中，对传统的知识提取技术构成了严峻挑战。

本文重点我们会讲解，其核心目标不再是生成浅层的文本摘要，而是从视频流中进行深度的、结构化的知识提取。我们将详细论证，为何传统的固定频率采样（如每秒一帧）方案在此场景下是低效且不可取的，并提出我们基于“动态采样”理念的优化框架。

动态采样的核心思想：F.A.S.T. 框架

传统视频处理方案，如固定帧率采样，其根本缺陷在于它对视频内容的一视同仁。它无法区分讲解核心概念的30秒与沉默或重复操作的5分钟之间在知识价值上的巨大差异，导致最终采集成百上千的冗余或无意义的图像帧。为了解决这一问题，我们提出了一套创新的处理框架：聚焦式音频语义触发采样（Focused Audio-Semantic Triggered Sampling, F.A.S.T.）。

F.A.S.T. 框架的基本原理是：利用视频中信息密度相对更高的音频通道，来智能引导对信息密度较低的视觉通道的采样过程。

音频，尤其是包含人类语音的音轨，其转录文本是高度结构化且易于进行语义分析的。我们可以通过分析语音内容，反向定位视频中的“知识高光时刻”，从而实现对采样资源的精确投放。

该框架主要包含以下几个核心阶段：

1、音频转录与语义标注：

• 首先，使用高精度的自动语音识别（ASR）引擎，如 OpenAI 的 Whisper，将视频的完整音轨转化为带有精确时间戳的文本（如 SRT 格式字幕文件）。

• 接下来，对转录后的文本进行自然语言处理（NLP）。此步并非简单地分词，而是要进行更深度的语义分析，识别出关键词、关键短语、操作指令（如“点击按钮”、“输入密码”）、概念定义、以及话题的切换点。这些被识别出的部分将被标记为“语义热点”。

2、动态采样区间生成：

• 根据语义热点的时间戳，系统生成一个非均匀的采样计划。对于被标记为“语义热点”的时间段（例如，讲解一个关键功能的 30 秒），系统会大幅提高采样频率（如每秒 5-10 帧），以捕捉精细的操作过程和界面变化。

• 对于语音稀疏、内容重复或无关紧要的长时间片段（例如，等待程序加载、无声的鼠标移动），系统则会显著降低采样频率，甚至完全跳过，从而避免了海量低价值图像的产生。

3、图像帧的实体化建模：

• 对于通过动态采样捕获到的每一帧图像，我们复用前文所述的“实体-属性-关系”建模方法。通过先进的视觉模型（Vision Language Models, VLM），对图像进行深度解析，识别出其中的实体。例如，在教学视频的截图中，实体可能包括：界面窗口(UI-Window_1)、按钮(Button_Login)、输入框(Input_Username)、代码片段(CodeSnippet_01)、以及通过 OCR 识别出的文本(Text_"Login")。

4、跨模态知识融合与归纳（Reduction）：

• 这是 F.A.S.T. 框架的最后一步，也是最关键的一步。系统会将来自同一时间戳的音频语义实体和视觉实体进行关联融合。例如，当音频中出现“点击登录按钮”这一实体时，系统会将其与视觉模型在对应帧中识别出的按钮( Button_Login )实体建立 Action_Click 关系。
• 一个统一的归纳器（Reducer）负责处理连续帧的建模结果。它会合并连续多帧中稳定出现的相同实体（例如，一个窗口在 10 帧内未变，则合并为一个实体并标注其持续时间），并根据实体的变化构建时序关系（例如，Input_Username 实体在下一帧中其 value 属性发生了改变，则建立一个 DataInput 事件）。

F.A.S.T. 框架通过一种“以文导图”的创新模式，根本性地解决了低密度视频知识提取的效率和精度难题。它将原本需要处理海量冗余图像的“蛮力”方法，转变为一种由语义驱动的、外科手术式的精确打击。通过该框架，我们能够从教学视频、操作录屏等载体中，构建出包含操作序列、因果关系和状态变迁的、高度结构化的实体仓库和 RAG 存储系统，其知识密度和可用性远非传统视频摘要技术可比。

效果演示：从理论到可观测的实践剪影

上述框架并非停留在理论设想，而是已经过我们大量、深入的工程实践验证。我们深知，衡量一项技术成熟度的唯一标准是其在真实场景下的表现。为此，我们对海量的视频数据，尤其是知识密度变化剧烈的教学类、操作演示类视频，进行了严苛的测试。我们成功地实现了让系统自动“生吞”数小时的超长视频，并从中精确地提取、标注和结构化其蕴含的核心知识。

下图所展示的，正是我们内部系统在处理一段教学视频时，实时生成的执行日志与分析界面。这并非模拟数据，而是系统工作的真实剪影。

这份看似简单的日志，实际上蕴含了 F.A.S.T. 框架的核心价值：

• 证据一：可验证的动态采样。 日志中明确的 start_seconds 和 end_seconds 时间戳，正是音频语义分析后反哺给采样器的执行指令。我们可以看到系统并非线性扫描，而是聚焦于5.75-9.50秒、9.50-19.18秒等被判定为“知识高光”的区间。
• 证据二：深度的视觉实体理解。CumulativeSummary 字段显示，系统不仅“看到”了图像，更“理解”了其内容——The image displays a presentation slide or educational...within a business or data analysis context。这证明了视觉实体建模正在有效工作，它识别出了“演示文稿”、“数据分析上下文”这类高级抽象实体。
• **证据三：多模态知识的融合。**日志中“我们来看看...”这类口语化的文本，源自 Whisper 的音频转录，它成为了触发精细采样的引信。这直观地展示了音频流与视频流的协同工作。

这项工作的意义是深远的。它意味着，长久以来被视为非结构化信息“孤岛”的视频资料库，如今可以被彻底盘活。每一场技术分享、每一次操作演示、每一节在线课程，都能被转化为一个可供精确查询、深度分析、自动关联的结构化知识库。我们不再满足于仅仅知道视频里“讲了什么”，而是能够精确地知道“在第几分几秒，谁，在哪个界面上，对哪个按钮，执行了什么操作，并导致了什么结果”。

结语：为什么是AI无限上下文？

我们从日志、代码、法规一路论证到高冗余的视频，似乎在不断跨越各个技术领域。但我们所有探索的核心，最终指向一个近年来备受关注、却时常被误解的概念：AI的无限上下文（Infinite Context）**。

我们认为真正的“无限上下文”，其挑战并非仅仅是让模型能够接收更长的文本序列。它的核心技术瓶颈在于，如何让 AI 在计算资源有限的前提下，高效地“消化”并“理解”来自现实世界的海量、多模态、高冗余信息。直接将一部 2 个小时的视频所有帧提供给模型是不可行的，这无异于信息洪水。

我们提出的 F.A.S.T. 框架和实体建模思想，正是应对这一挑战的工程化解答：**通过智能预处理，将低密度信息提纯为高密度的结构化知识，再将其作为高质量的“上下文”提供给 AI。**这才是实现“无限上下文”的务实路径。

我们之所以在此刻选择将这套思考与实践开源和推出，是因为我们坚信这一领域的想象空间远超任何单一团队的能力边界。我们的所有相关代码完全开源，我们不会有任何技术上的藏私和保留。

在构建下一代知识基础设施的宏大叙事面前，固步自封是最危险的陷阱。我们希望通过毫无保留的分享，吸引更多志同道合的研究者与工程师加入这场激动人心的探索。

共同进步，将为我们所有人带来一个更智能、更易于获取知识的未来。

---

本文首发于 Yak Project 公众号，阅读原文。