アーキテクチャ¶
ワークスペースでは、cognoxium-core、PyO3拡張、型付きPythonファサードを分離しています。
Python application
|
v
typed Python API and immutable planner
| |
| +--> gettext diagnostics and renderers
v
PyO3 extension (binary wheel)
|
v
Rust core: Arrow schema, hashing, native tokenizers, DataFusion session
現在の実行境界¶
Rustは、正規のArrowスキーマ、ペイロードの列挙型、診断情報の構造、拡張トレイト、ハッシュ計算、トークン化、およびプロセス内DataFusionセッションを定義します。バイナリwheelは、ハッシュ計算とバッチトークン化をPythonへ公開します。
v0.1系列のPythonファサードは、イミュータブルなPythonプランナーでフレーム変換を実装しています。このプランをDataFusionへ変換するわけではありません。現在の性能に関する説明を評価する際には、この違いが重要です。パフォーマンスを参照してください。
Pythonは、レコードを扱いやすくする機能、プランニング、プラグインプロトコル、ローカライズされた診断、パッキング、マニフェスト、プロバイダー形式のレンダラーを担当します。Pythonトークナイザーのコールバックは、明示的に低速な代替手段です。
依存関係の境界¶
コアには、ネットワーククライアント、モデル呼び出し、APIキー処理、アカウント要件、テレメトリがありません。プロバイダーやフレームワークへの依存は、ホストアプリケーションまたは明示的なプラグイン側で管理します。
プラグインのフィンガープリントは再現性を構成する要素ですが、プラグインが宣言したフィンガープリントが外部モデルやサービスの状態を正確に表しているかを、Cognoxiumが検証することはできません。
拡張の方向性¶
ペイロード構造体には、Text、JSON、Binary、Reference用のnullableな子フィールドがあらかじめ確保されています。そのため、将来のレンダラーやトークンプロファイルも、既存のトップレベルのペイロード構造を利用できます。これは拡張を見据えたアーキテクチャ上の設計であり、v0.1系列でマルチモーダルパッキングが利用できるという約束ではありません。拘束力のない現状と拘束力を持たないロードマップを参照してください。