打造高效游戏音频问答知识库

大家好，我是溪夜。

游戏音频开发中，查文档是“家常便饭”，但受限于关键词匹配不准或信息分布零散，简单的查询往往会变成消耗精力的“时间黑洞”。

去年我接触到了 RAG（检索增强生成），发现它能完美解决文档检索难题，可以精准提取信息并遏制大模型的幻觉。

本文以“如何高效检索 Wwise 文档”为例，分享我的完整落地方案。希望能帮大家告别低效检索，把时间留给更重要的创意设计工作。

术语

文中会用到这些术语缩写：

RAG：Retrieval-Augmented Generation，即检索增强生成
LLM：Large Language Model，即大型语言模型

知识检索的痛点

游戏音频开发过程中，文档分散在各处：

Wwise：在线文档受网速影响，体验不稳定；离线文档则分散为多个不同格式（PDF、HTML、CHM），需要在不同目录间来回切换
Unity / Unreal：在线文档体验尚可，但离线文档体验较差，本质上是散装的 HTML 网页，查阅起来很麻烦
REAPER：在线文档仅包含 API（e.g. 官方文档、X-Raym）；离线文档体验很好，是一份结构清晰、更新及时的专业文档
编程语言文档：体验取决于维护情况。有些文档完善且易于检索，有些则体验欠佳

找到需要查阅的文档后，还会面临以下困扰:

检索效率低：无论文档是什么格式，都要重复"打开文档 → 搜索关键词 → 结果不匹配 → 再次搜索"
关键词匹配难：常常因为关键词不够精准、英文术语不熟悉，导致事倍功半
破坏工作心流：在多份文档之间反复横跳，容易打断工作节奏

AI 时代的思路

直接问 LLM？

有些人会直接向 LLM 提问，但受限于模型训练数据取向和知识截止日期，并非每个问题都能得到满意的回答。那么把文档都上传聊天窗口里不就行了？但这样做仍有两个问题：

性能下降：现代 LLM 的上下文窗口普遍较大，但仍容易被文档"撑爆"，导致回答卡顿、出现幻觉
重复劳动：即使只上传少量文档，每个对话的上下文长度仍有限，达到上限后需要开启新对话，意味着要重复文档上传操作

是时候使用 RAG 了

这时候就该 RAG（Retrieval-Augmented Generation，即检索增强生成）登场了，它的工作原理可简单总结为：

构建知识索引：将文档压缩、摘要，转化为知识图谱。并独立于对话窗口存在，开启新对话也无需重复上传文件
分层检索：通过逐层披露的方式，精准提取相关片段，有效解决“大海捞针”的难题并节省 Token
减少幻觉：将模型回答严格锁定在用户文档中，确保回答”有据可依”，最大程度遏制 AI 的幻觉

听起来很完美，但搜索“如何使用 RAG”时，找到的方案里充斥着“环境配置”、“接入模型 API”、“向量数据库部署” 等晦涩术语，似乎这是个高级用户的专属工具。但实际上，普通用户使用 AI 工具的黄金法则是：拥抱大公司打磨好的成品。这样可以避开部署、运维等繁琐工作，专注于使用本身。基于这个原则，正式引入本文的主角，由 Google 开发的学习笔记产品 —— NotebookLM。

介绍 NotebookLM

NotebookLM 是 Google 在 2023 年推出的 RAG 笔记产品，作为 Google AI 全家桶的成员之一，它继承了 Gemini 的用户体验设计，界面简洁、功能强大，并且无需付费就可使用几乎所有功能。在本文写作时，它内部的模型更是升级到了 Gemini 3（Flash 和 Pro 混用，负责文字）和 Gemini 3 Pro Image（即 Nano Banana Pro，负责图片、幻灯片），产品底层的模型能力非常强悍。相较于其它 RAG 方案，NotebookLM 在性能和易用性方面几乎没有对手。更重要的是，它严格基于用户提供的文档来生成答案，有效避免了幻觉问题。在我使用 NotebookLM 的半年时间里，它从未给出过脱离文档来源的臆想内容，这一点让我非常放心。

如何提一个好问题

