Skip to content

Search and Resources

msjsc001 edited this page Jul 31, 2026 · 2 revisions

Search and Resources / 查询与资源管理

← Wiki home / 手册首页 · English · 中文 · Troubleshooting / 故障排查

Use this page when / 适用情况: interpreting the stage button beside Search, checking whether CUDA or the reranker actually ran, or understanding a safe fallback.
理解“查询”右侧的阶段状态、确认 CUDA 或重排是否实际执行,或者判断一次安全降级是否仍能正常使用。

English

Query stages

The status control beside Search reports the active stage:

  1. preparing and validating selected knowledge bases
  2. lexical recall
  3. semantic vector recall
  4. extension retrieval and cross-source fusion
  5. optional reranking
  6. result finalization and filtering
  7. context packing

Selected knowledge bases can have different sizes and warm/cold model states, so stage times may vary substantially.

What “hybrid” means

A complete hybrid query combines lexical and semantic candidates before fusion and optional reranking. A result can still be useful when one optional stage is skipped, but the Query Console and activity log should describe the actual path rather than pretending the full path ran.

Auto device behavior

Auto prefers CUDA only when all of these are usable:

  • Runtime imports and CUDA detection
  • embedding model and vector index
  • enough Windows Commit and physical memory for the next model load
  • enough GPU memory for the real model and activation estimate

The decision is workload-aware. It is not based on one universal free-memory number for every computer.

Possible safe outcomes include:

  • CUDA semantic recall and CUDA reranking
  • CUDA semantic recall with reranking skipped
  • CPU semantic recall
  • lexical recovery after a semantic worker failure

Reading resource messages

  • Vector recall completed on CUDA: semantic retrieval used the NVIDIA GPU.
  • Reranker skipped: recall results remain usable, but the optional second-pass ordering was not applied.
  • Low Commit headroom: the Windows commit limit, not simply visible free RAM, constrained another model load.
  • CUDA out of memory: the GPU could not make the requested allocation even if total free memory appeared close to the estimate.
  • Lexical recovery: the isolated semantic worker exited or could not complete, and a safer fallback returned results without crashing the UI.

Practical actions

  1. Keep Auto selected unless diagnosing a device-specific issue.
  2. Avoid running several large AI models simultaneously.
  3. Let Windows manage the paging file automatically.
  4. Re-run the query after other heavy work has released resources.
  5. Use CPU intentionally when predictable completion matters more than speed.
  6. Rebuild the vector index only when status says it is missing or incompatible; resource pressure alone is not a reason to rebuild.

Logs for diagnosis

QUERY_PLAN, QUERY_FINGERPRINT, and QUERY_STAGE describe planned stages, the active environment, actual devices, candidate counts, fallback reasons, timings, and resource snapshots. When reporting a problem, include the complete block for each selected knowledge base and the user-facing messages below it.

Before sharing logs publicly, remove private source paths, workspace names, and other personal identifiers.

中文

查询阶段

“查询”右侧的状态控件会显示当前阶段:

  1. 准备并校验选中的知识库
  2. 字面召回
  3. 语义向量召回
  4. 扩展格式检索和跨来源融合
  5. 可选重排
  6. 结果整理与过滤
  7. 上下文组装

多个知识库的规模、模型是否已经加载都可能不同,因此各阶段耗时会有明显差异。

“混合检索”代表什么

完整混合查询会组合字面候选与语义候选,再融合并按需进行重排。某个可选阶段跳过后结果仍可能可用,但查询台和活动日志应明确显示实际路径,而不是假装所有阶段都已执行。

Auto 的设备决策

只有以下条件都可用时,Auto 才会优先采用 CUDA:

  • Runtime 导入与 CUDA 检测正常
  • 向量模型和向量索引就绪
  • Windows Commit 和物理内存足够支持下一次模型加载
  • 显存能够容纳真实模型和激活量估计

这个判断会结合实际工作负载,并不是所有电脑共用一个固定空闲内存数字。

可能出现的安全结果包括:

  • CUDA 语义召回和 CUDA 重排
  • CUDA 语义召回成功,但跳过重排
  • CPU 语义召回
  • 语义子进程失败后进行字面恢复

理解资源提示

  • 向量召回在 CUDA 完成:语义检索实际使用了 NVIDIA GPU。
  • 跳过 Reranker:召回结果仍可使用,但没有进行可选的二次排序。
  • Commit 余量不足:限制来自 Windows 提交上限,不只是任务管理器显示的空闲物理内存。
  • CUDA 显存不足:即使显示的总空闲显存接近估算值,GPU 也可能无法完成实际连续分配。
  • 字面恢复:隔离的语义子进程退出或未完成,软件使用更安全的降级路径返回结果,主界面不会因此退出。

实际处理方法

  1. 除非正在排查设备问题,否则保持 Auto。
  2. 避免同时运行多个大型 AI 模型。
  3. 让 Windows 自动管理分页文件。
  4. 等其他重型任务释放资源后重新查询。
  5. 如果稳定完成比速度更重要,可以主动选择 CPU。
  6. 只有状态明确提示向量索引缺失或不兼容时才需要重建;单纯资源压力不需要重建索引。

用日志诊断

QUERY_PLANQUERY_FINGERPRINTQUERY_STAGE 会记录计划阶段、当前环境、实际设备、候选数量、降级原因、耗时和资源快照。反馈问题时,请提供每个选中知识库的完整日志块,以及后面的用户提示。

公开分享日志前,请删除私人来源路径、工作区名称和其他个人标识。


Previous / 上一篇: ← Knowledge Bases and Live Watch / 知识库与热监听 · Next / 下一篇: PDF and Tika / PDF 与 Tika →

Clone this wiki locally