なぜ生のトランスクリプション十分ではないのか
大声で思考を話し、すべて「um、」「uh、」「あなたがわかっている、」false start キャプチャされ、逐語的にされたアイデア想像してください。つまり、生のスピーチ転写です。Whisperモデル - 利用可能な最も正確 - あなたが言った、フィラー単語、すべて誠実にトランスクリプト含め。
その思考の編集版、メールまたはドキュメントであなたが書いたことがあるが、完全に見える異なる。より良い句読点。削除フィラー。適切な構造。プロフェッショナル登録。
これら2つのバージョン間のギャップはAI テキスト充実がブリッジ。
あなたの音声とテキスト間で何が起こるのか
AIエンリッチメント付きスピーチテキスト変換パイプライン、2つの異なるステージを持ちます:
段階1: トランスクリプション。 あなたのオーディオはスピーチ認識モデルで処理される - Telvrの場合、Whisper large-v3。これはオーディオ波形をテキスト高精度に変換。出力は生トランスクリプト: あなたが言ったことは、話された言語のすべての自然不完全性を含めて。
段階2: エンリッチメント。 生のトランスクリプトはそれと何を行うか説明するのに特定のプロンプトを持つ言語モデルに渡されます。言語モデルはトランスクリプションをフォーマット出力に変換します - フィラーを削除、文を再構成、フォーマット化ルールを適用、対象コンテキストに登録を調整。
エンリッチメント段階 「um」 と「uh」 の単純な検索置換ではありません。本当の言語理解を実際に出力を生成して、考える人が書いた場合の流産。
説明されている6つのエンリッチメント モード
生のトランスクリプション
最も単純なモード: 最小後処理、Whisper生成に閉じる出力。あなたが正確なトランスクリプト必要な場合に有用 - あなたが望む何かを引用、正確な言葉記録、特定フレーズング保護。
入力: 「uh の主な問題は、uh、3倍通常エラーレート見ている支払いエンドポイント昨日周辺2 pm から」
出力: 「主な問題は、3倍通常エラーレート見ている支払いエンドポイント昨日午後2時周辺。」
生のモード以下でも、基本クリーンアップ(大文字小文字、一貫した数値フォーマット)。
クリーン&コレクト
毎日の労働馬モード。不流暢(um、uh、like、あなた知っている)を削除、文法を修正、適切な句読点を追加、クリーン散文出力を読むことのようにシングル化テキストをタイプ注意深く。これはコンテキストのためのなシーク、デフォルト: Slackメッセージ、カジュアルメール、ノート、ドキュメント。
入力: 「そう基本的に何を言おう、um、認証に現在アプローチだ、いいえのように、スケール問題が発生しているため、セッションテーブルを使用しており、あの、uh、ボトルネック」になります
出力: 「認証スケールの現在のアプローチは問題が発生します。認証状態セッションテーブルを使用しており、これがボトルネックになります。」
エンリッチメントはフィラーを削除するだけ超えて注意 - それは考えを2つの明確な文に再構成。
プロフェッショナルメール
話された内容を件名行、挨拶、本文、閉鎖付きの完全なメール変換。トーン職業で自然であるに変更。ビジネス通信では、実質指示をAIに処理フォーマット。
入力: 「ねえあなたがJake伝えることができますか 、Jakeサーバマイグレーション計画を終わり週から必要だと、また、セキュリティ監査のリマインド 15日はスケジュール、彼のチーム準備を尋ねますか?」
出力:
件名: サーバーマイグレーション計画とセキュリティ監査アップデート
こんにちはJake、
このウィークの終わりまでサーバーマイグレーション計画を送信してもらえますか? 15日に予定されているセキュリティ監査について確認したいので - あなたのチームが準備されていますか?
ありがとうございます。
会議ノート
話されたコンテンツを標準会議ノート フォーマット構造化: 決定、アクション アイテム、コンテキスト、ステップ。会議直後のサマリーのために設計。
入力: 「本日の製品会議、Q3でモバイル起動をスケジュール決定を通り。Tomロードマップアップデートしており、法律レビュー新しい用語が起動前に必要、Sarahが所有しているそれを、1週間でチェック」
出力:
決定
- Q3へモバイル起動スケジュール変更
アクションアイテム
- Tom: 製品ロードマップ更新 - 進行中
- Sarah: 起動前に新しい用語のの法律レビューを開始
次のチェック イン
- 1週間
2-3文サマリー
より長いスピーチを緊密な2 ~3文サマリーに凝縮。エグゼクティブサマリー、ステータス更新、多く情報が必要をコンパクトステートメント必要な場合に有用。
入力: [3分間話プロジェクト状態、背景、ブロッカー、計画された解決策、予期されるタイムラインをカバーする説明]
出力: 「プロジェクト現在は第三者プロバイダーからのAPI アクセスで、統合を2週間約延期をブロック。チーム開発を継続するマック API レイヤーを実装しています。完全統合は月の終わりで予想される。」
開発タスク
話されたコンテンツをコンテキスト、要件、受け入れ条件を持つ開発タスク構造化。出力はGitHubの問題、Linear タスク、およびJira チケットのための一般的なフォーマット一致。
入力: 「APIにレート制限を追加する必要があります、今エンドポイントハンマー誰かだけからの保護がないため、1分あたりユーザー 100リクエスト制限する必要があります、超過時に429 を返す、実装のためのRedisを使用」
出力:
タスク: APIレート制限追加
コンテキスト APIには現在のエンドポイント乱用への脆弱性残し、レート制限がありません。
要件
- 各認証ユーザーを1分あたり100リクエストに制限
- 制限を超えたときHTTP 429(多すぎるリクエスト)を返す
- レート カウンタ実装のためのRedisを使用
受け入れ条件
- [ ] ユーザー1分100リクエストで強制されるレート制限
- [ ] 429応答が適切なヘッダー付き返される
- [ ] Redis カウンター 1分後に正しくリセット
エンリッチメント実装されているところ
エンリッチメント段階 は、各モードのための慎重に設計されたシステムプロンプト、言語モデルを使用。プロンプト は role定義(「あなたはプロフェッショナルテキストエディタです」)、タスク(「以下の生スピーチトランスクリプションをプロフェッショナルメール変換」)、ルール(「フィラー単語削除、文法を修正、件名行と挨拶を追加」)、期待される出力フォーマット。
生のWhisper トランスクリプト が、その後、ユーザーメッセージとして追加。LLM は、単一推論パス フォーマット済み出力を生成。
このアーキテクチャ がなぜエンリッチメント が、合計レイテンシに約1秒のみ追加 - よいプロンプト LLM 効率的なモデル上推論は速い。
正しいモードを選択
正しいモード書いているのは、コンテキスト に依存:
- いずれかの一般的なテキスト、Slack、ノート: クリーンモード
- プロフェッショナル コンテキストでのメール: メールモード
- 会議直後のドキュメンテーション: 会議ノート モード
- ステータス更新、TLDR、抄録: サマリーモード
- GitHub 問題、Linear、Jira タスク: 開発タスク モード
- カスタムワークフロー: 独自のシステム プロンプトを持つカスタムモード
Telvrでモード切り替え、モード セレクタをクリック。ユーザーが一貫した主な使用例、最後で選択したモードはセッション間で持続し、あなたがそれを再選択する必要はありません。
エンリッチメント対シンプルクリーンアップ
「エンリッチメント」と「クリーンアップ」間の区別は要件。シンプル クリーンアップツール フィラー単語削除と大文字小文字修正 - 相対的に機械操作任意のテキスト処理スクリプトが近い。
本当のエンリッチメント 言語理解を適用。明確性のために文を再構成、だけでなく，正確性。流れに識別し、アクションアイテム 形式化フォーマット 所有者とのこと。「私は...について尋ねることが書かれたり」 をプロ登録で「I would like to inquiry about...」に変換。
その差は出力で見られるのは: 機械的にクリーンテキストが除去されたつ読むらしいスピーチ。エンリッチュされたテキストは誰かが人が書いたものを読む。