开始看使用案例之前，有必要再介绍一下如何提问。很多时候 LLM 给出的结果不好，核心原因提问本身质量不佳。我曾读到一句描述人际沟通的话：“语焉不详是对他人的霸凌”，这句话深刻揭示了上下文在沟通中的地位。在与 LLM 交互时，这一点尤为重要。提问前不妨先问问自己：我把问题说清楚了吗？提供的背景信息足够吗？越详细的上下文，越能获得精准的回答。

举个例子，同样是询问音画不同步问题:

差：“音乐同步不准怎么办？”
好：“我在 Unreal 的 Level Sequence 中通过 AkAudioEvent 轨来播放 AkEvent，但在 Sequence 比较长且场景复杂时，偶尔会出现音画不同步问题，有哪些解决方案？”

AI 时代改变了我们获取知识的方式。传统搜索是用关键词"打捞"答案，而向 AI 提问更像是在"召唤"——通过语义理解和内容生成，让答案主动浮现。答案就在那里，只要你问对问题。

使用案例

下面通过几个 Wwise 开发中的实际问题，展示 NotebookLM 的回答质量。案例中涵盖了概念辨析、性能优化、生成表达式、理解 SDK 等场景，可以看出 NotebookLM 提供的答案在准确性和可读性上都表现出色。

案例一：State 和 Switch 的区别

问题：Switch 和 State 的主要区别是什么？它的应用场景分别是什么？答案：

在 Wwise 中，**State（状态）**和 **Switch（切换开关）**都是用于驱动游戏音频动态变化的“游戏同步器”（Game Syncs），但它们在作用范围、功能目的以及具体应用场景上存在显著区别。
以下是它们的主要区别与应用场景：

1. 主要区别
• 作用范围（Scope）：
    ◦ State 是全局性的（Global）。一旦状态改变，它会同时影响游戏中所有正在播放的相关声音。例如，如果将状态设为“在菜单中”，全局的背景音乐音量都会受到影响。
    ◦ Switch 是基于游戏对象（Game Object）的。不同的游戏对象可以同时处于不同的 Switch 状态。例如，两个不同的 NPC 走在不同的地面上，各自触发对应的脚步声 Switch，互不干扰。
• 功能目的：
    ◦ State 主要用于属性调整（Mixer Snapshots）。它像是一组“混音快照”，通过改变音量、音高、低通滤波器（LPF）等属性的偏移量，让现有的声音适应环境变化，而无需增加新的音频资源。
    ◦ Switch 主要用于选择替代方案（Alternatives）。它用于根据当前环境或对象状态，从一个“切换容器”（Switch Container）中选择完全不同的音频内容来播放。
• 对声音的影响方式：
    ◦ State 改变的是正在播放的声音的属性，且状态间可以定义**过渡时间（Transition Time）**来实现平滑切换。
    ◦ Switch 决定的是播放哪一个声音文件或容器。

2. 应用场景
State（状态）的应用场景：
通常用于模拟物理环境或全局条件的持续性改变：
• 环境变化： 例如角色潜入水下（Underwater），此时可以使用 State 全局调低所有陆地声音的音量并增加低通滤波，模拟闷响效果。
• 游戏状态： 如玩家阵亡（Player Dead）、进入暂停菜单（In Menu）或时间减缓（Slow Motion），通过改变全局混音快照来营造氛围。
• 身体/心理状态： 例如角色处于耳鸣/眩晕（Stunned）状态，通过 State 暂时改变所有声音的音高和音量。
• 交互式音乐： 在音乐系统中使用 State 来控制音乐的激烈程度（如从“探索”切换到“战斗”），让音乐随剧情全局平滑过渡。

Switch（切换开关）的应用场景：
通常用于处理同一类行为在不同条件下的具体表现形式：
• 地面材质： 这是最典型的场景。同一个“脚步声”事件，根据角色脚下的材质（草地、混凝土、木板、地毯）切换到对应的声音容器。
• 武器/装备： 根据角色使用的武器类型（手枪、自动步枪）或弹药类型选择不同的射击声。
• 对象模式： 如引擎状态（怠速、高速、待机）或角色性别（男声、女声语音切换）。
• 材质驱动的交互： 如根据车辆撞击力度的大小，使用 Switch 选择轻微刮擦或剧烈碰撞的声音。

