typesafe-ai

TypeSafe で構築する

TypeSafe を使うと、AI の知能をプログラミングのプリミティブのように利用できます。小さな判断を組み合わせて、より大きな機能を構築できます。System One models は、ソフトウェアが直接利用できる、素早く焦点を絞った判断を返します。Jev は、TypeSafe を代表する最初の System One モデルです。自然言語を理解し、テキストや推論の説明を生成するのではなく、型付きの回答と確率を返します。ワークフローはコードが管理し、モデルは通常のコードでは意味理解が必要になる場面で、プログラムから利用できる常識を提供します。

最新のドキュメントを読む

最新の TypeSafe ドキュメントが正式な情報源です。タスクの一環として必ずお読みください。 このスキルでは方向性を示し、ドキュメントでは現在の概念、プロンプトの指針、API の仕様、SDK の使い方、モデル、制限、実例を説明しています。

• 関連するページやクックブックを見つけるために、まずドキュメントのインデックスを確認してください。サイト全体を読み込むのではなく、必要な箇所を選んで読みましょう。
• Mintlify では、ページのパスに .md を追加すると Markdown 形式で取得できます。たとえば、TypeSafe での構築方法を参照してください。インデックス内のリンクをたどり、必要に応じて拡張子のないドキュメントページへのリンクに .md を追加してください。相対リンクは https://docs.typesafe.ai を基準に解決してください。
• 統合を実装する前に、現在の API または選択した SDK のページと、設計に関連する質問のガイダンスを読んでください。新しいワークフローを作成する場合は、最も近いクックブックも確認してください。一般的な分類器より優れた分解方法が示されていることがよくあります。
• インデックスを利用できない場合は、以下の直接リンクまたはサイトのナビゲーションを使用してください。Markdown の取得に失敗した場合は、通常のページを試してください。最新情報にアクセスできない場合は、利用可能なローカルドキュメントまたはインストール済み SDK の型を参照し、その制限を明記したうえで、バージョンに依存する詳細を推測しないでください。

タスク	まず確認するものと関連する詳細
プログラミングモデルを理解する	System One、構築ガイド
構築できるものを探す	ユースケースマップ、続いてインデックスから関連するクックブック
入力と質問を準備する	状態、プリミティブ、続いて選択したプリミティブのページ
不確実性への対処方法を決める	信頼度
API コードを書く	HTTP API、Python SDK、または JavaScript SDK
古い統合を更新する	移行ガイドとインストール済み SDK の最新リファレンス

有用な形を見つける

ユーザーが求める動作から始めましょう。アプリケーションには何を表示し、選択し、変更し、引き渡す必要があるでしょうか。それを実現するために必要な判断を逆算します。既知のルール、計算、正確な検索、実行はコードに任せます。ユーザーが選んだスタックと範囲を尊重し、意味の理解が役立つ場合は TypeSafe を追加します。

アイデアを出したりアーキテクチャを選んだりするときは、分類だけでなく、ほかの方法も検討してください。以下のパターンは出発点です。確立されたレシピに当てはまらないアイデアも含め、ユーザーの目標に合わせてプリミティブを組み合わせましょう。

• 既知の引数に振り分けて値を設定する。 リクエストに応じてハンドラーとその型付きパラメーターを選択できます。分岐ごとに役立つ質問を最初に行い、関連する回答だけを利用します。関数呼び出しと投機的ファンアウトをご覧ください。
• 生成するのではなく、選択する。 コード内で候補値やソースの範囲を見つけ、判断によって意図されたものを選んでから、コピーまたは正規化します。コードを使ってソーステキストを組み立て、書式設定されたドキュメントや読書ガイドを作成することもできます。値の抽出と構造の復元をご覧ください。
• 証拠を探して評価する。 候補を取得し、クエリとの関連性を比較して、役立つコンテキストを選択します。再ランキングと階層的分類をご覧ください。
• 判断を再利用可能なデータに変える。 各次元を一度スコアリングし、コードやユーザーのコントロールで重み、しきい値、ランキング、表示を変更できるようにします。ラベル付きの結果があれば、これらのシグナルを従来型の ML 特徴量にできます。複合スコアリングと特徴量の発見をご覧ください。
• 検証してエスカレーションする。 特定の主張やフィールドを証拠と照合して確認し、不確実なケースや失敗したケースは、人または推論モデルに送ります。引用の確認と抽出カスケードをご覧ください。
• 変化する状態に対応する。 コードで目標と観測結果を保持し、最新の判断に基づいて次の範囲を限定したステップを決められます。推定された状態と観測された事実を区別し、状況が変わった場合は結果を適用する前に、その情報が最新かどうかを確認します。

