ChronometricaとTopaz Sharinganの比較：YouTubeの文字起こしレコードがない場合の対処法

アプリで説明する必要がある処理結果から選ぶ

Actorは、ホスト環境で動くデータ収集プログラムです。アプリはActorに入力を渡し、実行して、その結果を読み取ります。結果仕様は、アプリが受け取るデータの内容を定めます。

文字起こしの抽出では、成功時の結果は仕様の一部にすぎません。文字起こしを取得できなかった入力の扱いも決める必要があります。このルールは、ユーザーに表示するメッセージと、アプリが次に実行する処理に影響します。

開発者による公開の質問では、ローカル環境では成功したのに本番環境では失敗すること、リクエストのブロック、空の結果、再試行時の動作が不明確なことが報告されています。この質問は、別のPython文字起こしライブラリに関するものです。処理結果を理解できることが重要な理由を示しています。ただし、ここで比較するどちらのActorについても、試験の証拠にはなりません。

まず、ユーザーへの対応に必要な判断を確認しましょう。

出典：Chronometricaの結果仕様、Topaz Sharinganの結果仕様。

すべての要件を満たすなら、単純な仕様を選びましょう。アプリで処理結果を区別し、それに応じて動作する必要があるなら、詳細な仕様を選びましょう。こうすれば、アプリに必要な動作を基準に選べます。どちらのサービスが失敗しにくいかという、裏付けのない主張に頼らずに判断できます。

Chronometricaの成功レコードと失敗詳細を併せて確認する

Chronometricaは、取得に成功した重複のないYouTube動画を、デフォルトのデータセットの各行に1件ずつ格納します。データセットとは、これらの結果レコードの集まりです。失敗した入力は、成功したデータセット行にはなりません。課金対象の文字起こし行にもなりません。別に提供される`OUTPUT`の概要は、実行情報を報告します。ここには`failedInputDetails`が含まれることがあります。Chronometricaの仕様。

データセットの件数が少ないときは、この区別が重要です。入力リストよりもレコード数が少ないデータセットは、すべての入力が成功したことを示しません。そこにあるのは、取得に成功した文字起こしレコードです。レコードが生成されなかった入力についても、報告された処理結果を確認する必要があります。

`includeFailedInputDetails`は`true`のままにしてください。仕様に記載された失敗詳細には、安全に扱える入力識別情報、`errorCategory`、`errorCode`、`isRetryable`が含まれます。カテゴリは失敗を種類ごとに分類します。コードは、より具体的な機械可読の値を示します。再試行フラグは、報告された失敗が再試行可能かどうかを示します。Chronometricaの入力スキーマ、結果仕様。

アプリはこれらの詳細を使って、送信したすべての入力を一覧にまとめられます。成功した文字起こし、または失敗した入力の詳細を、該当する入力識別情報に対応付けてください。リスト内の位置でレコードを対応付けないでください。成功行が1つでも欠けると、位置による入力と結果の対応付けは安全ではなくなります。

取得元が返した結果と、アプリの表示メッセージを分けてください。結果には、取得処理が報告した内容を記録します。表示メッセージは、その結果をユーザーに説明します。こうすれば、保存した観測結果を変えずに、表示文を変更できます。

必要な言語の字幕を取得できるかどうかは別に判断する

どちらの処理手順を実行する場合も、まず、アプリが特定の言語の字幕を必要とするかどうかを決めてください。利用可能な文字起こしと判断するには、テキストがあるだけでなく、この言語要件も満たす必要があります。

Chronometricaの`preferredLanguages`は、値を指定すると厳密に適用されます。要求された言語の字幕がない場合、Actorは別の言語を黙って選ばず、`LANGUAGE_UNAVAILABLE`を返します。この設定は字幕を翻訳しません。ChronometricaはYouTube上の既存の公開字幕を読み取ります。音声認識で文字起こしを新たに生成する代替処理はありません。Chronometricaの仕様、入力スキーマ。

この動作は、ユーザーが要求した言語の字幕を必ず提供する必要があるアプリに適しています。同時に、明確な制約もあります。別の言語の字幕がある動画でも、アプリの要件を満たせない場合があります。

