[polish] 支持根据 ASR 结果和元数据，自定义 LLM 润色策略与调用参数

Offen
  • Stimmt etwas nicht?
#1,225 7 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@HKLHaoBin arbeitet bereits daran.

Seit 24.10.2026.

  • #1262 von @HKLHaoBin — offen

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
38/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
rust, tauri
Bereich
ai, api, desktop

Rechercherichtung

Start by locating the application pipeline between final ASR output and the LLM request, then map the existing ASR metadata and request configuration structures. Design and document the hook’s typed input, structured output, supported overrides, error fallback, and unchanged default behavior. Done when users can skip polishing or override supported request parameters, with examples and tests covering short-text skipping, text-length-based reasoning settings, and disabled-hook compatibility.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

现象

不同语音输入对润色的需求并不相同。短句的 ASR 结果可能已经足够准确，直接输出或使用较低的推理强度即可；较长、较复杂的内容，则可能需要更充分的整理。

希望能够根据每次 ASR 的结果，自动决定是否调用 LLM，以及本次调用使用哪些参数，减少手动切换配置的操作。

功能建议

在 ASR 完成后、LLM 请求发起前，提供一个可选的用户自定义函数，并明确其输入、输出格式。

OpenLess 应公开传入函数的 ASR 结果结构，提供若干文本和 metadata 字段供用户判断。例如：

字段示例 含义
text 最终转写文本
charCount 文本字符数，并明确空白、标点等的计数规则
audioDurationMs 音频时长
language 识别语言，如可获得
confidence 识别置信度，如 ASR 服务提供
asrProvider 本次使用的 ASR 服务或引擎

这些字段可以来自 ASR 返回结果，也可以由 OpenLess 整理或计算。希望文档明确字段类型、单位、可选性和缺失时的表示方式；不同 ASR 服务的置信度若不可直接比较，也应说明其含义。

函数的返回值可以是一个结构化的策略对象，既能决定是否跳过润色，也能覆盖本次 LLM 调用的部分参数，而不局限于 true / false。

使用示例

以下用 JavaScript 示意，不限定实际脚本语言或最终 Hook 接口名称。

示例中的 action 和 request 是建议的返回结构：action 决定是否润色，request 中的字段用于覆盖本次 LLM 请求参数，未指定的参数沿用当前配置。

LLM 参数采用 OpenAI Chat Completions API 的官方写法 reasoning_effort。如果使用 Responses API，对应写法为 reasoning: { effort: "none" } 等。具体支持哪些值取决于所选模型。OpenAI 官方文档

function configurePolish({ charCount }) {
  // 少于 5 个字符：跳过 LLM，直接输出 ASR 原文
  if (charCount < 5) {
    return { action: "skip" };
  }

  // 5–9 个字符：调用 LLM 润色，但不启用推理
  if (charCount < 10) {
    return {
      action: "polish",
      request: { reasoning_effort: "none" },
    };
  }

  // 100 个字符及以上：使用 medium，也可按需改为 low
  if (charCount >= 100) {
    return {
      action: "polish",
      request: { reasoning_effort: "medium" },
    };
  }

  // 10–99 个字符：沿用当前润色配置
  return { action: "polish" };
}

这些阈值仅用于说明用户可以自定义策略。skip 表示完全不发送 LLM 请求；reasoning_effort: "none" 则仍会调用 LLM 生成润色结果。

长度只是一个示例。开放明确的输入结构和返回协议后，用户还可以结合语言、音频时长、文本内容等制定规则，也可以按需调整其他受支持的 LLM 请求参数。

预期收益

让简单输入更快完成，同时为复杂输入保留更充分的润色能力。用户可以根据自己的 ASR 准确度和使用习惯，在响应速度、调用成本和输出质量之间进行调整。

建议接受标准

  • 提供用户自定义策略函数，在最终转写完成后、LLM 请求发起前执行。
  • 文档公开函数输入结构，至少包含转写文本及若干可用于判断的 metadata 字段。
  • 明确各字段的类型、含义、计算规则，以及不可用时的表示方式。
  • 支持通过返回对象跳过润色，或覆盖本次调用的部分 LLM 参数；未指定的参数沿用当前配置。
  • 跳过润色时不发送 LLM 请求，直接输出 ASR 原文，并作为正常流程处理。
  • 明确可覆盖的参数、对应的 API 格式及适用范围，并说明模型不支持某个参数时的处理方式。
  • 提供同时展示“短文本跳过 LLM”和“按文本长度调整推理强度”的示例。
  • 未启用该功能时保持现有行为，并明确函数执行异常时的回退方式。

相关讨论

#1032 已提出按字数跳过短输入润色的场景。本请求进一步希望开放 ASR 结果和元数据，以及可编程的润色策略接口。

Vorherrschende Sprache
Rust
Sterne
3.7k
Forks
349
Ø Merge
2 T. 14 Std.
Gemergte PRs (30 T.)
97

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus Open-Less/openless

Alle Issues in Open-Less/openless

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.