アカウントモデル

Glossia はリポジトリの指示とモデルプロバイダーの認証情報を分離します。リポジトリは翻訳すべき内容を記述し、アカウントはどの 大規模言語モデル が作業を実行するかを決定します。

## アカウントにモデルが含まれる理由

チームは同じプロバイダー関係を持つ複数のリポジトリを翻訳することがよくあります。アカウントスコープのモデルは管理者がプロバイダーキーをローテーションしたり、すべてのリポジトリを編集せずに基底モデルを一度だけ切り替えることを可能にします。

この境界はまた、認証情報をソースコントロールから外します。リポジトリにはプロバイダーキーではなく、translation-default のような読みやすいハンドルが含まれます。

## ハンドルは安定した意図を提供します

L10N.md の model フィールドはアカウントモデルハンドルの参照を示します:

model: translation-default

このハンドルはリポジトリの意図を表します。管理者はリポジトリの構成を安定したまま、後でそのハンドルが選択するプロバイダーモデルを更新することができます。

## 複数のモデルの使用方法

Glossia は各ドキュメントの翻訳に構成済みの 生成 モデルを 1 つ使用します。複数のモデルを追加してもアンサンブル、フェイルバックチェーン、または自動品質ティアは作成されません。リポジトリの著者は translation-default, long-form, または japanese-specialist のような安定したハンドルを通じて目的を選択します。

選択はドキュメントおよびターゲットロケールのコンテキスト階層に従います:

1. L10N/<locale>.md が model を宣言する最も近いファイルは、そのロケールにおいて優先されます。
2. そうでない場合、L10N.md で model を宣言する最も近いファイルは、そのディレクトリにおいて優先されます。
3. より近いファイルがモデルを宣言していない場合、親 L10N.md の設定は継承されます。
4. 適用可能なコンテキストファイルがハンドルを宣言しない場合、Glossia はアカウントのデフォルト生成モデルを使用します。

明示的に構成されたハンドルが存在する必要があります。不明なハンドルには、Glossia はアカウントのデフォルトに対して沈黙して切り替えるのではなく、エラーをレポートします。

## デフォルトの選択

プロジェクトのセットアップには、リポジトリが独自の L10N.md を持つ前にモデルが必要です。したがって、Glossia はアカウントのデフォルトを選択します。各 カテゴリ に最初に加えたモデルはそれのカテゴリのデフォルトとなり、管理者は設定ページから別のモデルをデフォルトに変更できます。

リポジトリが L10N.md を持っていると、明示的なハンドルを使用するだけで、その選択がレビュー者に明確になります。 model を省略すると、リポジトリはアカウントのデフォルトのままになります。

## 生成モデルと判断モデル

モデル構成には 2 つのカテゴリがあります:

• 生成 モデルは翻訳を作成し、プロジェクトのセットアップを支援します。リポジトリモデルハンドルとロケールルーティングルールはこのカテゴリのみを選択します。
• 判断 モデルは翻訳を固定された品質ルーブリックに対して評価します。アカウントに判断モデルがある場合、そのデフォルト判断モデルは構造的検証後、コンテンツエンドポイントからの完全な、単一ドキュメントの翻訳をそれぞれチェックします。フラグメントリクエストは生成プリミティブであり、リポジトリ実行は組み立てられた出力を評価します。

カテゴリには独立したデフォルトが設定されています。Jev を追加しても、翻訳を作成するモデルは変更されません。最初の判断モデルは、後の翻訳実行を評価できるようにします；最後のものを削除すると、評価は無効になります。判断モデルを持たないアカウントは、既存の動作を維持します。

Glossia は現在、TypeSafe Jev を判断プロバイダーとしてサポートしています。Jev は文章ではなく、与えられた選択とスコアを返します。Glossia は弱点の選択を修正ヒントに変換し、位置指定された、または独立して検証されたエラーとしてそれらを提示することなく行います。

## 品質チェックと改訂

評価者はソース、翻訳、ターゲットロケール、コンテンツ形式、プロジェクト指示、および解決された組織のコンテキストを受け取ります。意味の保存、完全性、用語、流暢さ、ドキュメントの整合性、目的とオーディエンスの適合、およびロケールの適切さを評価します。声調と文体は、声調やプロジェクト、またはドキュメントガイダンスが利用可能な場合に評価されます。

各要素は設定された最小スコアに達する必要があります。これは 10 点満点の 7 点にデフォルト設定されています。主要なまたは重大なエラーは、スコアに関係なく常に修正を要求します。確信度はライブ評価イベントに含まれ、受容性を変更しません。これらのイベントは現在、ダッシュボードに保持されたり表示されたりしていません。配点ベースのスコアは 10 を必要とし、通常は厳しすぎます。

失敗した要素は、その前に定義された修正ヒントを次の翻訳試みに提供します。リポジトリの既存の retries 設定はこれらの改訂を制限し、コンテンツエンドポイントは 0 から 3 までの retries フィールドを使用して 3 回の修正リトライを可能にします。完全な改訂ドキュメントは、受け入れられる前に、構造的チェックと品質評価を再度パスします。

一過性のプロバイダー失敗は高膨張バックオフで最大 3 回まで再試行されます；無効な認証情報と誤った応答は即座に失敗します。枯渇したプロバイダー失敗はファイルの翻訳を停止し、チェックされていない出力は決して受け入れられません。評価は完全なドキュメントを使用し、大きな入力入力は省略されるのではなく拒否されます。シリアル化された入力は、ステートと最も長い質問に対して 30,000 バイト、そして完全リクエスト全体で 60,000 バイトに保守的に制限され、Jev のコンテキスト限界 の内にとどまります。自動化されたスコアはモデル判断であり、依然としてバイリンガルの人間レビューに対する較正を必要とします。

評価者の構成と ルーブリック versões は翻訳ロックファイルに参加します。評価の有効化、モデルまたは閾値の変更、または評価の削除は、前の翻訳が次の実行において古くходу をします。プロバイダーキーはロックファイルから除外されます。

## ヒューマンレビューの境界

モデル出力は提案された作業であり、自動マージではありません。セットアップと翻訳の活動は Glossia で表示され続けますが、リポジトリの変更はチームのレビューするためのプルリクエストを通じて公開されます。これは、チームがすでにコードに対して使用している品質と所有権の境界を保持します。