何らかの字幕テキストがあるという理由だけで、この結果を文字起こしの取得成功として扱わないでください。要求された言語を入力レコードと一緒に保存してください。そうすれば、要求を満たす字幕が見つからなかったとアプリで説明できます。

ユーザーが別の言語でもよい場合は、処理手順を拡張する前に、その選択をアプリで定義してください。言語要件の変更は、リクエストの変更です。元のリクエストの再試行とは区別してください。字幕の取得可否について詳しくは、YouTube字幕抽出ガイドを参照してください。

レコードがない場合を架空の例で確認する

以下は架空の例です。実際の実行結果、ベンチマーク、顧客の結果ではありません。

アプリが、字幕の言語を指定して、重複のない8件の動画IDを送信します。5件の動画には利用可能な字幕があります。1件には公開字幕がありません。1件には要求された言語の字幕がありません。1件ではアクセスに失敗し、返されたフラグは再試行可能であることを示しています。

この架空の入力セットで、利用可能な字幕がある割合は次のとおりです。

`5 / 8 × 100 = 62.5%`

この計算が示すのは、この架空の入力セットだけです。どちらのActorの実際の成功率を推定するものでもありません。

Chronometricaの文書に記載された結果構造に従うと、アプリは成功した文字起こし行を5件、失敗した入力の詳細を3件読み取ります。成功した文字起こしのデータセットに、失敗行を3件作って追加するわけではありません。アプリはその後、文字起こしレコードを5件、未解決の処理結果を3件表示できます。Chronometricaの結果仕様。

未解決の処理結果には、それぞれ異なるメッセージが必要です。アプリは、1件では公開字幕が見つからなかったと説明できます。別の1件では、要求された言語の字幕が見つからなかったと説明できます。アクセスの失敗については、返されたフラグを根拠に、回数を制限した再試行を予定していると伝えられます。

再試行キューに入れるのは、フラグで再試行可能とされたケースだけです。成功したデータセット行がないすべての入力を再試行するわけではありません。再試行可能のフラグは、もう1度試す判断の根拠になります。ただし、その試行の成功を保証するものではありません。

後でその入力を再試行した場合、アプリは新しい結果を記録します。最初の観測結果も残します。これにより、各試行で何が起きたかを記録で確認できます。

この例を使うと、判断ルールを実際の用途に当てはめて確認できます。アプリにこれらの個別メッセージと再試行キューが必要なら、詳細な仕様を選びましょう。要件のすべてが、nullを許容する文字起こし値で満たされるなら、単純な仕様で十分な場合があります。

少数の入力で結果仕様を確認する

少数の入力で確認すると、入力数を増やす前に、アプリが仕様どおりのレコードを読み取れるかを確かめられます。この確認で本番環境の信頼性を立証できるわけではありません。

以下のJSONは、公開仕様に記載された入力フィールドを使っています。URLは入力形式を示すためのものです。現在の字幕の内容や、特定の結果を保証するものではありません。用途に合う公開ソースに置き換えてください。

{
  "startUrls": [
    "https://www.youtube.com/watch?v=dQw4w9WgXcQ"
  ],
  "includeFailedInputDetails": true
}

各フィールドはChronometricaの入力スキーマに記載されています。公開Taskの例も、処理を始める際の参考になります。Taskとは、保存済みの入力設定です。スキーマの例もTaskのリンクも、このガイドのために実行を完了した証拠ではありません。

次の短い手順で、処理の流れを確認してください。