自由度の高いリクエストには、ユーザーの目標に最も合う方向をいくつか提示し、出発点を提案しましょう。具体的なリクエストには、関連するパターンを選んで実装します。ブレインストーミングを必須の寄り道にする必要はありません。

判定を設計する

回答の意味に基づいて選び、該当するプリミティブのページを読んでください。

必要な内容	プリミティブ	重要な違い
定義済みの選択肢から1つ	Choice	1つの選択肢を選びます。分布は競合する選択肢を比較します
条件が成立するかどうか	Noul	「はい」の確率です。別個の信頼度はありません。複数のラベルが該当する可能性がある場合は、ラベルごとに1つずつ使います
説明された次元に沿った度合い	Score	確率で重み付けされた順序レベル上の位置です。段階的な順位付けには、項目ごとに比較可能なScoreを使います

回答に十分な関連状態（ソーステキスト、識別情報、関係性、ポリシー、現在の事実など）を各質問に含めてください。コンテキストに複数の要素がある場合は、名前付きのJSONフィールドを優先してください。判定はinstructionsに記述し、可能な回答はcriteriaで定義してください。質問IDはコードで使うもので、モデルには送信されません。質問には意味をすべて含めてください。ticket.messages[0].textのように、バッククォートで囲んだパスを使ってネストされた状態を参照してください。

各質問では、範囲を絞った一貫性のある判定を1つ求めてください。独立して役立つ次元は、判定対象の関係性を損なわないように分けてください。範囲を限定したアクションの選択や、コンテキストに応じた解釈も有効です。アトミックにすることは、文字どおりの事実抽出や1文に制限することを意味しません。単純な質問には文字列を使えます。定義、対比、除外、例によって指示や条件が明確になる場合は、構造化オブジェクトや配列を使ってください。Scoreのレベルは、具体的な状況を説明し、それぞれ単独で意味が通るようにしてください。

必要な回答を利用できる状態にしておいてください。該当するものがない場合があるなら、一致なしの結果を含めてください。存在判定が独立して役立つ場合は、別の判定として行ってください。ソース値を選択させる場合は、候補が網羅されているか確認してください。モデルは、候補から除外された値を選べません。

構成して検証する

独立した質問は、役立つ推測的な質問も含め、同じ状態に対してまとめて行ってください。質問は並列に実行され、互いの回答を参照できません。推測の前提はそれぞれ明示してください。コードでは、該当する回答を使用します。以前の回答が証拠の取得、新しい状態の構成、または次の選択肢の決定に必要な場合は、2回目のリクエストが妥当です。質問を増やせばトークンも余分に使います。実際のリクエスト予算、コスト、エンドツーエンドのレイテンシを測定してください。

確率と信頼度を行動の指針として使い、しきい値はユーザーのデータと結果を踏まえて評価してください。Choice／Scoreの信頼度は、分布の集中度を示すものであり、ワークフロー全体の正しさや行動の許可を示すものではありません。Noulが0.5に近い場合は、「はい」と「いいえ」の確率が近いことを示し、強度が中程度であることを意味しません。許容できる選択肢が複数ある場合も確率が分散するため、信頼度が低くても、害のない好みの選択を無効にする必要はありません。使われない分岐の不確実性は無視してください。

ポリシーは明示し、判定結果は再利用できる状態にしておいてください。重み付きスコアは、相殺できる選好に適しています。「重大な違反が1つでもあれば」というルールには、個別の条件が必要です。根拠と質問の意味が変わらない場合、重みや表示フィルターの変更に推論を再実行する必要はありません。型付き出力が保証するのはインターフェースであり、真実性ではありません。System Oneモデルは、適切に調整された判定を行うようトレーニングされています。対象ドメインでの性能を検証してください。

代表的なケースと、それに対するアプリケーションの動作をテストしてください。失敗時には、正確な状態、質問、候補、回答、組み合わせ、観測された結果を調べてください。証拠の不足、モデルのエラー、コードのエラー、サービス障害を切り分けてください。クックブックのしきい値やデモ結果は、普遍的なルールやモデルの恒久的な制限ではなく、評価対象となる例として扱ってください。Webアプリでは、API認証情報をサーバー側に保持してください。