技術的な側面についての知識がもっとあれば、みんなが似たようなものになってるのは良いことかもしれないね。人間にキッチンから寝室に行くように言ったら、みんな同じように立ち上がって歩くでしょ。誰もカニ歩きなんてしないよね。そうするためには、モデルを何らかの形で制約しないといけないかも。逆に、LLMで何か違うものを求めるなら、プロンプトに少しクリエイティブな言葉を加えるだけでいいんだ。

明らかに異なるモデル間で出力がどれだけ似ているかを見るのはいつも興味深いよね。初期の頃に短編小説の執筆をテストしたとき、GPTやLlama、Phi、Claudeなど、みんな同じニッチなトピックを選んでいたのを覚えてる。

それにしても、ちょっと無意味だよね。コーヒーショップにウェブサイトが必要な理由って何？「このコーヒーショップに行きたいけど、ウェブサイトが見つからない」なんて言ってる人はいないよね。もし「営業時間、住所、簡単なメニュー、写真」が欲しいだけなら、もっと簡単で安い方法があるよ。

Claudeを使って、ウェブサイトのデザインを大幅にリニューアルしようとしたんだけど、結果にはかなり満足したんだ。でも、実際に導入するのは待つことにした。そしたら、同じデザインがカフェに適用されてるのを見つけて、びっくり！これ、偶然とは思えないくらい似てて、Claudeのリニューアル案はお蔵入りにすることにしたよ。

デザインのバックグラウンドがあまりないユーザーでも、AIに「全体の色を変えて、もっと差別化して」ってフォローアップのプロンプトを送ることができるよ。デザイン雑誌やブログからサンプル画像を持ってきて、「ここにあるデザイン要素を取り入れて」って言えば、うまくいくと思う。

これ、結構面白かった。私にとって、GPTのSolとLunaが一番良かった。正直、期待してなかったんだけど。フォントの選び方が大事だね。Opusのはまあまあだけど、ちょっと残念。残りはひどい。

私も同じことを考えてたけど、もっと深い理由があると思う。このページのこの文を見てみて。 > 私たちのデフォルトスキルには、既知の落とし穴を避けるためのUIデザインガイダンスも含まれている（例えば、今や恐れられている紫のAIスロップ）し、モデルがユーザーのリクエストに適したビジュアルアイデンティティについて考えるようにしている。でもそれを超えて、各モデルは自分が必要だと思うものを自由に作ることができるんだ。

これはまさに期待すべきことだと思う。LLMはトレーニングデータに基づいて最も可能性の高い出力を生成するように設計されているから、一般的なデザインタスクを与えると、過去10年のデザインクリシェやトロープの抽出が得られることになるよ。

最近はアドホックな評価を作るのは簡単だよ。君がそれを解決したとは思えない。実際のシナリオに対して適切な評価やベンチマークを書くのは全然簡単じゃない。エージェントのベンチマーキングは、最低限でも以下を固定することを意味する。 - モデル - モデルの設定（努力、権限、プロバイダーなど） - データセット（特定のshaのgitリポジトリなど） - エージェント自体を動かすコード（自分のハーネスを作ることはできるけど、それを一つの実行可能ファイルとして出荷する必要がある。時間を凍結させる必要がある。クローズドソースのランタイム（例えばClaudeコード）に対してベンチマークを取るのは全く意味がない。頻繁に変更されていて、直接検査できない方法で変わるから。） - エージェントが使えるツール。ツールX（例えばgrepやreadfileやsed）の少し異なる実装でも影響がある。一般的に、非常に特定のコンテナイメージを固定することも意味する。私の個人的なベンチマークでは、実行可能ファイルに付属する特定のツールのリストを提供していて、提供されたAPI以外の外部とのやり取りはできない。エージェントは自分のツールをバンドルしている。そしてそれでも、LLMプロバイダーからのノイズがかなりあり、モデルの挙動を顕著に変える。これが設定を最適化したり、時間とともに推論を変えたりするせいなのかはわからない。そして最後に、LLMの出力は非決定的だ。LLMを審査者として使うことも、基本的に同じ非決定的な問題を呈し、徹底的にベンチマークを取る必要がある。質の高いルーブリックや「ゴールデンアンサー/出力」を作るのは難しい。一貫して強調しようとしている指標の一つは、「ショットガンバミットダンプ」の情報を避けること。だから、要点をわかりやすく伝え、専門用語で埋め尽くされた情報のダンプを避ける回答は、違う評価を受ける。要するに、個人的またはプロフェッショナルなプロジェクトからの実世界のエージェント作業をベンチマークするのは全然簡単じゃない。そして、テストケース自体を作るのも難しい。いいえ、「sota」の出力を取ってそれをゴールドスタンダードとして使うことはできない。これは非常にクソなアプローチだ。問題に対する最も雑な解決策で、まさに雑なもの：もっともらしい、平均的で、創造性や独創的な思考が欠けている。複雑なソフトウェア開発で本当の違いを生むもの。これらのベンチマークを作成する目的は、どの設定/モデル/ツール/ハーネス（スキル/mcps/documentation/agents.mdなど）がより良く機能するかを見つけることだ。そして、これは本当に難しい非トリビアルな作業から自分でベンチマークを作成し、実装面でほとんどの指標でより良い解決策を見つける場合にのみ機能する。たとえ一連のケースやエッジケースを解決する実装に落ち着くことができたとしても。

このアプローチの明らかな制限は、最先端のモデルが試みを評価できるタスクに限られることだね。まだ適応できないタスクも多いし、特にグラウンドトゥルースがない場合は比較できない。LLMの審査員に評価させることができるタスクでも、自分でトレースを見てラベリングすることには大きな利点がある。時間はかかるけど、自分の特定のドメインでエージェントが失敗する方法について多くを学べるし、より信頼できるゴールデンデータセットが得られるし、審査員を評価するメカニズムも持てる。コーディングに関してはまだやってないけど（正直、最良のアプローチが分からない）、アプリ内の評価では、トレースをレビューするためのインターフェースを作ったよ。私のアプリは、固定プロンプト、スキーマ、動的コンテキストを含めて、初回リクエストで1万～3万の入力トークンを送信するから、ただレビューするのが大変なんだ。私のインターフェースは、その生の入力データを人間が読みやすいオブジェクトに変換して、重要な点を強調し、リクエストの入力と出力を結びつけてくれる。これでレビューや採点、タグ付けがずっと楽になる。そして、一連のリクエストのバッチを処理した後、合格したリクエストの入力と出力はゴールデンデータセットとして凍結されて、他のモデルに対して実行できるようになる。LLMの審査員は素晴らしくて、入力プロンプト、特定のモデルの応答、（人間が承認した）グラウンドトゥルースを見て、出力とグラウンドトゥルースの間の重要な違いを指摘するのが得意なんだ。実際にグラウンドトゥルースを作るよりずっと簡単だよ。Hamel Husainの評価に関する著作はぜひ読んでみてほしい。