总结比喻
你可以将 State 想象成天气：当乌云密布（State = Rainy）时，整个世界的光线都会变暗，雨水会淋湿所有人，这是一个全局性的环境影响。
而 Switch 就像是衣服：在这个雨天里，每个行人（Game Object）可以根据自己的选择穿雨衣、打伞或直接淋雨，每个人选择的“替代方案”是独立且互不干扰的。

案例二：Wwise 生成 SoundBank 时的性能优化思路

问题：我想要优化 Wwise Console 生成 SoundBank 时的性能，它在哪些步骤上是可以通过升级硬件来优化的？答案：

优化 Wwise Console 生成 SoundBank 的性能，主要涉及对多核 CPU 资源的充分利用、磁盘 I/O 吞吐量的提升以及合理的生成策略。
根据参考资料，以下是可以通过硬件及相关配置进行优化的关键步骤和方法：

1. 核心硬件优化：多线程处理（CPU）
Wwise 及其命令行工具 Wwise Console 在生成 SoundBank 时，最耗费计算资源的步骤是音频转码（Audio Conversion/Transcoding）。
• 自动多核并行： Wwise 会自动识别并利用机器上多核 CPU 的所有处理核心来加速转码过程。在生成过程中，系统会为每个处理器内核分配独立的文件转码任务。
• 并发实例（针对构建集群）： 如果您在自动化构建环境中使用 Wwise Console，可以使用 --no-wwise-dat 参数。该选项允许多个 Wwise 实例同时向同一个目录执行转码而不会发生冲突。这在利用分布式硬件（如多台服务器或极高核心数的机器）并行构建大型工程时非常有效。
• 多核渲染支持： 虽然主要针对运行时，但在设计工具端进行渲染分析时，Wwise 也会利用多核性能。

2. 磁盘 I/O 与存储优化
SoundBank 的生成涉及数以万计的小文件（Originals 素材和生成的 .wem 文件）的读取与写入。
• 使用 SSD 硬盘： 资料明确指出，在配有 SSD 硬盘的机器上进行操作可以显著减少因 I/O 等待导致的时间延迟。
• 减少磁盘竞争： 在执行 Wwise Console 任务时，建议关闭其他高 I/O 占用的程序，例如云同步、防病毒扫描或版本控制系统的后台同步进程，以确保磁盘带宽完全供应给 Wwise。

3. 利用缓存机制减少硬件开销（策略优化）
硬件的性能再高，也比不上直接跳过无需重复的工作。
• 增量生成（Incremental Generation）： Wwise 会通过 .cache 文件夹和 SoundBankInfoCache.dat 文件跟踪更改。如果对象或设置没有变化，Wwise Console 会跳过转码并报告“Up to date”（最新），从而避免重复消耗 CPU 和 I/O 资源。
• 禁用 DECODED 文件生成： 通过在 Wwise Console 中使用 --no-decode 参数，可以避免在缓存文件夹中生成 DECODED 文件。这不仅能节省 CPU 计算周期，还能减少磁盘空间占用，从而间接提升 I/O 响应速度。
• 保留时间戳： 在版本控制系统中启用“保留时间戳”（Preserve timestamps）功能，可以在生成 SoundBank 时略微提升 Wwise 的检测效率。

4. 内存管理
虽然 SoundBank 生成主要受 CPU 和 I/O 驱动，但充足的系统内存有助于 Wwise 维护大型工程的元数据结构和查询索引。Wwise 的默认内存管理器（rpmalloc）在处理多核渲染和高并发任务时具有更好的性能表现。
总结建议： 为了获得最佳生成性能，硬件上应优先选择高主频且多核心的 CPU 以及 NVMe SSD。在软件调用层面，确保 Wwise Console 运行在增量模式下，并根据构建环境考虑使用 --no-decode 或并行运行多个实例。

案例三：生成准确的 WAQL

问题：生成一个 WAQL 查询语句，查询 \Events\Awesome 下所有类型为 Stop 的 Action 答案：

您要求的 WAQL（Wwise Authoring Query Language）查询语句可以查找路径 \Events\Awesome 下所有类型为 Stop 的 Action 对象。
WAQL 查询通常以 $ 符号开头。

WAQL 查询语句：
$ "\Events\Awesome" select descendants where type = "Action" and (@ActionType = 2 or @ActionType = 3)