1. 入力と受け入れ条件を定義します。重複のない動画リストを作成します。必要な言語があれば記録します。どのような字幕テキストを利用可能とするかを決めます。利用可能な文字起こしが返されなかった場合に、アプリで何を表示するかも決めます。
2. 失敗詳細を有効にしたままにします。`includeFailedInputDetails`を`true`に設定し、少数の公開入力を送信します。アプリが成功したデータセットと、別に提供される`OUTPUT`の結果を読み取れることを確認します。
3. 処理結果を入力に対応付けます。仕様に記載された入力識別情報を使い、結果をリクエストに結び付けます。成功レコードと失敗した入力の詳細を照合します。件数の少ないデータセットだけで、送信したリストの全結果を把握できるとは考えないでください。
4. 失敗時の判断を確認します。返された失敗フィールドを読みます。字幕の取得可否に関する結果と、明示的に再試行可能とされたケースを分けます。文字起こしがないという理由だけで、再試行してよいと判断しないでください。
5. 上限のある再試行ルールを適用します。アプリで試行回数の上限を設定します。対象となるケースだけを再試行します。各試行の観測結果を残し、上限に達したら停止します。
6. 最終状態を正確に表示します。再試行が終わっても文字起こしを取得できなかった場合、その入力を未解決のままにします。欠落したテキストを空の成功レコードに置き換えたり、もう1度試せば取得できるかのように示したりしないでください。

アプリが読み取った内容に、ある入力に対応する成功レコードも失敗詳細もない場合は、その不確実性を残してください。実行情報と、結果を読み取るコードを確認してください。件数を合わせるために結果を作り出してはいけません。

受け取ったレコードの状態をアプリで把握でき、意図したユーザー向けの判断ができれば、この確認は成功です。結果の読み取り方法が機能することを確かめるために、送信したすべての動画から文字起こしを取得する必要はありません。

入力数を増やす前に再試行の上限を決める

再試行キューとは、アプリが再送信する予定の入力のリストです。ここでの目的は限定的です。対象となる失敗した入力に、回数を制限して再度試す機会を与え、明確な記録を残します。

リストを拡大する前に、試行回数の上限を決めてください。上限がないと、何度試しても成功しない場合でも、再試行可能な失敗が繰り返し処理され続けることがあります。停止条件を明確にすれば、自動試行が終了した時点をアプリからユーザーに伝えられます。

送信した入力、その言語要件、観測された処理結果、試行順序をアプリの記録に残してください。これらは、アプリ側で選んで記録する項目です。Actorに追加の出力フィールドがあると主張するものではありません。これらの記録により、元のリクエストと、その後の試行や変更されたリクエストを区別できます。

欠損値をそのまま保持してください。不明な値は、不明のままにする必要があります。欠損値を0に置き換えたり、空の文字起こしを成功の証拠として使ったりしないでください。アプリでは、受信したテキスト、報告された失敗、まだ確定していない処理結果を区別できるようにしてください。

字幕の取得可否による失敗は、その時点のリクエストに対する観測結果として扱ってください。正確な記録を残すために、自動で再試行する必要はありません。後でユーザーが要求する言語を変えたり、新たな確認を求めたりした場合は、新しいリクエストまたは観測結果として保存してください。

これらのルールにより、アプリの動作を説明できるようになります。再試行すれば字幕を取得できるという主張には依存しません。

アプリの要件からActorを選ぶ

文字起こしがない場合に、その結果を説明する必要があるなら、Chronometricaは有力な選択肢です。確認した失敗フィールドは、入力との対応付け、個別のユーザーメッセージ、回数を制限した再試行の判断に使えます。これが、取得に失敗した入力の状態を把握する必要があるアプリにChronometricaを勧める具体的な理由です。Chronometricaの仕様。

主な制約は、字幕を取得できるかどうかです。詳しい失敗記録は、取得処理で利用可能なテキストが得られなかった理由を説明します。字幕を作成したり、翻訳したり、音声認識による代替の文字起こしを提供したりするものではありません。

仕様に記載された、文字起こしまたはnullという結果でアプリの要件を満たすなら、Topaz Sharinganを選びましょう。入力スキーマには`startUrls`と`timestamps`が含まれています。nullという結果は、明示された仕様の一部です。不具合の証拠ではありません。Topaz Sharinganの仕様、入力スキーマ。

どちらがより安定しているかが決め手になる場合、この比較だけでは選べません。確認した資料には、同条件での性能比較試験がありません。エラー記録が詳しいことを、成功率が高い証拠として扱わないでください。この不確実性も含めて判断してください。