72 lines
5.9 KiB
Markdown
72 lines
5.9 KiB
Markdown
# 向量存储管理
|
||
|
||
向量存储选项卡控制 Inquire 模式背后的智能，这是 Speakr 的语义搜索功能，允许用户使用自然语言问题在其所有录音中查找信息。在这里，你可以监控和管理将转录文本转换为可搜索知识的嵌入系统。
|
||
|
||
|
||
|
||
## 理解 Inquire 模式
|
||
|
||
在深入管理之前，了解你在管理什么是有价值的。Inquire 模式将每个转录文本分解为重叠的文本块，将这些块转换为称为嵌入的数学表示，并以可搜索的格式存储它们。当用户提问时，他们的查询会被转换为相同的数学格式，并与所有存储的块进行比较，以找到最相关的信息。
|
||
|
||
这种方法超越了简单的关键字匹配。系统理解"预算担忧"与"财务约束"和"成本超支"相关，即使确切的词语不同。这种语义理解使 Inquire 模式在发现用户可能无法准确记住的信息时非常强大。
|
||
|
||
## 嵌入模型
|
||
|
||
你的 Speakr 实例使用 all-MiniLM-L6-v2 模型，在界面中显著显示。该模型生成 384 维向量——想象每个文本块映射到 384 维空间中的一个点，相似含义聚集在一起。
|
||
|
||
这个特定模型是经过精心选择的。存在具有更好准确性的更大模型，但它们需要 GPU 和大量计算资源。MiniLM 模型在仅 CPU 的系统上高效运行，使高级搜索无需昂贵的基础设施即可实现。它处理文本速度快、上下文理解好，并生成不会压倒你存储的紧凑嵌入。
|
||
|
||
该模型最适合英文文本，因为这是其训练数据的主要部分。其他语言可能会以不同的成功率运行，但英文内容始终会产生最可靠的结果。这个限制是模型效率和可访问性的权衡。
|
||
|
||
## 处理状态概览
|
||
|
||
状态卡片让你立即了解向量存储的健康状况。总录音数显示你的系统中有多少音频文件，而为 Inquire 处理的数量显示有多少已转换为可搜索的嵌入。这些数字最终应该匹配，尽管随着后台处理赶上通常会存在滞后。
|
||
|
||
需要处理显示等待嵌入生成的录音。当用户上传新内容时这个数字会增加，随着后台处理器处理队列而减少。持续高数字可能表明处理已停滞或你的系统不堪重负。
|
||
|
||
总块数显示你的录音已被分解为的细粒度片段。根据转录密度，典型的一小时录音可能会生成 50-60 个块。这种分块确保即使在非常长的录音中也能找到相关片段。
|
||
|
||
嵌入状态指示器提供快速健康检查。绿色的"可用"表示一切正常运行。其他状态可能表明模型正在加载、处理正在运行或需要注意。
|
||
|
||
## 处理进度
|
||
|
||
处理进度条显示通过嵌入队列的实时进展。当达到 100% 时，所有录音都已处理并可搜索。较低的百分比表示正在进行的工作，随着录音完成条形图会填充。
|
||
|
||
这种视觉反馈帮助你一目了然地了解系统状态。卡住的进度条表明处理已停止。缓慢的进度可能表明系统资源受限。快速的进度显示一切高效运行。
|
||
|
||
## 管理处理队列
|
||
|
||
刷新状态按钮更新所有统计信息和进度指示器，用于监控活动处理或验证最近上传的内容已排队。界面不会自动刷新，因此手动刷新确保你看到的是当前信息。
|
||
|
||
当系统显示录音需要处理但进度没有推进时，可能有几个因素在起作用。后台处理器可能已停止、嵌入模型可能加载失败，或者系统资源可能已耗尽。检查你的日志以获取具体的错误消息。
|
||
|
||
处理系统被设计为具有弹性。如果特定录音的处理失败，系统会标记它并继续而不是卡住。这些失败会出现在你的日志中，可能需要手动干预来解决。
|
||
|
||
## 优化性能
|
||
|
||
处理性能在很大程度上取决于你的系统资源。嵌入模型在加载时需要大约 500MB 的 RAM，再加上处理文本的额外内存。CPU 速度直接影响嵌入生成的速度——现代多核处理器可以同时处理多个录音。
|
||
|
||
磁盘 I/O 也很重要。系统读取转录文本、处理它们并将嵌入写回数据库。快速存储，特别是 SSD，可以显著提高处理吞吐量。如果你的向量存储与转录文本在不同的磁盘上，请确保两者都有足够的性能。
|
||
|
||
网络延迟不应该影响处理，因为一切都在本地发生，但数据库性能很重要。定期数据库维护，包括索引优化和清理操作，即使你的向量存储增长也能保持查询快速。
|
||
|
||
## 常见问题故障排除
|
||
|
||
当 Inquire 模式在处理过的录音下返回较差的结果时，问题可能是查询表达而非向量存储。鼓励用户问完整的问题而不是输入关键字。"John 关于预算说了什么？"比仅仅"John 预算"效果更好。
|
||
|
||
如果处理似乎冻结了，请检查 sentence-transformers 库是否正确安装。没有它系统会优雅降级，禁用 Inquire 模式而不是崩溃，但处理不会推进。你的日志会显示嵌入模型是否成功加载。
|
||
|
||
处理期间的内存错误通常表明你的系统试图同时处理太多内容。分块系统防止单个录音压倒内存，但并行处理多个大录音可能会超出可用 RAM。
|
||
|
||
## 扩展考虑
|
||
|
||
向量存储随着你的内容可预测地增长。每个块需要大约 2KB 的存储用于其嵌入和元数据。生成 50 个块的典型一小时录音需要大约 100KB 的嵌入存储。一万小时的录音可能需要 100MB 的嵌入存储——即使在适度的系统上也是可管理的。
|
||
|
||
得益于高效索引，即使使用大型向量存储，搜索性能仍然保持快速。然而，极其大型的实例（数十万条录音）可能受益于专用向量数据库解决方案，而不是内置的 SQLite 存储。
|
||
|
||
如果你的实例增长到超出舒适的限制，请考虑归档旧录音。向量存储仅包含活动录音，因此删除过时内容可以同时改善存储和搜索性能。
|
||
|
||
---
|
||
|
||
返回[管理员指南概览](index.md) →
|