解析：
1. $：表示这是一个 WAQL 查询。
2. "\Events\Awesome"：定义查询的起始点，即指定的工程路径下的对象（一个对象生成器）。
3. select descendants：这是一个转换语句，用于选择起始对象（\Events\Awesome 文件夹/工作单元）下的所有下级对象（包括事件、事件动作等）。
4. where type = "Action"：这是一个筛选语句，用于将输入序列（所有下级对象）筛选为仅保留类型为 "Action" 的对象。
5. and (@ActionType = 2 or @ActionType = 3)：进一步筛选这些 Action 对象，使其动作类型匹配“Stop”。
    ◦ Wwise 中的 Action 对象具有 @ActionType 属性。
    ◦ 根据源文件提供的 Action 类型值，动作类型 2 对应于 /Stop/Stop，而 3 对应于 /Stop/Stop All。由于查询要求所有类型为 Stop 的 Action，因此需要使用逻辑运算符 or 将这两种具体的 Stop 动作包含在内。

注意：
WAQL 查询可用于 Wwise 工具栏搜索、List View 搜索、Query Editor 和 WAAPI（使用 ak.wwise.core.object.get 函数）。在 Project Explorer Search 中虽然支持 WAQL，但它只会显示 Event 本身，而不会显示 Event Action。因此，要获取 Event Action，最好在 List View 搜索字段、Query Editor 或通过 WAAPI 使用此查询。

案例四：查询结构体用法

问题：AkAudioObject 结构体的用法是什么，它包含哪些成员？答案：

AkAudioObject 结构体在 Wwise 声音引擎中代表带有附加元数据的音频信号，它是整条对象管线中随音频缓冲区一并传输的元数据封装。

AkAudioObject 的主要用法
1. 对象处理器感知：与传统的仅能处理音频信号的效果器插件不同，Object Processor（对象处理器） 插件可以感知并统一处理通过总线发送的所有 AkAudioObject 实例，并访问其相应的元数据。
2. 空间化渲染：基于对象的音频管线允许 Wwise 将音频缓冲区连同其对应的元数据（如 3D 位置和朝向）一并发送到平台操作系统的音频组件（终端），从而在支持 3D Audio 的终端上实现最高精度的空间化效果。
3. 动态处理：对象处理器可以读取并修改所有音频对象的信号和元数据，但只有非原地（Out-of-place）处理器能够创建或移除对象及更改声道配置。

AkAudioObject 包含的成员
根据 Wwise SDK 定义，该结构体包含的成员可分为以下几类：
• 标识类成员：
    ◦ AkAudioObjectID key：在给定总线内本地唯一的 ID。
    ◦ AkPipelineID instigatorID：发起端节点（通常是声部或角色混音器实例）的 Pipeline ID，用于性能分析。
    ◦ String objectName：显示在性能分析器中的对象名称字符串。
• 定位元数据：
    ◦ AkPositioningData positioning：用于延迟 3D 渲染的定位数据，保存了 3D 位置、朝向、散布（Spread）和聚焦（Focus）等设置。
• 增益与优先级：
    ◦ AkRamp cumulativeGain：上游应用的累积增益，例如音频源的音量设置或来自总线的增益变化。
    ◦ AkPriority priority：音频对象的播放优先级。当硬件对象不足时，终端可据此决定哪些对象使用硬件渲染，哪些下混到 Bed 中。
• 自定义元数据：
    ◦ ArrayCustomMetadata arCustomMetadata：存储从访问过的 Wwise 对象中收集到的自定义元数据插件数组，可由对象处理器读取以执行特定逻辑（如直通模式）。

总结：AkAudioObject 本身不包含音频采样数据（采样数据存储在对应的 AkAudioBuffer 中），它充当音频信号的“身份卡”和“导航信息”，指导声音引擎和硬件终端如何正确地渲染和定位该信号。

查看回答来源

NotebookLM 的每个答案都会标注信息来源（Source Grounding），点击答案中的“原文角标”，即可在来源文档中反向溯源。以案例一为例，点击回答中 State 是全局性的（Global） 旁边的数字角标 3，即可跳转到左侧来源文档。可以看到这个结论来自 WwiseHelp_en_01.pdf 中的这条定义：

State: A global offset or adjustment to the game audio properties that represent changes in the physical and environmental conditions in the game.

搭建知识库

方法一：使用预拆分的文档，创建知识库

