Panorama

どの案件も、業務とシステムが実際どう回っているかを描き、何を作る価値があるかを決めることから始まる。Panoramaは、コードを一行も書かず、環境にシステムを立ち上げる前に、何を作る価値があるかを明確にするのが目標だと言う。これで支出が間違った課題へ流れるのを防ぐ。誰も使わないAI機能にすでに予算を燃やしたチームにとって、最初のフェーズこそ本題だ。仕事の中で最も安く正解を出せる部分である。

Panoramaは検索をデモの小技ではなく、計測されたシステムとして扱う。つまりチャンキング、埋め込み、リランキング、ハイブリッド検索を丁寧に処理する。そのうえで評価をつなぎ、劣化に気づけるようにする。狙いは、ノートブックでは問題なく見えたRAGパイプラインが、実際の問い合わせが有料ユーザーの前で来た途端に外すチームだ。

以前のステップを忘れるエージェント、数万トークンまで膨らむプロンプト、間違った詳細に使われるコンテキストウィンドウ。すべてはモデルに何を見せるかに帰着する。Panoramaは各ステップでその入力を設計する。公開されたある事例では、プロンプトが大きすぎてどのフロンティアモデルも受け付けなかった製品を扱った。モデルが見るものを組み直したことで、ようやく動くようになった。本当の制約はコンテキストの生の大きさではなく、信号の密度だった。

推論の請求は利用量より速く膨らみがちで、Panoramaの狙いはその理由を突き止めることだ。チームはトークンの行き先を分析し、ルーティング、キャッシュ、バッチ処理、より小さなモデルでコストを下げる。ある事例では、反復的なタスクを数ドルで学習したオープンモデルへ蒸留した。呼び出しあたりのコストは16分の1になった。これは大きな差だ。請求額が上がっているなら一見の価値がある。

モデルは背後のデータ次第で良くも悪くもなる。そしてほとんどの企業は、形が違うだけで大量に持っている。Panoramaはそのデータを使えるようにするためのパイプライン、学習セット、評価セット、ラベリングの仕組み、ガバナンスを構築する。地味な作業だ。同時に、親切なデモの外でモデルが持ちこたえるかを静かに決める層でもある。

プロンプティングで足りなくなったとき、Panoramaは次の段階を担う。データ整理、学習、評価、デプロイ、継続的な調整だ。プロンプトの微調整を超え、巧妙な言い回しでしかタスクを理解しないモデルではなく、自社のデータとタスクに合わせて形づくられたモデルを必要とするチームの道筋である。プロンプティングだけで行けるのはここまでだ。

チームは最終状態を納品ではなくパートナーシップとして位置づける。エンジニアは作られたものを理解し拡張を続けることが前提で、モデルや要件が変わってもチームは連絡が取れる状態を保つ。これはAIでとりわけ重要だ。基盤モデルは多くのソフトウェアより速く変わり、保守できないシステムは数か月で負債になる。