Poolside: Laguna S 2.1 (free)

Poolside Laguna S 2.1は、エージェント型コーディングと長期にわたる作業のために設計された、Mixture-of-Experts言語モデルです。総パラメータ数は118B、トークンごとのアクティブパラメータ数は約8Bで、メーカーのシリーズの中では、小型のLaguna XS 2.1と大型のLaguna M.1の中間に位置します。ツールに接続したアプリでテキストを処理し、テキスト、コード、推論、ツール呼び出しリクエストを生成します。

アーキテクチャは、48層にわたってグローバルアテンションとスライディングウィンドウアテンションを組み合わせています。内訳はグローバル層12、スライディングウィンドウ層36です。512トークンのスライディングウィンドウはそれらの層内のローカルアテンションを表し、記載されているモデルコンテキストは1,048,576トークンです。この2つは異なる測定値です。大きなコンテキストは、多数の手順にわたってソースファイル、観察、決定が蓄積されるタスクに対応します。作業目標と意味のある根拠を一緒に保持し、適用される構成内で、後続の推論と最終応答の余地を確保してください。

モデルの中心的な用途は、粘り強い継続、確認、修正を必要とするソフトウェア作業です。リポジトリのタスクでは、期待する動作、関連ファイルのテキスト、依存関係の情報、実際の失敗出力を提示してください。「このリグレッションの原因をたどり、文書化されたインターフェースを維持する変更を提案し、修正を無関係な変更と区別できるチェックを挙げてください」のように、焦点を絞った結果を求めます。ツールに接続したワークフローでは、次の手順を選ぶ前に、実行した各チェックの結果をモデルに渡してください。

最適化の作業では、測定値と明確な目標を提示してください。たとえば、「このプロファイルとメモリ割り当て報告を使って、ボトルネックを特定してください。変更を1つ提案し、期待する効果を説明し、同じ測定を繰り返した後で基準値と比較してください」と依頼できます。これにより、性能に関する主張を確認できるようになります。Poolsideのリリースは、検証と進行の継続を重要な動作として取り上げていますが、説得力のある説明だけでは、修正が高速、正確、完了済みであることは確認できません。変更を採用するか退けるかの根拠となる観察を保持してください。

Laguna S 2.1は、ツール呼び出しの前や呼び出しの間に思考を挟むことに対応しています。メーカーは、以前のアシスタントメッセージの推論内容を後続の履歴に保持することを推奨しています。それらのブロックを落とすと、後続の手順で推論が停止する場合があります。アシスタントの応答、ツール呼び出し情報、対応するツール結果をひとまとまりに保持してください。これにより、以前に試したことを繰り返し組み立て直すのではなく、実際の状態から長いタスクを継続しやすくなります。

記載されている思考の選択肢はoffとmaxで、メーカーが説明する設定ではmaxが既定で有効です。そのモードではモデルが思考予算を決めます。リリースでは、low、medium、highという個別の推論労力制御は示されていません。エージェント型コーディングでは、Poolsideは思考を有効にし、手順の間で保持することを推奨しています。最終成果物と完了条件を明示し、長い推論の流れと完成した結果を区別してください。メーカーは、特に競技数学で思考が長引きすぎることを、実質的な制限として挙げています。

ツールの定義には特に注意が必要です。Poolsideは、S 2.1が、似ていても異なるスキーマを厳密に追う代わりに、最初は慣れたツールインターフェースに依存する場合があると報告しています。ツール引数に入れ子の配列があると、不正な形式や誤ったエスケープのJSONを生成することもあります。実際の引数定義を渡し、提案された呼び出しを検証し、一致しない場合は正確なエラーを返してください。メーカーは、こうした不一致の一部を解決する方法として、コンテキスト内のフィードバックによる修正を説明しています。その結果のツール観察を、次の判断に使えるよう保持します。

メーカーは、BF16と量子化された各バリアントを個別に公開し、任意のDFlashドラフトモデルも提供しています。これらは異なる成果物と配信手順であるため、量子化されたチェックポイントのメモリ使用量や投機的デコーディングの性能を、一般的なモデル名から想定するべきではありません。通常のテキスト作業では、ソースコード、コマンド出力、文書の抜粋を、読み取れるテキストとして用意してください。リリースは、このモデルが視覚能力を持たないことを記載しています。スクリーンショットを分析の根拠にするには、文章による観察か、適切な外部確認の手順が必要です。

変更した成果物、重要な決定、観察されたチェック、未解決の条件を示す最終成果物を求めてください。コードレビューでは、所見を関連するソースに結び付け、各問題が動作に影響する理由を示します。修正では、パッチの提案と、動作を実際に確認したパッチを分けてください。推論とツール履歴の保持はモデルがタスクを進める助けになり、最終成果物と記録された結果が、何を達成したかを示します。