为了让 NotebookLM 能够理解 Wwise 文档，需要对文档进行两步预处理：

格式转换：NotebookLM 不支持 CHM，需要转为 PDF 格式
文档拆分：控制每个来源文件的 Token 数，以保证 RAG 性能

为了方便大家，我将 Wwise 2019 - 2024 各版本的最新小版本文档都做好了预处理，压缩包内包括：

双语文档：每个版本都有中文和英文两套文档，供大家按语言偏好自行选择
文档范围：
- 包含 Wwise Fundamentals、Wwise Help、Wwise SDK Windows、Wwise Unity Integration Help、Wwise UE Integration 五个文档
- 版本号为 2019.1.11、2019.2.15、2021.1.14、2022.1.19、2023.1.18、2024.1.10、2025.1.4
下载链接：https://drive.google.com/file/d/1GqPieIqQLZmPVuU-nA_zxRMnFVZcwd9a

下面介绍一下如何创建知识库（笔记本）：

方法非常简单，只需打开 NotebookLM 主页 https://notebooklm.google.com
点击 新建笔记本，在弹出的窗口中，将所需的文档拖拽并上传到笔记本。这里可根据实际需求（例如集成文档中，选用当前项目所使用的引擎文档），对文档进行筛选。
稍等片刻，等文档分析结束，就可以自由提问了。

方法二：自行处理文档，创建知识库

若你使用的 Wwise 版本不在压缩包中，或想要搭建其他领域的知识库，可以使用我开发的开源工具 DocWeaver 自行处理文档。 DocWeaver 提供以下功能：

根据 Token 数自动预估拆分份数
CHM/HTML 等格式转换为 PDF。因现有的 CHM 转 PDF 方案均无法完美转换 Wwise CHM 文档，所以我重新写了一版转换算法以适配该需求
按设定大小智能拆分文件
支持命令行批处理，限于篇幅不在本文展开介绍，可访问 GitHub 仓库后在 README 中查看用法

下面从零制作一个 Wwise 笔记本，这里假设 Audiokinetic Launcher 中已下载了所需的文档。

找到所需的文档，可以在 Audiokinetic Launcher 中点击版本右边的问号打开文档，或点击右边的“扳手图标”后，在弹出的菜单中点击 Open Containing Folder，在 Wwise 安装目录中可以找到绝大多数文档
打开从 DocWeaver 的 GitHub Release 页面，找到所需版本（arm64 是 macOS ARM 架构的版本，x86_64 是 Windows X86 64 位架构的版本）下载并解压，地址：https://github.com/zcyh147/DocWeaver/releases
打开工具后，将需要处理的文件拖拽进工具的 Drag & Drop 区域。
稍等片刻，查看预估的拆分文件数量
点击 Split All，在弹出的窗口中设置输出目录，即可开始处理。工作结束后，输出文件会以 <源文件名>_<数字后缀>.pdf 的格式命名（若未达到 Max Tokens 则会原样拷贝一份到输出目录），随后参考方法一创建笔记本即可

补充说明

NotebookLM 的优缺点

每个产品均有优缺点，NotebookLM 也不例外。

优点：

免费用户就可享受绝大多数功能，例如
- 可创建 100 个笔记本、每个笔记本 50 个来源；每天可对话 50 次对话，及生成 3 次音频概览
- 可使用 Slides 生成、Deep Research 等进阶功能
跨平台无缝体验，支持网页端、移动端 App
大公司维护，极其靠谱
Google AI Pro 付费会员（20 美金/月）性价比极高，可同时使用 Gemini、NotebookLM、Slides、Opal 在内的 Google AI 全家桶

缺点：

大陆地区不可用，可用的国家地区见 https://support.google.com/gemini/answer/13575153
对重度用户而言，每日免费 50 次查询显然不够
数据存储于 Google 服务器，私有数据难以实现保密
笔记本中每个来源的总 Token 数有限制。若文件字数较多，需手动拆分以确保 RAG 性能

为什么用 PDF 作为笔记本来源格式

之所以选择 PDF 而非 TXT，主要是为了保留图片信息：

NotebookLM 已支持将手写文件图片作为来源，并能够识别其中的笔记和公式，这说明正在逐渐放开图像理解能力
我预测它很快会全量开放图像理解功能，因此通过 PDF 保留图片具有前瞻意义——当该功能上线时，无需重新制作文档，即可对图片进行提问
PDF 的目录（Outline）作为文档的结构树，在 RAG 的切分和检索过程中，能够提供更精准的上下文定位

DocWeaver 中，单个来源的默认 Token Limits 为什么是 50 万

NotebookLM 对每个来源文件的 Token 数量有限制。经测试，单个来源在 80 万 Token 左右时，仍能保持较好的检索准确度。之所以在 DocWeaver 中将默认 Tokens 数设置为 50 万，是因为较小的文件，能获得更快的检索速度和更稳定的回答质量。对于 Wwise 知识库笔记本来说，十几个来源即可覆盖所有文档，远没有达到笔记本的来源数上限，因此追求单个来源的 Token 极限没有实际意义。

为什么我的 NotebookLM 里有标签

NotebookLM 有个小缺点：不支持文件夹和标签功能。当笔记本数量增多时，管理起来会比较麻烦。好在 GitHub 上有开发者提供了解决方案——NotebookLM Categorizer 插件。安装后可在网页增加一栏自定义标签栏，让笔记本管理更加便捷。地址：https://github.com/muharamdani/notebooklm-categorizer

扩展用例

生成音频概览，视频概览，演示文稿等

NotebookLM 提供了丰富的内容生成功能，可以将笔记本转化为：

音频概览：自动生成播客式的对话总结
演示文稿：一键生成结构化的幻灯片
学习卡片：问答式的知识点梳理
思维导图：可视化的知识结构这些功能在学习新知识时非常实用。生成时还可通过自定义 Prompt 进行个性化定制。关于详细用法和最佳实践，互联网上已有大量优秀教程，本文不再赘述。

与 Gemini 结合使用

在 Gemini 的问答框中，点击 +，在弹出的菜单中选择 NotebookLM，即可让笔记本参与对话。NotebookLM 笔记本会作为 Gemini 的外挂知识库，发挥 Agentic RAG 的功能。此时 Gemini 可以同时在 NotebookLM 和公开的信息源中检索答案，某些用例下可输出更全面的答案。

增加更多数据，搭建更具参考价值的知识库

除了官方文档，任何资料（e.g. 博客文章、演讲记录、YouTube 视频）都可作为 NotebookLM 的查询来源。合理利用这一特性，可以构建更丰富、更具针对性的知识库。需要提醒的是，添加内容时请确保来源合法合规，尊重知识产权，避免法律风险。

总结

在这篇文章中，介绍了如何使用 Google NotebookLM 搭建游戏音频开发的问答知识库，通过 RAG 技术解决文档检索效率低下的痛点。从痛点分析、工具选型到实际操作，分享了一套完整的落地方案：

使用预处理好的 Wwise 文档，可以快速创建知识库
借助 DocWeaver 工具，可以自行处理其他版本或领域的文档
结合 NotebookLM 的多媒体生成和 Gemini 集成功能，可以进一步提升学习效率

特别感谢

感谢 Audiokinetic 团队多年来对 Wwise 技术文档的精心维护。正是他们对文档质量的执着追求和持续投入，为开发者提供了如此完善的学习资源，才让这个知识库方案有了扎实的基础。

版权声明

本文提供的 Wwise 文档资料均来自 Audiokinetic 官方，版权归 Audiokinetic 所有，仅供学习使用。

术语#

知识检索的痛点#

AI 时代的思路#

直接问 LLM？#

是时候使用 RAG 了#

介绍 NotebookLM#

如何提一个好问题#

使用案例#

案例一：State 和 Switch 的区别#

案例二：Wwise 生成 SoundBank 时的性能优化思路#

案例三：生成准确的 WAQL#

案例四：查询结构体用法#

查看回答来源#

搭建知识库#

方法一：使用预拆分的文档，创建知识库#

方法二：自行处理文档，创建知识库#

补充说明#

NotebookLM 的优缺点#

为什么用 PDF 作为笔记本来源格式#

DocWeaver 中，单个来源的默认 Token Limits 为什么是 50 万#

为什么我的 NotebookLM 里有标签#

扩展用例#

生成音频概览，视频概览，演示文稿等#

与 Gemini 结合使用#

增加更多数据，搭建更具参考价值的知识库#

总结#

特别感谢#

版权声明#

术语