1年間LLMとともに構築して学んだこと

xguru · 2024-06-10T11:16:01+09:00

大規模言語モデル（LLM）を用いた開発は、いま非常に興味深い時期にあるこの1年で、LLMは実用アプリケーションにおいて「十分に良い」水準に達し、毎年より高性能になり、より低コストになっているソーシャルメディア上のデモとあわせて、2025年までにAIへ約2,000億ドルが投資されると見積もられている各社のAPIによりLLMへのアクセスが容易になり、MLエンジニアや研究者だけでなく、誰もが製品にインテリジェンスを組み込めるようになった AIで構築するための参入障壁は下がったが、デモを超えて実際に効果的な製品やシステムを作ることは依然として難しい私たちはこの1年間にわたって構築を続け、その過程で多くの困難を発見してきた私たちの失敗を避け、より速く反復できるように、学んだことを共有したいこの記事は3つのパートで構成される: Tactical（戦術）: プロンプティング、RAG、ワークフローエンジニアリング、評価、モニタリングに関する実践事項 LLMで構築する実務者や週末プロジェクトに取り組む人向けに書かれている Operational（運用）: 製品リリースにおける組織的・日常的な関心事と、効果的なチーム構築の方法持続可能かつ安定的にデプロイしたい製品・技術リーダー向けの内容 Strategic（戦略）: 「PMF前にGPUなし」「モデルではなくシステムに集中する」といった見解を含む、長期的で大局的な視点と反復の方法創業者や経営陣を念頭に置いて書かれているこのガイドは、LLMを使って成功する製品を構築するための実践的な案内書となることを目指している私たち自身の経験に基づいており、業界全体の事例を示している [戦術: LLM利用の核心] このセクションでは、新たに登場しつつあるLLMスタックの中核コンポーネントに関するベストプラクティスを共有する品質と信頼性を高めるためのプロンプティングのコツ、出力を評価するための戦略、グラウンディングを改善するための検索拡張生成のアイデアなどを含むまた、Human-in-the-Loopワークフローをどう設計するかについても掘り下げる予定である戦術1. プロンプティング新しいアプリケーションを開発するときは、まずプロンプティングから始めることを勧めるプロンプティングの重要性は過小評価も過大評価もしやすい適切なプロンプティング技法を正しく使えば非常に大きな成果を得られるため、過小評価されがちである一方で、プロンプトベースのアプリケーションも正しく動かすには、プロンプトの周辺に相当なエンジニアリングが必要になるため、過大評価されがちでもある基本的なプロンプティング技法を最大限活用することに集中するさまざまなモデルやタスクで、継続的に性能向上に役立ついくつかのプロンプティング技法がある N-shotプロンプト + コンテキスト内学習、Chain-of-Thought、関連リソースの提供などである N-shotプロンプトとコンテキスト内学習 N-shotプロンプトによるコンテキスト内学習の考え方は、LLMにタスクを実演し、期待に沿う出力の例をいくつか与えることにある Nが低すぎると、モデルがその特定の例に過度に引きずられ、汎化能力が低下する可能性がある経験的には N ≥ 5 を目標にし、数十件使うこともためらわないこと例は、想定される入力分布を代表しているべきである入出力の完全なペアを与える必要はなく、多くの場合は望ましい出力例だけで十分であるツール利用をサポートするLLMを使う場合、N-shotの例でもエージェントに使ってほしいツールを実際に使うべきである Chain-of-Thought（CoT）プロンプティング CoTプロンプティングでは、LLMが最終回答を返す前に思考過程を説明するよう促すこれは、LLMがすべてをメモリ内だけで処理しなくて済むように、スケッチパッドを与えるものと考えられる元々のアプローチは、単に「段階的に考えてみよう」という文言を指示の一部として加えることだったが、CoTをより具体的にすることが有効だと分かってきた 1〜2文で具体性を加えると、幻覚の発生率が大きく下がる場合が多い最近では、この技法が信じられているほど強力なのかという疑問も提起されているまた、CoTが使われる際に推論中に実際に何が起きているのかについても、かなり議論があるそれでも、可能であれば試してみる価値のある技法である関連リソースの提供関連リソースを提供することは、モデルの知識基盤を拡張し、幻覚を減らし、ユーザーの信頼を高める強力なメカニズムである多くの場合、検索拡張生成（Retrieval Augmented Generation, RAG）を通じて行われるモデルに、応答へ直接活用できるテキストスニペットを提供することは不可欠な技術である関連リソースを提供する際は、単に含めるだけでは不十分であるモデルに対して、リソースの利用を優先し、直接参照し、ときにはリソースが十分でない場合はその旨を述べるよう指示することを忘れてはならないこれらは、エージェントの応答をリソースコーパスに「グラウンド」させるのに役立つ入力と出力を構造化する構造化された入力と出力は、モデルが入力をよりよく理解し、ダウンストリームシステムと安定して統合できる出力を返すのに役立つ入力にシリアライズ形式を追加すると、コンテキスト内のトークン間の関係、特定トークンに関する追加メタデータ（型など）、あるいは要求をモデルの学習データ中の類似例と結び付ける助けになる場合があるたとえば、インターネット上でSQL作成についての多くの質問は、SQLスキーマの指定から始まるしたがって、Text-to-SQLに対する効果的なプロンプティングには、構造化されたスキーマ定義を含めるべきである構造化された出力も同様の目的を果たすが、システムのダウンストリーム構成要素との統合を簡素化する Instructor と Outlines は構造化出力でうまく機能する（LLM API SDKを使う場合は Instructor、自前でホストするモデルに Huggingface を使う場合は Outlines を使う）構造化された入力は、タスクを明確に表現し、学習データの形式にも似ているため、より良い出力が得られる可能性を高める構造化入力を使う際は、各LLMファミリーごとに好む方式がある点に注意すべきである Claude はを好む一方、GPT は Markdown と JSON を好む XMLを使うと、タグを与えて Claude の応答を事前入力することもできる小さく、1つのことをうまくこなすプロンプトを作るソフトウェアでよくあるアンチパターン／コードスメルに、「すべてをこなす単一のクラスや関数」である「God Object」があるこれはプロンプトにも同じように当てはまるプロンプトは通常、シンプルに始まる数文の指示と、いくつかの例から始められるしかし、性能を改善し、より多くのエッジケースに対応しようとするうちに複雑さが増していくさらに多くの指示、多段階の推論、数十個の例などが追加されるその結果、当初は単純だったプロンプトが、2,000トークンのフランケンシュタインになってしまうしかも、より一般的で直感的な入力に対する性能はむしろ低下する GoDaddy はこの問題を、LLM構築から得た教訓の第1位に挙げているシステムやコードをシンプルに保とうとするのと同様に、プロンプトもそうあるべきである会議文字起こしの要約器に単一の万能プロンプトを使う代わりに、次のような段階に分けられる主要な決定事項、アクションアイテム、担当者を構造化形式で抽出する抽出した詳細を元の文字起こしと照合して一貫性を確認する構造化された詳細から簡潔な要約を生成するその結果、1つのプロンプトを複数のシンプルで焦点が明確かつ理解しやすいプロンプトに分割することになるこのように分割すれば、各プロンプトを個別に反復し、評価できるようになるコンテキストトークンを作るエージェントに実際に送る必要があるコンテキスト量についての前提を見直し、疑ってかかるべきであるミケランジェロのようにコンテキストの彫像を作り上げていくのではなく、不要な素材を削ぎ落として彫像を浮かび上がらせるべきである RAGは、潜在的に関連する大理石の塊をすべて集めるための一般的な手法だが、必要なものを抽出するために何をしているだろうか? モデルに送られる最終プロンプトを取り出し、すべてのコンテキスト構成、メタプロンプティング、RAGの結果とともに空白のページに置いて読んでみることが、コンテキストの見直しに役立つと分かったこの方法を使うと、重複、自己矛盾する表現、形式が不適切な部分を見つけられるもう1つの重要な最適化はコンテキストの構造である Bag-of-docs表現は人間にとって有用ではないのだから、エージェントにとっても良いと安易に仮定すべきではないコンテキストの各部分の関係を強調し、抽出をできるだけ単純にできるよう、コンテキストをどう構成するかを慎重に検討すべきである戦術2. 情報検索 / RAG プロンプティングに加えて、LLMを調整するもう1つの効果的な方法は、プロンプトの一部として知識を提供することであるこれは与えられたコンテキストにLLMをグラウンディングするもので、インコンテキスト学習に用いられるこれを検索拡張生成(Retrieval-Augmented Generation, RAG)と呼ぶ実務家たちは、RAGが知識を提供し出力を改善するうえで効果的であり、ファインチューニングと比べてはるかに少ない労力とコストで済むことを見いだしている RAGの良し悪しは、検索された文書の関連性、情報密度、詳細さに左右される RAG出力の品質は検索された文書の品質に依存し、いくつかの要素を考慮できる 1つ目で最も明白な指標は「関連性」であるこれは通常、平均逆順位(Mean Reciprocal Rank, MRR)や正規化割引累積利得(Normalized Discounted Cumulative Gain, NDCG)のようなランキング指標で定量化される MRRは、システムが順位リストの中で最初の関連結果をどれだけうまく配置できるかを評価する一方、NDCGはすべての結果の関連性と位置を考慮するこれらは、関連文書をより上位に、無関係な文書をより下位にランク付けするシステムの性能を測定するたとえば、映画レビューの要約を生成するためにユーザー要約を検索する場合、特定の映画に対するレビューをより上位にランク付けし、別の映画に対するレビューは除外するのが望ましい従来の推薦システムと同様に、検索された項目の順位は、LLMがダウンストリームのタスクをどのように実行するかに大きな影響を与える影響を測定するには、検索結果をシャッフルした状態でRAGベースのタスクを実行し、RAGの出力がどう変化するかを確認するとよい 2つ目は「情報密度」である 2つの文書が同程度に関連しているなら、より簡潔で無関係な詳細が少ない文書を優先すべきである映画の例に戻ると、映画の脚本とすべてのユーザーレビューは、広い意味では関連していると見なせるそれでも、高評価のレビューや編集レビューのほうが情報密度は高い可能性がある最後に、文書で提供される「詳細度」を考慮すべきである自然言語からSQLクエリを生成するRAGシステムを構築すると想像してみよう列名のあるテーブルスキーマをコンテキストとして提供するだけでも十分かもしれないしかし、列の説明やいくつかの代表値も含めたらどうだろうか? 追加の詳細情報は、LLMがテーブルの意味をよりよく理解し、より正確なSQLを生成する助けになる可能性があるキーワード検索を忘れず、ベースラインとハイブリッド検索に使うこと EmbeddingベースのRAGデモが広く出回っているため、情報検索分野における数十年分の研究とソリューションを忘れたり見落としたりしがちであるそれでも、埋め込みが強力なツールであることは間違いないが、万能ではないキーワードベース検索の利点第1に、埋め込みは高レベルの意味的類似性を捉えるのに優れているが、ユーザーが名前(例: Ilya)、頭字語(例: RAG)、またはID(例: claude-3-sonnet)を検索するときのような、より具体的でキーワードベースのクエリには苦戦することがある BM25のようなキーワードベース検索は、このために明示的に設計されているユーザーは長年キーワード検索を使ってきたため、それを当然のものと考えており、探している文書が返ってこなければ不満を感じる可能性がある第2に、キーワード検索のほうが、なぜ文書が検索されたのかを理解しやすいクエリに一致したキーワードを確認できるためである一方で、埋め込みベース検索は解釈可能性が低い第3に、LuceneやOpenSearchのような、数十年にわたり最適化され実運用で検証されてきたシステムのおかげで、キーワード検索のほうが一般に計算効率が高いほとんどの場合、ハイブリッドアプローチが最も効果的である明白な一致にはキーワードマッチングを使い、同義語、上位語、スペルミス、マルチモーダル(例: 画像とテキスト)には埋め込みを使う Shortwaveは、クエリ書き換え、キーワード + 埋め込み検索、ランキングなど、自社のRAGパイプラインをどのように構築したかを共有している新しい知識についてはファインチューニングよりRAGを優先する RAGとファインチューニングはどちらも、新しい情報をLLMに統合し、特定タスクでの性能を向上させるために使えるでは、まずどちらを試すべきだろうか? RAGの利点最近の研究によれば、RAGのほうが優れている可能性があるある研究では、RAGと教師なしファインチューニング(継続事前学習とも呼ばれる)を、MMLUと時事問題のサブセットで評価して比較した RAGは、学習中に触れた知識と完全に新しい知識の両方において、ファインチューニングより一貫して高い性能を示した別の論文では、農業データセットについてRAGと教師ありファインチューニングを比較した同様に、RAGの性能向上はファインチューニングより大きく、特にGPT-4で顕著だった(論文の表20を参照) 性能向上に加えて、RAGにはいくつかの実務上の利点がある第1に、継続事前学習やファインチューニングと比べて、検索インデックスを最新の状態に保つほうが容易で安価である第2に、検索インデックスに有害または偏った内容を含む問題のある文書がある場合、その文書を容易に削除または修正できるまた、RAGのRは文書をどのように検索するかについて、よりきめ細かな制御を提供するたとえば複数の組織向けにRAGシステムをホスティングする場合、検索インデックスを分割し、各組織が自分たちのインデックス内の文書だけを検索できるようにできるこれにより、ある組織の情報を誤って別の組織に露出させることを防げる長文コンテキストモデルがRAGを無用にすることはない Gemini 1.5 が最大 1,000万トークンのコンテキストウィンドウを提供するようになり、一部では RAG の未来に疑問を抱き始めている 1,000万トークンのコンテキストウィンドウは、従来の RAG フレームワークの大半を不要にするデータをコンテキストに入れて、いつもどおりモデルと対話するだけでよいこれが、エンジニアリング上の努力の大半を RAG に注ぎ込んでいるスタートアップ、エージェント、langchain プロジェクトにどのような影響を与えるか想像してみてほしい一言で言えば、1,000万コンテキストが RAG を殺すということだ RAG が引き続き必要とされる理由長大なコンテキストが複数文書の分析や PDF とのチャットといったユースケースでゲームチェンジャーになるのは事実だが、RAG の終焉に関する噂は大きく誇張されている第一に、1,000万トークンのコンテキストウィンドウがあっても、なおモデルに入力する情報を選ぶ方法が必要である第二に、狭い needle-in-a-haystack 評価を超えて、モデルがそれほど大きなコンテキストに対して効果的に推論できることを示す説得力あるデータは、まだ見たことがないしたがって、優れた検索（およびランキング）がなければ、注意を散らす情報でモデルを圧倒したり、さらには完全に無関係な情報でコンテキストウィンドウを埋め尽くしたりする危険がある最後に、コストの問題がある Transformer の推論コストは、コンテキスト長に応じて二乗で増加する（あるいは空間と時間の両方で線形に増加する）組織全体の Google Drive の内容を読めるモデルが存在するとしても、各質問に答える前に毎回そうするのがよい考えとは限らない RAM の使い方に関する比喩を考えてみよう数十テラバイト級の RAM を持つコンピューティングインスタンスは存在するが、それでもなおディスクへの読み書きを行っているしたがって、まだ RAG をゴミ箱に捨てないことこのパターンは、コンテキストウィンドウのサイズが大きくなっても依然として有用であり続けるだろう戦術 3. ワークフローのチューニングと最適化 LLM にプロンプトを与えることは、始まりにすぎない LLM を最大限活用するには、単一のプロンプトを超えてワークフローを受け入れる必要があるたとえば、複雑な単一タスクをどのように複数のより単純なタスクに分割できるだろうか？ファインチューニングやキャッシングが、性能向上とレイテンシ／コスト削減に役立つのはいつだろうか？このセクションでは、実証済みの戦略と実例を共有し、LLM ワークフローの最適化と構築に役立てる段階的なマルチターンの「Flow」は大きな性能向上をもたらしうる 1つの大きなプロンプトを複数の小さなプロンプトに分解することで、より良い結果が得られることはすでに知られている AlphaCodium がその例である単一プロンプトから多段階ワークフローへ移行することで、CodeContests における GPT-4 の精度（pass@5）を 19% から 44% へ引き上げたワークフローには次が含まれる問題についての熟考公開テストに対する推論可能な解法の生成可能な解法の順位付け合成テストの生成公開テストおよび合成テストに対する解法の反復明確な目標を持つ小さなタスクは、最良のエージェントまたはフロープロンプトを作るすべてのエージェントプロンプトが構造化出力を要求する必要はないが、構造化出力は、エージェントの環境との相互作用を調整するシステムとのインターフェースとして大いに役立つ試してみる価値のあることできる限り厳密に定義された明示的な計画ステップあらかじめ定義された計画の中から選ぶことも検討するとよい元のユーザープロンプトをエージェントプロンプトに書き換えるこの過程では情報損失が発生するため、注意が必要である線形チェーン、DAG、および状態機械としてのエージェント動作さまざまな依存関係や論理関係は、異なるスケールに対して向き不向きがありうるさまざまなタスクアーキテクチャで性能最適化を引き出せるだろうか？計画の検証計画には、最終成果物がうまく機能するように他のエージェントの応答を評価する方法に関する指示を含めることができる固定されたアップストリーム状態を前提としたプロンプトエンジニアリングエージェントプロンプトが、以前に発生しうるさまざまなバリエーションに対して評価されていることを確認すること現時点では決定論的ワークフローを優先すること AI エージェントはユーザーの要求と環境に動的に反応できるが、その非決定論的な特性はデプロイを難しくするエージェントが実行する各ステップは失敗する可能性があり、エラーから回復できる可能性は低いしたがって、エージェントが多段階タスクを成功裏に完了できる確率は、ステップ数が増えるにつれて幾何級数的に低下するその結果、エージェントを構築するチームは、信頼できるエージェントを本番投入することに苦労する有望なアプローチは、決定論的な計画を生成し、それを構造化され再現可能な方法で実行するエージェントシステムを持つことである最初の段階では、上位レベルの目標またはプロンプトが与えられると、エージェントが計画を生成するその後、計画は決定論的に実行されるこれにより、各ステップをより予測可能かつ信頼性の高いものにできる利点生成された計画は、エージェントにプロンプトを与えたりファインチューニングしたりするための few-shot サンプルとして利用できる決定論的な実行はシステムの信頼性を高め、テストとデバッグを容易にする。また、失敗を計画の特定ステップまで追跡できる生成された計画は有向非巡回グラフ（DAG）として表現でき、静的プロンプトに比べて理解しやすく、新しい状況にも適応しやすい最も成功しているエージェント構築者は、ジュニアエンジニアのマネジメント経験が豊富な人かもしれない計画生成プロセスは、ジュニアを指導・管理するやり方と似ているためであるジュニアに曖昧でオープンエンドな指示ではなく、明確な目標と具体的な計画を与えるのと同様に、エージェントにも同じことをすべきである結局のところ、信頼できて実際に機能するエージェントの核心はより構造化され、より決定論的なアプローチを採用すること、そして、プロンプトを改善しモデルをファインチューニングするためのデータを収集することに見いだされる可能性が高いこれがなければ、ときには非常によく動作しても、平均的にはユーザーを失望させ、定着率を低下させるエージェントを構築することになるだろう温度パラメータ以上に多様な出力を得る LLM の出力に多様性が必要なタスクがあると仮定しようユーザーが過去に購入した製品の一覧を考慮し、カタログから購入すべき製品を提案する LLM パイプラインを書いているかもしれないプロンプトを何度も実行すると、推薦結果があまりにも似通っていることに気づくかもしれないそこで、LLM リクエストの Temperature（温度）パラメータを上げることができる温度パラメータを上げると、LLM の応答はより多様になるサンプリング時に次トークンの確率分布がより平坦になり、通常は選ばれにくいトークンがより頻繁に選ばれるようになるしかし、温度を上げると、出力の多様性に関するいくつかの失敗モードが発生しうるたとえば、カタログ内の一部製品は適切であっても、LLM によって出力されないことがある LLM が学習時に学んだ内容に基づいてプロンプトに従う可能性が高い場合、同じ少数の製品が出力で過剰に代表されることがある温度が高すぎると、存在しない製品（あるいは意味のない内容）を参照する出力が生成されることがある温度を上げたからといって、LLM が想定どおりの確率分布（たとえば一様ランダム）から出力をサンプリングする保証はないそれでも、出力の多様性を高めるための別の工夫がある最も簡単な方法は、プロンプト内の要素を調整することたとえば、プロンプトテンプレートに過去の購入履歴のような項目一覧が含まれている場合、それらの項目をプロンプトに挿入するたびに順序をシャッフルすれば、かなりの違いを生み出せるまた、最近の出力の短いリストを保持しておくと、重複の防止に役立つ推薦製品の例では、LLM に対してこの最近のリストにある項目の提案を避けるよう指示したり、最近の提案と似た出力を拒否して再サンプリングしたりすることで、応答をさらに多様化できるもう1つの効果的な戦略は、プロンプトで使う表現を多様化することであるたとえば「ユーザーが定期的に使いたくなる項目を選ぶ」や「ユーザーが友人に勧める可能性が高い製品を選ぶ」といった文言を組み込むと、焦点が移り、推薦製品の多様性に影響を与えられるキャッシングは過小評価されているキャッシュは、同一入力に対する応答を再計算する必要をなくすことでコストを削減し、生成レイテンシをなくすまた、応答が以前にガードレール適用済みであれば、こうした検証済みの応答を返すことで、有害または不適切なコンテンツを提供するリスクを減らせるキャッシュへのシンプルなアプローチは、新しい記事や製品レビューを要約する場合のように、処理対象の項目に一意のIDを使うことリクエストが来たら、要約がすでにキャッシュ内に存在するか確認できる存在するなら即座に返せるし、存在しないなら生成し、ガードレールを適用して提供したうえで、将来のリクエストに備えてキャッシュに保存できるもう少しオープンエンドなクエリでは、オープンエンドな入力に対してもキャッシュを活用する検索分野の技術を借用できるオートコンプリートやスペル修正のような機能は、ユーザー入力を正規化してキャッシュヒット率を高めるのに役立つ finetune（ファインチューニング）が必要になる時点どれほど巧妙に設計されたプロンプトでも不十分なタスクがあるたとえば、かなりのプロンプトエンジニアリングを行っても、システムが依然として信頼できる高品質な出力を返すには程遠い場合があるこの場合、特定のタスク向けにモデルをファインチューニングする必要があるかもしれないファインチューニングが成功した事例 HoneycombのNatural Language Query Assistant 当初は「プログラミングマニュアル」が、コンテキスト内学習のためのn-shot例とともにプロンプトへ提供されていたこれでも適切に機能したが、モデルをファインチューニングすると、ドメイン固有言語の構文やルールに関してより良い出力を得られる RechatのLucy LLMは、フロントエンドが正しくレンダリングするために、構造化データと非構造化データを組み合わせた非常に特定の形式で応答を生成しなければならないファインチューニングは、これを一貫して機能させるうえで不可欠であるファインチューニングは効果的な場合があるが、かなりのコストを伴うファインチューニング用データにアノテーションを付け、モデルをファインチューニングして評価し、最終的には自前でホスティングしなければならないそのため、より高い初期コストに見合う価値があるかを検討する必要があるプロンプティングで90%まで到達できるなら、ファインチューニングに投資する価値はないかもしれないただし、ファインチューニングすると決めたなら、人手で注釈を付けたデータの収集コストを減らすために、合成データを生成してファインチューニングしたり、オープンソースデータでブートストラップしたりできる戦術 4. 評価とモニタリング LLMの評価は地雷原になり得る LLMの入力と出力は任意のテキストであり、設定するタスクも多様であるそれでも、厳密で慎重な評価は重要である OpenAIの技術リーダーたちが評価に関わり、個々の評価にフィードバックを与えているのは偶然ではない LLMアプリケーションの評価には、さまざまな定義と切り詰め方が必要になる単なるユニットテストかもしれないし、可観測性に近いものかもしれないし、単なるデータサイエンスかもしれない私たちは、これらすべての観点が有用であることを見いだしたこのセクションでは、評価およびモニタリングのパイプライン構築で重要な点について学んだ教訓を紹介する実際の入出力サンプルから、いくつかのassertionベースのユニットテストを作成する本番環境の入力と出力のサンプルから成るユニットテスト（つまりassertion）を作成し、少なくとも3つの基準に従って出力への期待値を設定する 3つという基準は恣意的に見えるかもしれないが、始めるには実用的な数であるこれより少ないなら、タスクの定義が十分でないか、汎用チャットボットのようにオープンすぎる可能性があるこうしたユニットテストまたはassertionは、プロンプトの編集、RAGによる新しいコンテキストの追加、その他の修正といったパイプラインの変更によってトリガーされるべきであるまずは、すべての応答に含めるべき、あるいは含めてはならない語句やアイデアを指定するassertionから始めることを検討するまた、単語数、項目数、文数が範囲内かを確認するチェックも検討する他の種類の生成では、assertionの形も異なる場合があるたとえばコード生成を評価する強力な方法である実行評価では、生成されたコードを実行し、ランタイム状態がユーザーの要求に十分応えているか確認するたとえば、ユーザーがfooという新しい関数を要求したなら、エージェントが生成したコードを実行したあとにfooを呼び出せるはずである実行評価における課題の1つは、エージェントのコードがしばしば対象コードと少し異なる形でランタイムを残すことだどんな妥当な回答でも満たせる最も弱い仮定へとassertionを「緩める」ことが効果的な場合がある顧客向けに意図されたとおりに製品を使うこと（つまり「ドッグフーディング」）は、実データにおける障害モードへの洞察を与えてくれるこのアプローチは潜在的な弱点の特定に役立つだけでなく、評価へ変換できる有用な本番サンプルの供給源にもなる LLM-as-Judgeは（ある程度）機能し得るが、万能ではない LLM-as-Judgeは、強力なLLMを使って別のLLMの出力を評価する方式であり、人によっては懐疑的に受け止められているそれでも、うまく実装されれば、LLM-as-Judgeは人間の判断とかなり高い相関を達成でき、少なくとも新しいプロンプトや手法がどのように機能しそうかについて事前情報を築くのに役立つ特にペア比較（例: 対照群 vs 処置群）を行う場合、LLM-as-Judgeは一般に方向性は正しく捉えるが、勝敗の差の大きさにはノイズが入り得る LLM-as-Judgeを最大限活用するための提案ペア比較を使う LLMに単一の出力をLikert尺度で評価させるのではなく、2つの選択肢を提示して、より良いほうを選ばせるこのほうが、より安定した結果につながる傾向がある位置バイアスを制御する提示された選択肢の順序がLLMの判断を偏らせる可能性があるこれを緩和するには、各ペア比較を2回実行し、そのたびにペアの順序を入れ替える入れ替えた後は、正しい選択肢に勝利を帰属させる必要がある引き分けを許容する場合によっては、2つの選択肢が同じくらい良いこともあるしたがって、LLMが恣意的に勝者を選ばなくて済むよう、引き分けを宣言できるようにする Chain-of-Thoughtを使う最終的な選好を示す前に、その判断を説明するようLLMに求めると、評価の信頼性が向上する場合があるおまけに、これにより、より弱いが高速なLLMを使っても似た結果を得られるパイプラインのこの部分はしばしばバッチモードで動くため、CoTによる追加レイテンシは問題にならない応答長を制御する LLMはより長い応答に偏る傾向があるこれを緩和するには、応答ペアの長さが近いことを確認する LLM-as-Judgeの特に強力な適用例は、新しいプロンプト戦略に回帰がないか確認することだ本番結果のコレクションを追跡しているなら、新しいプロンプト戦略でその本番サンプルを再実行し、LLM-as-Judgeを使って新しい戦略がどこで苦戦しそうかを素早く評価できる場合がある LLM-as-Judgeのシンプルだが効果的なアプローチの例単にLLMの応答、ジャッジの批評（つまりCoT）、最終結果を記録するその後、関係者とレビューして改善領域を特定する 3回の反復を通じて、人間とLLMの一致度は68%から94%へ向上したしかし、LLM-as-Judgeは万能ではない最も強力なモデルでさえ、信頼して評価できない微妙な言語的側面があるまた、従来の分類器や報酬モデルのほうが、LLM-as-Judgeより高い精度をより低いコストとレイテンシで達成できることも分かったコード生成では、LLM-as-Judgeは実行評価のようなより直接的な評価戦略より弱い場合がある生成結果評価のための「インターンテスト」生成結果を評価する際には、次のような「インターンテスト」を使うのがよいコンテキストを含めた言語モデルへの正確な入力を、関連分野を専攻する平均的な大学生に課題として与えた場合、その学生は成功できるだろうか？どれくらい時間がかかるか？答えがノーの場合 LLMに必要な知識が不足しているためなら、コンテキストを充実させる方法を検討するコンテキストを改善しても解決できないなら、現代のLLMには難しすぎるタスクかもしれない答えがイエスだが時間がかかる場合タスクの複雑さを下げられないか試してみる分解できるか？タスクのどの側面をよりテンプレート化できるか？答えがイエスで、しかも素早くできる場合データを掘り下げるときモデルは何を誤っているのか？失敗のパターンを見つけられるか？応答の前後でモデル自身に説明させてみる特定の評価に過度に重点を置くと、全体的な性能が低下することがある「測定指標が目標になると、それはもはや良い測定指標ではなくなる。」 - グッドハートの法則その例としてNeedle-in-a-Haystack（NIAH）評価がある元の評価は、コンテキストサイズが大きくなるにつれてモデルのリコールを定量化し、針の位置によってリコールがどう影響されるかを確認するのに役立つしかし過度に強調され、Gemini 1.5レポートのFigure 1として紹介されたこの評価では、ポール・グレアムのエッセイを繰り返した長文ドキュメントに特定のフレーズ（"The special magic {city} number is: {number}"）を挿入し、その後モデルにマジックナンバーを思い出させるタスクが含まれる一部のモデルはほぼ完璧なリコールを達成しているが、NIAHが実際のアプリケーションで必要な推論力やリコール能力を本当に反映しているのかは疑わしいより実用的なシナリオを考える 1時間分の会議録音の文字起こしが与えられたとき、LLMは主要な決定事項と次のアクションを要約し、各項目を適切な担当者に正しくひも付けられるか？このタスクは単純な暗記を超え、複雑な議論を把握し、関連情報を特定し、要約を統合する能力も問うため、より現実的である実用的なNIAH評価の例医師と患者のビデオ通話の文字起こしを使い、LLMに患者の薬について質問するエスプレッソに漬けたナツメヤシ、レモン、ヤギのチーズなど、ピザのトッピングに必要なランダムな材料に関するフレーズを挿入する、より挑戦的なNIAHも含まれる薬のタスクではリコールは約80%、ピザのタスクでは30%だった NIAH評価を過度に重視すると、抽出や要約タスクの性能が下がる可能性があるこのようなLLMはすべての文に注意を向けるよう微調整されているため、無関係な詳細や気を散らす情報まで重要なものとして扱い始めることがあるその結果、最終出力に含まれてしまうことがある（含まれるべきでない場合でも！）これは他の評価やユースケースにも当てはまるたとえば要約事実的一貫性を重視すると、より具体性が低く（したがって事実と一致しない可能性も低い）、関連性に欠ける要約が生成されることがある逆に文章スタイルや雄弁さを重視すると、事実との不一致を招きうる、より派手なマーケティング調の言語が生成されることがあるアノテーションを二値タスクまたはペアワイズ比較に単純化するモデル出力に対して自由記述のフィードバックを与えたり、Likert尺度で評価したりするのは認知的負荷が高いその結果、収集されたデータは人間評価者間のばらつきによってノイズが増え、有用性が下がるより効果的なアプローチは、タスクを単純化してアノテーターの認知負荷を減らすことうまく機能する2つのタスクは、二値分類とペアワイズ比較である二値分類では、アノテーターはモデルの出力について単純なイエス／ノーの判断を求められる生成された要約が元文書と事実的に一致しているか、提案された応答が関連しているか、有害性を含んでいるか、などを問うことができる Likert尺度と比べて、二値の判断はより正確で、評価者間の一貫性が高く、処理量も多い DoorDashが一連のイエス／ノー質問を通じてメニュー項目にタグ付けするためのラベリングキューを構築した方法などがあるペアワイズ比較（Pairwise Comparison）では、アノテーターは一対のモデル応答を受け取り、どちらがより良いかを尋ねられる人間にとってAまたはBを個別に採点するより、「AはBより良い」と言うほうが簡単なので、より速く信頼性の高いアノテーションにつながる（Likert尺度よりも） Llama2ミートアップで、Llama2論文の著者の1人であるThomas Scialomは、ペアワイズ比較のほうが、記述済みの応答のような教師あり微調整データを収集するよりも速く安価であることを確認した前者のコストは1件あたり$3.5、後者のコストは1件あたり$25 参照不要（Reference-free）評価とガードレールは相互に置き換えて使えるガードレールは不適切または有害なコンテンツを捕捉するのに役立ち、一方で評価はモデル出力の品質と正確性を測るのに役立つ参照不要評価の場合、これはコインの表裏の関係と見なせる参照不要評価とは、人間が作成した回答のような「golden」referenceに依存せず、入力プロンプトとモデルの応答だけで出力品質を評価できる評価のこと参照不要評価の例: 要約評価要約の事実的一貫性と関連性を評価するには、入力文書だけを考慮すればよい要約がこれらの指標で低スコアなら、ユーザーに表示しないようにできるため、評価を実質的にガードレールとして利用できる参照不要の「翻訳」評価: 人間による翻訳参照がなくても翻訳の品質を評価でき、これもまたガードレールとして使える LLMは返すべきでないときにも出力を返す LLMを扱う際の主要な課題は、そうすべきでない場面でもLLMがしばしば出力を生成してしまうことこれは無害だが無意味な応答から、有害性や危険な内容のようなより深刻な欠陥まで引き起こしうるたとえば文書から特定の属性やメタデータを抽出するよう求められると、その値が実際には存在しない場合でも、LLMは自信満々に値を返すことがあるまた、コンテキストとして英語以外の文書を与えたために、モデルが英語以外の言語で応答することもある LLMに「該当なし」や「不明」の応答を返すようプロンプトで指示することはできるが、完璧ではないログ確率を使える場合でも、出力品質の指標としては不十分であるログ確率は出力にトークンが現れる可能性を示すが、生成されたテキストの正確性を反映するわけではないむしろ、クエリに応答し、一貫した応答を生成するよう訓練された命令チューニングモデルでは、ログ確率の較正が不十分な場合があるしたがって、高いログ確率は出力が流暢で一貫していることを示すかもしれないが、正確または関連性が高いことを意味しない慎重なプロンプトエンジニアリングはある程度役立つが、望ましくない出力を検出し、フィルタリング／再生成する強力なガードレールで補完する必要があるたとえばOpenAIは、ヘイトスピーチ、自傷、性的出力などの安全でない応答を識別できるコンテンツモデレーションAPIを提供している同様に、個人識別情報（PII）を検出するための多数のパッケージが存在するガードレールの利点の1つは、ユースケースへの依存が比較的少なく、そのため特定の言語でのあらゆる出力に広く適用できることまた、高精度な検索によって関連文書が存在しない場合、システムが明確に「わかりません」と応答できる LLMは、出力が期待される場面で出力を生成できないこともあるこれはAPIプロバイダーの長いレイテンシのような単純な問題から、コンテンツモデレーションフィルターによって出力がブロックされるようなより複雑な問題まで、さまざまな理由で起こりうるしたがって、デバッグと監視のために、入力と（場合によっては出力不足も）一貫して記録することが重要である幻覚（Hallucination）はしつこい問題であるコンテンツ安全性やPIIの欠陥は多くの注意が払われるためほとんど発生しない一方で、事実の不一致はしつこく残り、検出もより難しいより頻繁に発生し、基準発生率は5〜10%であり、LLMプロバイダーから得た知見によれば、要約のような単純なタスクでも2%未満に下げるのは難しい場合があるこれに対処するために、プロンプトエンジニアリング（生成のアップストリーム）と事実不一致ガードレール（生成のダウンストリーム）を組み合わせられるプロンプトエンジニアリングでは、CoTのような技法は、LLMが最終出力を返す前に推論を説明させることで、ハルシネーションの低減に役立つその後、事実不一致ガードレールを適用して要約の事実性を評価し、ハルシネーションをフィルタリングまたは再生成できる場合によっては、ハルシネーションは決定論的に検出できる RAG検索のリソースを使う際、出力が構造化され、どのリソースかを識別できるなら、入力コンテキストから取得されたものかを手動で確認できるはずである [運用: 日常業務(Day-to-Day)および組織の問題 ] 運用 1. データ材料の質が料理の味を決めるように、入力データの品質は機械学習システムの性能を制約するまた、出力データは製品が機能しているかどうかを知る唯一の方法であるすべての執筆者は、データ分布（モード、エッジケース、モデルの限界）をよりよく理解するために、毎週数時間かけて入力と出力を綿密に確認する開発-本番バイアスの確認従来の機械学習パイプラインにおける一般的なエラー原因は、学習-提供バイアスであるこれは、学習に使われるデータが、モデルが本番で遭遇するデータと異なるときに発生する学習やファインチューニングなしでLLMを使えるため学習セットは存在しないが、開発-本番データバイアスという類似の問題が発生する基本的には、開発中にシステムをテストするデータは、システムが本番で直面するデータを反映している必要があるそうでなければ、本番精度が低下する可能性がある LLMの開発-本番バイアスは、構造的バイアスと内容ベースのバイアスの2種類に分類できる構造的バイアスには、リスト型の値を持つJSON辞書とJSONリストの違い、一貫しない大文字小文字、タイプミスや文の断片のような誤りなど、形式の不一致に関する問題が含まれるこうした誤りは、さまざまなLLMが特定のデータ形式で学習されており、プロンプトが些細な変更に非常に敏感な場合があるため、予測不能なモデル性能につながり得る内容ベース、または「意味論的」バイアスは、データの意味や文脈の違いを指す従来のMLと同様に、LLMの入出力ペア間のバイアスを定期的に測定することは有用である入力および出力の長さや、特定の形式要件（例: JSONまたはXML）のような単純なメトリクスは、変更を追跡する簡単な方法であるより「高度な」バイアス検出として、入出力ペアの埋め込みをクラスタリングし、ユーザーが以前モデルにさらされていない領域を探索していることを示す可能性がある、ユーザーが議論しているトピックの変化のような意味論的バイアスを検出することを検討するとよいプロンプトエンジニアリングのような変更をテストするときは、ホールドアウトデータセットが最新の状態であり、直近のユーザーインタラクションの種類を反映していることを確認するたとえば、本番入力でタイプミスがよく見られるなら、ホールドアウトデータにも含まれているべきである単に数値でバイアスを測定するだけでなく、出力に対して定性的評価を行うことも有益であるモデルの出力を定期的にレビューすること（俗に「バイブチェック」と呼ばれる実践）は、結果が期待に合致し、ユーザーのニーズに引き続き関連しているかを確認するのに役立つバイアス確認に非決定性を組み込むことも有用であるテストデータセットの各入力に対してパイプラインを複数回実行し、すべての出力を分析することで、たまにしか発生しない異常を捉えられる可能性が高まる毎日LLMの入出力サンプルを確認する LLMは動的で、絶えず進化している印象的なゼロショット能力としばしば満足のいく出力にもかかわらず、LLMの失敗モードは極めて予測しにくいカスタムタスクでは、LLMの性能について直感的な理解を育てるために、データサンプルを定期的に確認することが不可欠である本番の入出力ペアは、LLMアプリケーションにおける「現物、現場」(genchi genbutsu)であり、代替できない最近の研究では、開発者がより多くのデータと相互作用するほど、「良い」出力と「悪い」出力に対する認識が変化することが強調されている（つまり、基準バイアス）開発者はLLM出力を評価するための基準を事前にいくつか提示できるが、こうした事前定義の基準はしばしば不完全であるたとえば、開発過程で良い応答の確率を高め、悪い応答の確率を下げるために、プロンプトを更新できるこの評価、再評価、基準更新の反復プロセスは、出力を直接観察しなければLLMの振る舞いや人間の選好を予測するのが難しいために必要であるこれを効果的に管理するため、LLMの入力と出力を記録すべきである毎日これらのログサンプルを調べることで、新しいパターンや失敗モードを迅速に特定し、適応できる新しい問題を発見したら、すぐにそれに対するassertionまたはevalを書ける同様に、失敗モード定義に対するあらゆる更新は、評価基準に反映されるべきであるこのような「バイブチェック」は誤った出力のシグナルであり、コードとassertionがそれを運用する最後に、このような姿勢は組織内で共有されるべきであるたとえば、オンコールローテーションに入力および出力のレビューや注釈付けを追加すること運用 2. モデルとともに働く LLM APIを使うと、少数のプロバイダーの知能に依存することになるこれは良い面もあるが、こうした依存関係には、性能、レイテンシ、スループット、コストの面でトレードオフが伴うまた、この1年でほぼ毎月、より新しくより優れたモデルがリリースされてきたため、古いモデルを廃止して新しいモデルへ移行する際に、製品を更新する準備を整えておく必要があるこのセクションでは、完全には制御できない技術、つまり自前でホスティングや管理ができないモデルを使う際に得た教訓を共有する実際のユースケースの大半では、LLMの出力は何らかの機械可読形式を通じてダウンストリームアプリケーションで消費されることになるたとえば、不動産CRMのReChatでは、フロントエンドでウィジェットをレンダリングするために構造化された応答が必要である同様に、製品戦略アイデア生成ツールのBobaでは、タイトル、要約、実現可能性スコア、時間範囲フィールドを持つ構造化出力が必要である最後に、LinkedInは、使用する技術を決定し、その技術を呼び出すためのパラメータを提供するために使われるYAMLを生成するようLLMを制約する方法を共有したこのアプリケーションパターンは、Postelの法則の極端なバージョンである受け入れるもの（任意の自然言語）には寛容であり、送るもの（型付けされた機械可読オブジェクト）には保守的であるべきだしたがって、これは非常に耐久性のあるものになると期待している現在、InstructorとOutlinesは、LLMから構造化出力を引き出すための事実上の標準である LLM API（例: Anthropic、OpenAI）を使う場合はInstructorを、自前でホストするモデル（例: Huggingface）を使う場合はOutlinesを使うとよいモデル間のプロンプト移行はつらい作業である場合によっては、注意深く作られたプロンプトがあるモデルでは非常にうまく機能しても、別のモデルでは期待どおりに機能しないことがあるこれはさまざまなモデルプロバイダー間を切り替えるときだけでなく、同一モデルのバージョン間でアップグレードするときにも起こりうるたとえば Voiceflow は、gpt-3.5-turbo-0301 から gpt-3.5-turbo-1106 へ移行すると、意図分類タスクで 10% の性能低下が発生することを発見した（幸いにも、彼らには評価基盤があった！）同様に GoDaddy は、1106 バージョンへアップグレードすると、gpt-3.5-turbo と gpt-4 の性能差が縮まるという前向きな傾向を観測した（あるいは、物事を半分空ではなく半分満ちていると見る人でなければ、新しいアップグレードで gpt-4 のリードが縮まったことに失望するかもしれない）したがって、モデル間でプロンプトを移行する必要がある場合、単に API エンドポイントを差し替える以上の時間がかかると見込むべきである同じプロンプトをつなげば、同等あるいはより良い結果につながると安易に仮定してはならないまた、信頼できる自動評価は、移行前後のタスク性能の測定に役立ち、手動検証に必要な労力を減らしてくれるモデルのバージョン管理と固定どの機械学習パイプラインでも、「何かを変えると、すべてが変わる」これは特に、私たち自身で訓練しておらず、しかも知らないうちに変更される可能性がある大規模言語モデル（LLM）のようなコンポーネントに依存するときに当てはまる幸いなことに、多くのモデルプロバイダーは特定のモデルバージョン（例: gpt-4-turbo-1106）を「固定」できるオプションを提供しているこれにより、モデル重みの特定バージョンを使用し、変更されないようにできる本番環境でモデルバージョンを固定すれば、モデル挙動の予期しない変更を防げるこれは、モデルが置き換わったときに起こりうる、出力が過度に冗長になる問題やその他の想定外の失敗モードに対する顧客からの不満を避ける助けになるまた、本番設定をミラーしつつ最新のモデルバージョンを使う「シャドーパイプライン」を維持することも検討するとよいこれにより、新しいリリースで安全に実験やテストを行えるこうした新しいモデルで出力の安定性と品質を検証した後であれば、本番環境のモデルバージョンを自信を持って更新できるタスクを完了できる最小のモデルを選ぶ新しいアプリケーションに取り組むとき、利用可能な中で最も大きく強力なモデルを使いたくなる誘惑があるしかし、いったんそのタスクが技術的に実現可能だと確認できたなら、より小さなモデルで同等の結果が得られないか試してみる価値がある小さなモデルの利点は、レイテンシとコストが低いことだ性能は劣るかもしれないが、Chain-of-Thought、n-shot プロンプト、文脈内学習といった手法は、小さなモデルが本来の能力以上の働きをするのを助けられる LLM API 以外にも、特定タスク向けのファインチューニングは性能向上に役立つことがある総合すると、小さなモデルを使った慎重に設計されたワークフローは、より速く安価でありながら、単一の大規模モデルの出力品質に匹敵し、場合によってはそれを上回ることさえあるたとえばこのツイートでは、Haiku + 10-shot プロンプトがゼロショットの Opus や GPT-4 を上回る方法についての逸話が共有されている長期的には、出力品質・レイテンシ・コストの最適なバランスを目指した、小さなモデルによるフローエンジニアリングの事例がさらに増えると予想されるもうひとつの例として、地味な分類タスクがある DistilBERT（6,700 万パラメータ）のような軽量モデルは、驚くほど強力なベースラインである 4 億パラメータの DistilBART も、もうひとつの優れた選択肢だオープンソースデータでファインチューニングすれば、レイテンシとコストを 5% 未満に抑えつつ、ROC-AUC 0.84 で幻覚を識別でき、大半の LLM を上回る要点は、小さなモデルを見過ごしてはならないということだあらゆる問題に巨大なモデルを当てはめるのは簡単だが、少しの創意工夫と実験によって、私たちはしばしばより効率的な解決策を見つけられる運用 3. プロダクト新しい技術は新たな可能性をもたらすが、優れたプロダクトを作る原則は普遍であるしたがって、まったく新しい問題を初めて解く場合でも、プロダクト設計を一からやり直す必要はない堅実なプロダクトの基本に LLM アプリケーション開発を基づけることで、得られるものは多いそうすることで、私たちがサービスを提供する人々に本当の価値を届けられる初期段階からデザインを関与させるデザイナーがいると、プロダクトをどう構築し、どうユーザーに提示するかを理解し、深く考えるようになるときには、デザイナーを単に物事をきれいに見せる人だと固定観念で捉えてしまうことがあるしかし実際には、ユーザーインターフェースだけでなく、既存のルールやパラダイムを壊すことになっても、ユーザー体験をどう改善できるかを再考する役割を担うデザイナーは、ユーザーの要求をさまざまな形に再構成することに、とりわけ長けているその中には他の形より解きやすいものもあり、AI ソリューションにより多く、あるいはより少ない機会を与えることがある多くの他のプロダクトと同様に、AI プロダクトの構築は、それを動かす技術ではなく、達成すべきタスクを中心に行うべきである次のような問いを自分に投げかけることに集中するとよい「ユーザーがこのプロダクトに求めているタスクは何か？そのタスクはチャットボットが得意そうなものか？オートコンプリートはどうか？もしかすると別のものかもしれない！」既存の設計パターンと、それが達成すべきタスクにどう関係するかを検討するとよいこれらは、デザイナーがチームの能力に加える貴重な資産であるヒューマン・イン・ザ・ループのための UX 設計質の高いアノテーションを得る1つの方法は、ユーザー体験（UX）に Human-in-the-Loop（HITL）を統合することユーザーが簡単にフィードバックや修正を提供できるようにすれば、即時の出力を改善でき、モデル改善に役立つデータも収集できるユーザーが商品をアップロードして分類するECプラットフォームを想像してみよう UXの設計方法はいくつもあるユーザーが正しい商品カテゴリを手動で選択し、LLMが定期的に新商品を確認してバックエンドで誤分類を修正するユーザーはカテゴリをまったく選択せず、LLMが定期的にバックエンドで商品を分類する（潜在的な誤りを含む） LLMがリアルタイムで商品カテゴリを提案し、ユーザーは必要に応じて検証・更新できる 3つのアプローチはいずれもLLMを含むが、提供するUXは大きく異なる 1つ目のアプローチは初期負担をユーザーに負わせ、LLMは事後処理のチェック役を担う 2つ目のアプローチはユーザーの労力を一切必要としないが、透明性やコントロールは提供しない 3つ目のアプローチが適切なバランスを保つ LLMが事前にカテゴリを提案することで、ユーザーの認知負荷を下げ、商品を分類するためにこちらの分類体系を学ぶ必要をなくす同時に、ユーザーが提案を確認して編集できるようにすることで、商品をどう分類するかの最終決定権をユーザーの手にしっかりと委ねるおまけに、3つ目のアプローチはモデル改善のための自然なフィードバックループを生み出す良い提案は受け入れられ（正のラベル）、悪い提案は更新される（負の後に正のラベル）この「提案 → ユーザー検証 → データ収集」というパターンは、多くのアプリケーションで一般的に見られるコーディングアシスタント: ユーザーは提案を受け入れる（強い正）、受け入れて調整する（正）、または無視する（負）ことができる Midjourney: ユーザーは画像をアップスケールしてダウンロードする（強い正）、画像を変更する（正）、または新しい画像セットを生成する（負）ことができるチャットボット: ユーザーは応答に対して「いいね」（正）または「よくないね」（負）を付けたり、応答が本当にひどい場合は再生成（強い負）を選んだりできるフィードバックは明示的な場合もあれば暗黙的な場合もある明示的フィードバックは、製品からの求めに応じてユーザーが提供する情報暗黙的フィードバックは、ユーザーが意図的にフィードバックを与えなくても、ユーザーとの相互作用から学習される情報コーディングアシスタントとMidjourneyは暗黙的フィードバックの例であり、「いいね」と「よくないね」は明示的フィードバックであるコーディングアシスタントやMidjourneyのようにUXをうまく設計すれば、製品とモデルの改善に向けた多くの暗黙的フィードバックを収集できる容赦なく要件階層（Hierarchy）の優先順位を付けるデモを本番環境に載せることを考えるときは、次の要件を考慮する必要がある信頼性: 99.9%の稼働率、構造化出力への準拠無害性: 攻撃的、NSFW、その他の有害なコンテンツを生成しないこと事実的一貫性: 提供されたコンテキストに忠実で、事実を歪めないこと有用性: ユーザーのニーズや要求に関連していること拡張性: レイテンシSLA、サポート可能なスループットコスト: 予算は無限ではないためその他: セキュリティ、プライバシー、公平性、GDPR、DMA などこれらすべての要件を一度に解決しようとすると、何もリリースできないだからこそ優先順位を付けなければならない。容赦なく。これは、製品が機能しない、あるいは成立しない可能性がある妥協不能な条件（例: 信頼性、無害性）が何かを明確にすることを意味する MVP（Minimum Lovable Product）を見極めることが重要である最初のバージョンは完璧ではないと受け入れ、リリースして反復していくべきであるユースケースに応じてリスク許容度を調整する言語モデルとアプリケーションのレビュー水準を決める際には、ユースケースと対象を考慮する必要がある医療や金融の助言を提供する顧客向けチャットボットでは、安全性と正確性に対して非常に高い基準が必要になるミスや誤った出力は現実の損害を生み、信頼を失わせる可能性がある一方で、推薦システムのようなそれほど重要でないアプリケーションや、コンテンツ分類・要約のような社内向けアプリケーションでは、厳しすぎる要件は大きな価値を追加しないまま進展を遅らせるだけであるこれは、多くの企業が外部向けアプリケーションよりも社内LLMアプリケーションのほうで速く動いているという最近の a16z レポートとも一致している社内生産性のためにAIを試すことで、組織はより統制された環境でリスクの管理方法を学びつつ、価値の獲得を始められるその後、自信が付けば顧客向けユースケースへと拡張できる運用 4. チームと役割（Roles）どんな職務も定義は簡単ではないが、この新しい領域で仕事の職務記述書を書くのはとりわけ難しい重なり合う職種のベン図や職務記述に関する提案はここでは省くただし、新しい役割であるAIエンジニアの存在を認め、その役割については論じる重要なのは、チームの残りの部分と責任をどのように割り当てるべきかを議論することであるツールではなくプロセスに集中する LLMのような新しいパラダイムに直面すると、ソフトウェアエンジニアはツールを好む傾向があるその結果、ツールが解決しようとしていた問題やプロセスを見落としてしまうこうして多くのエンジニアは偶発的複雑性を抱え込み、チームの長期的な生産性に悪影響を及ぼすたとえばこの記事では、特定のツールが大規模言語モデル向けのプロンプトを自動生成する方法について説明している問題解決の方法論やプロセスを先に理解せずにこうしたツールを使うエンジニアは、最終的に不要な技術的負債を背負い込むことになると主張している（IMHO もっともだ）偶発的複雑性に加えて、ツールはしばしば仕様が不十分であるたとえば、有害性、簡潔さ、トーンなどに関する汎用評価器を備えた「LLM評価ツールボックス」を提供するLLM評価ツール業界が成長している多くのチームが、自分たちのドメイン特有の失敗モードについて批判的に考えずに、こうしたツールを採用しているのを目にするこれに対してEvalGenは、基準の指定、データのラベリング、評価の確認など、各段階にユーザーを深く関与させることで、ドメイン固有の評価を生成するプロセスを教えることに重点を置いているソフトウェアはユーザーを次のようなワークフローへ導く EvalGenが導くLLM評価作成のベストプラクティスドメイン固有のテストを定義する（プロンプトから自動的にブートストラップされる）コードまたはLLM-as-a-Judgeによるアサーションとして定義されるテストが指定した基準を捉えているかをユーザーが確認できるようにするため、テストを人間の判断と一致させることの重要性システム（プロンプトなど）が変更されるのに合わせてテストを反復する EvalGenは開発者に評価構築プロセスのメンタルモデルを提供するが、特定のツールに固定することはない AIエンジニアにこの文脈を与えた後、彼らはよりシンプルなツールを選んだり、自前のツールを構築したりすることをしばしば決めると分かるプロンプト作成と評価以外にも、LLMの構成要素は非常に多く、ここですべてを列挙することはできないしかし、AIエンジニアがツールを採用する前にプロセスを理解しようと努めることは重要である常に実験する ML製品は実験と深く結びついている A/Bテストやランダム化比較試験だけでなく、システムの可能な限り最小の構成要素を修正し、オフライン評価を行う頻繁な試行を意味するみんなが評価に熱中する理由は、実際には信頼性や確信のためではなく、実験を可能にするためである！評価が優れているほど実験をより速く反復でき、その結果、システムの最良バージョンへより早く収束できる実験が非常に安価になったため、同じ問題を解くためにさまざまなアプローチを試すことが一般的になったデータ収集とモデル訓練の高コストは最小化されたプロンプトエンジニアリングのコストは、人間の時間が少し余分にかかる程度であるチーム全体がプロンプトエンジニアリングの基本を学べるようにすることこれにより全員が実験するよう促され、組織全体で多様なアイデアにつながる探索のためだけに実験するのではなく、活用のためにも実験を使うこと！新しいタスクの動作するバージョンはあるか？チームの別の人が異なる方法でアプローチすることを検討してみることより速い可能性のある別の方法を試す Chain-of-ThoughtやFew-Shotのようなプロンプト技法を調べ、品質を高めることツールが実験の妨げにならないようにすることもしそうなら、再構築するか、改善できるものを購入すること製品／プロジェクトの企画中には、評価の構築と複数の実験実施のための時間をあらかじめ確保することエンジニアリング製品向けの製品仕様を考え、そこに評価に関する明確な基準を追加することロードマップ作成時には、実験に必要な時間を過小評価しないこと本番承認を得る前に、複数回の開発と評価の反復を見込むこと誰もが新しいAI技術を使えるように権限を与える生成AIの採用が進むにつれて、専門家だけでなくチーム全体がこの新しい技術を理解し、使えると感じてほしい LLMがどのように動くか（例: レイテンシ、失敗モード、UX）について直感を養うのに、これ以上良い方法はない LLMは比較的取り組みやすいパイプラインの性能向上のためにコーディング方法を知っている必要はなく、誰もがプロンプトエンジニアリングと評価を通じて貢献できるこの大きな部分は教育である n-shotプロンプティングやCoTのような技法が、モデルを望ましい出力方向へ条件づけるのに役立つという、プロンプトエンジニアリングの基礎から始められる知識を持つ人は、LLMが本質的に自己回帰的であることのような、より技術的な側面についても教育できるつまり、入力トークンは並列処理されるが、出力トークンは逐次生成されるしたがって、レイテンシは入力長ではなく出力長の関数であるこれはUXを設計し、性能期待値を設定する際の主要な考慮事項である実験と探索のための実践機会を提供することもできるハッカソンはどうだろうか？チーム全体が数日間、投機的なプロジェクトをハックすることに時間を使うのは高くつくように見えるかもしれないが、その結果は驚くものになるかもしれないハッカソンによって、3年ロードマップを1年でほぼ完了したチームもある別のチームは、ハッカソンを通じてLLMによって初めて可能になったパラダイムシフトのUXへとつながり、それが今では今年以降の優先事項になっている「AIエンジニアリングがすべて」という落とし穴にはまらないこと新しい職種が生まれると、初期にはその役割に関連する能力を過大評価する傾向があるそれはしばしば、その職業の実際の範囲が明確になるにつれて痛みを伴う修正へとつながるこの分野の新参者や採用担当者は、大げさな主張をしたり過度な期待を抱いたりすることがある過去10年で注目すべき例は次のとおりであるデータサイエンティスト: 「あらゆるソフトウェアエンジニアより統計学に詳しく、あらゆる統計学者よりソフトウェアエンジニアリングに詳しい人」機械学習エンジニア（MLE）: 機械学習に対するソフトウェアエンジニアリング中心の視点当初、多くの人はデータ駆動型プロジェクトにはデータサイエンティストだけで十分だと想定していたしかし、データサイエンティストはデータ製品を効果的に開発・展開するために、ソフトウェアエンジニアやデータエンジニアと協力しなければならないことが明らかになったこの誤解はAIエンジニアという新しい役割でも再び現れ、一部のチームはAIエンジニアだけで十分だと信じている実際には、機械学習またはAI製品を構築するには幅広い専門職が必要である私たちは12社以上に対してAI製品に関するコンサルティングを行ってきたが、彼らが「AIエンジニアリングが必要なすべて」という思い込みの罠にはまるのを一貫して観察してきたその結果、製品構築に必要な重要要素を見落とし、製品がデモ以上に拡張できず苦戦することが多いたとえば、評価と測定はVibeチェック以上へ製品を拡張するために重要である効果的な評価に必要なスキルは、従来は機械学習エンジニアに見られる強みの一部と一致する AIエンジニアだけで構成されたチームは、こうしたスキルを欠いている可能性が高い共同著者のHamel Husainは、データバイアス検出とドメイン固有評価設計に関する最近の取り組みで、こうしたスキルの重要性を説明している AI製品構築の道のりで必要となる役割の種類とタイミングまず製品構築に集中すること AIエンジニアが含まれることはあり得るが、必須ではない AIエンジニアは製品（UX、配管など）をプロトタイプし、迅速に反復するのに有用である次に、システムを計測しデータを収集して、正しい基盤を作ることデータの種類と規模に応じて、プラットフォームエンジニアおよび／またはデータエンジニアが必要になる場合があるまた、問題をデバッグするためにこのデータをクエリして分析するシステムも必要である次に、AIシステムを最適化することこれは必ずしもモデル訓練を含むわけではない基本事項には、指標設計、評価システム構築、実験実行、RAG検索最適化、確率的システムのデバッグなどの段階が含まれる MLEはこの分野に非常に長けている（もちろんAIエンジニアも習得可能である）先行段階を完了していない場合、MLEを採用するのは通常妥当ではないこれとは別に、常にドメイン専門家が必要である小規模企業では理想的には創業チームがこの役割を担い、大企業ではプロダクトマネージャーがこの役割を果たせる役割の進行とタイミングを認識することが重要である間違ったタイミングで人を採用したり（例: MLEを早すぎる段階で採用する）、間違った順序で構築したりすることは、時間とコストの無駄であり離職を招くまた、1〜2段階でMLEと定期的にチェックインする（ただし正社員としては雇わない）ことで、会社が正しい基盤を築く助けになる [戦略: LLMを活用した構築で後れを取らない方法] 成功する製品開発には、やみくもにプロトタイプを作ったり最新モデルやトレンドを追いかけたりするのではなく、慎重な企画と優先順位付けが必要である AI製品開発では、自社開発するか購入するかといった主要なトレードオフを検討する必要がある初期のLLMアプリケーション開発のための「プレイブック」を提示する戦略1: PMF前にGPUなし優れた製品になるには、単に他人のAPIを薄くラップしただけ以上のものになる必要があるしかし、反対方向の失敗はさらに大きなコストを招くことがある昨年には、明確な製品ビジョンやターゲット市場もないまま、モデル学習とカスタマイズに莫大なベンチャー資本が投じられたある企業は実に60億ドルものシリーズA投資を受けたこのセクションでは、すぐに独自モデルの学習を始めることがなぜ誤りなのかを説明し、自前ホスティングの役割についても考察する最初から（ほぼ）再トレーニングするのは意味がないほとんどの組織にとって、最初からLLMを事前学習するのは、製品開発から逸脱した非現実的な取り組みである機械学習インフラの開発と維持には多くのリソースを要するデータ収集、モデルの学習と評価、デプロイなどが含まれるプロダクト・マーケット・フィットを検証する段階であれば、このような努力は中核となる製品開発からリソースを分散させる計算資源、データ、技術的能力があっても、事前学習済みLLMは数か月で陳腐化する可能性がある BloombergGPTの事例金融業務に特化したLLMであるBloombergGPTは、363Bトークンで事前学習された AIエンジニアリング4名、ML製品および研究5名の計9名の専任スタッフによる膨大な努力が投じられたそれにもかかわらず、1年以内にその業務でgpt-3.5-turboおよびgpt-4に後れを取ったこうした事例は、ほとんどの実アプリケーションにおいて、LLMをゼロから事前学習することがリソースの最善の使い方ではないことを示唆しているその代わり、チームは特定の要件に合わせて利用可能な最も強力なオープンソースモデルをファインチューニングするほうがよいもちろん例外はある Replitのコードモデルは、コード生成と理解に特化して事前学習された優れた事例である事前学習によってCodeLlama7bなどのより大きなモデルより優れた性能を示したしかし、より強力なモデルが登場するにつれ、有用性を維持するには継続的な投資が必要だった必要だと確認されるまではファインチューニング禁止ほとんどの組織で、ファインチューニングは戦略的思考よりもFOMO（Fear Of Missing Out、取り残されることへの不安）によって主導されている組織は「単なるラッパー」という非難を避けるため、あまりに早い段階でファインチューニングに投資してしまう実際には、ファインチューニングは、他のアプローチでは十分ではないと確信させる多くの事例を集めた後に初めて投入すべき重装備のようなものだ 1年前、多くのチームがファインチューニングへの期待を表明していたが、プロダクト・マーケット・フィットを見いだしたチームはわずかで、大半はその判断を後悔したファインチューニングを行うなら、ベースモデルの改善に応じて繰り返し実施する覚悟が必要である下の「モデルは製品ではない」と「LLMOps構築」を参照ファインチューニングが実際に正しい選択となりうる場合既存モデルの学習に使われた大半のオープンなWebスケールデータセットでは利用できないデータが必要な場合既存モデルでは不十分であることを示すMVPをすでに構築している場合ただし注意が必要である。優れた学習データをモデル開発者が容易に入手できないなら、あなたはどこから入手するのか？ LLMベースのアプリケーションは科学博覧会のプロジェクトではない戦略目標や競争上の差別化への貢献度に見合った投資が行われるべきである推論APIから始めつつ、セルフホスティングを恐れないこと LLM APIを使えば、スタートアップは最初から独自モデルを学習させなくても、言語モデリング機能を容易に導入・統合できる AnthropicやOpenAIなどのプロバイダーは、数行のコードで製品にインテリジェンスを与えられる汎用APIを提供しているこうしたサービスを使えば、労力を減らして顧客向けの価値創出に集中でき、アイデアの検証やプロダクト・マーケット・フィットへの反復をより速く進められるしかし、データベースと同様に、マネージドサービスは規模や要件が拡大するにつれて、すべてのユースケースに適しているわけではない実際、医療や金融のような規制産業、あるいは契約上の義務や機密保持要件により求められる場合、機密データや個人データをネットワーク外に送信せずにモデルを使う唯一の方法がセルフホスティングであることもあるさらにセルフホスティングは、推論プロバイダーが課すレート制限、モデル提供終了、利用制限などの制約を回避できるセルフホスティングはモデルに対する完全な制御権を提供し、差別化された高品質なシステムをより構築しやすくする最後に、セルフホスティング、とくにファインチューニングは、大規模ではコスト削減につながる可能性がある例えばBuzzfeedは、オープンソースLLMをファインチューニングしてコストを80%削減した事例を共有している戦略2: より良いものに向けて反復する長期的に競争優位を維持するには、モデルを超えて製品を差別化できる要素を考える必要がある実行速度は重要だが、それだけが唯一の強みであってはならないモデルは製品ではない、そのモデルを取り巻くシステムこそが製品であるモデルを構築しないチームにとって、イノベーションの速いペースは祝福であるコンテキストサイズ、推論能力、価格対価値などの改善を追って最新モデルへ移行し、より良い製品を作れるからだこうした進歩は予測できるほど魅力的である総合すると、モデルはシステムの中で最も持続性の低い構成要素である可能性が高いその代わり、継続的な価値を提供できる部分に努力を集中すべきである Evals: モデル全体でタスク性能を安定して測定するため Guardrails: モデルに関係なく望ましくない出力を防ぐため Caching: モデルを完全に回避することでレイテンシとコストを下げるため Data flywheel: 上記すべての反復的改善を推進するためこれらの構成要素は、生のモデル機能よりも厚い製品品質の堀を築くただし、アプリケーションレイヤーを構築することがリスクなしという意味ではない OpenAIや他のモデルプロバイダーが実用的なエンタープライズソフトウェアを提供しようとしているのに、いずれ切り取られる部分を自分で作り込んではならない例えば、一部のチームは独自モデルの構造化出力を検証するためのカスタムツール構築に投資してきたここへの最小限の投資は重要だが、深く投資するのは時間の有効活用ではない OpenAIは、関数呼び出しを要求したときに有効な関数呼び出しを返せるようにすべきである。すべての顧客がそれを望むからだここでは「戦略的先送り」を適用し、絶対に必要なものだけを構築し、プロバイダーの機能拡張を待つべきである小さく始めて信頼を得るすべての人にとっての何でも屋になろうとする製品を作るのは、凡庸さへのレシピである説得力のある製品を作るには、企業はユーザーが繰り返し戻ってくるような粘着性の高い体験を築くことに特化しなければならないユーザーが尋ねるあらゆる質問に答えることを目指す一般的なRAGシステムを考えてみよう専門性が欠けているということは、システムが最新情報を優先したり、ドメイン特化の形式を解析したり、特定タスクのニュアンスを理解したりできないことを意味するその結果、ユーザーは浅く信頼できない体験をすることになり、要件を満たせず離脱してしまうこれを解決するには、特定のドメインとユースケースに集中する必要がある広さより深さを加えることで範囲を絞るべきであるそうすることで、ユーザーの共感を呼ぶドメイン特化ツールを作れる専門化により、システムの機能と限界を率直に伝えられるシステムにできることとできないことを透明に公開することは、自己認識を示し、ユーザーがどこで最も多くの価値を加えられるかを理解する助けとなり、結果として出力に対する信頼と確信を築く LLMOpsを作るが、適切な理由を持つこと: 迅速な反復 DevOpsは本質的に、再現可能なワークフローやシフトレフト、あるいは2枚のピザチームへの権限委譲のことではない。YAMLファイルを書くことではなおさらない DevOpsとは、作業とその結果のあいだのフィードバックサイクルを短縮し、エラーではなく改善が蓄積されるようにすることだそのルーツはリーンスタートアップ運動を通じてリーン生産方式とトヨタ生産方式にさかのぼり、シングルミニッツ段取り替えとカイゼンを重視する MLOpsはDevOpsの形をMLに適用したものだった再現可能な実験や、モデル構築者がデプロイできるよう権限を与えるオールインワンのツール群がある。YAMLファイルも大量にあるしかし業界全体として、MLOpsはDevOpsの機能を取り入れなかった。モデルと本番環境での推論・相互作用のあいだのフィードバックギャップを縮めなかった幸いにも、LLMOps分野はプロンプト管理のような些末な問題から離れ、反復を妨げる難しい問題である本番監視と評価へとつながる継続的改善へ方向転換したすでに、チャットモデルやコーディングモデルに対する中立的でクラウドソーシングされた評価のための対話型アリーナがある。これは集団的かつ反復的な改善の外側のループだ LangSmith、Log10、LangFuse、W&B Weave、HoneyHiveなどのツールは、本番環境でのシステム出力に関するデータを収集・整理するだけでなく、開発と深く統合してそのシステムの改善に活用することを約束している。こうしたツールを採用するか、自前で構築しよう買えるLLM機能を作らないこと成功しているビジネスの大半はLLMビジネスではない。同時に、ほとんどのビジネスにはLLMで改善できる機会があるこの2つの観察はしばしばリーダーを誤らせ、コストを増やし品質を下げながら、LLMでシステムを拙速に作り替え、人工的で虚栄心の強い"AI"機能としてリリースさせてしまう。いまや恐れられているキラキラのアイコンの完成だより良い方法がある。製品目標に本当に合致し、中核業務を強化するLLMアプリケーションに集中することだチームの時間を浪費するいくつかの誤った試みを考えてみようビジネス向けのカスタムtext-to-SQL機能を構築する文書と対話できるチャットボットを構築する企業のナレッジベースをカスタマーサポート用チャットボットに統合する上記はいずれもLLMアプリケーションのHello Worldだが、製品企業が自ら構築するのは理にかなわないこれは多くのビジネスに共通する一般的な問題であり、有望なデモと信頼できるコンポーネントのあいだには大きな隔たりがあり、ソフトウェア企業の得意領域だからだ現在のY Combinatorのバッチで大規模に解決されている一般的な問題に、貴重なR&D資源を投じるのは無駄だこれがありきたりなビジネス助言のように聞こえるなら、それは現在の過熱した盛り上がりのなかで、"LLM"というものを最先端で差別化されたものと誤解しやすく、すでに陳腐化したアプリケーションを見落としやすいからだ AIをループに入れ、人間を中心に置くこと現在のLLMベースのアプリケーションは脆弱だ。膨大な量のセーフガードと防御的エンジニアリングを必要とするが、それでも予測しにくい。しかも、厳密にスコープを定めれば、こうしたアプリケーションは非常に有用になりうる。つまり、LLMはユーザーのワークフローを加速する優れたツールになれるということだ LLMベースのアプリケーションがワークフローを完全に置き換えたり、職務機能を代替したりする姿を想像したくなるかもしれないが、今日もっとも効果的なパラダイムは人間とコンピュータのケンタウロス（Centaur chess）だ有能な人間が、自身の迅速な活用のために調整されたLLM機能と組み合わされることで、作業をこなす生産性と満足感は大きく向上しうる LLMの代表的なアプリケーションの1つであるGitHub CoPilotは、このワークフローの力を実証した "全体として、開発者はGitHub CopilotとGitHub Copilot Chatを使うと、コーディングがより簡単になり、エラーが減り、可読性が高く、再利用しやすく、簡潔で、保守しやすく、堅牢になると感じたと述べています。" - Mario Rodriguez, GitHub 長らくMLに携わってきた人は、"human-in-the-loop"という考えにすぐ飛びつきがちだが、そう急がないこと HITL機械学習は、MLモデルが想定どおりに動作することを保証する人間の専門家に基づくパラダイムだここで提案しているのは、関連はしていても、よりニュアンスのあるものだ。LLMベースのシステムは、今日のほとんどのワークフローの主な駆動力であるべきではなく、単なるリソースであるべきだ人間を中心に置き、LLMがどのようにワークフローを支援できるかを問うことは、製品と設計の意思決定にかなり異なる影響をもたらす最終的には、あらゆる責任を素早くLLMに丸投げしようとする競合とは異なる製品、つまりより良い製品、より有用でよりリスクの低い製品を作ることになる戦略3. プロンプティング、Eval、データ収集から始める前のセクションでは、技術と助言を大量に投入した。受け止めるにはかなり多い。役に立つ助言の最小セットを考えてみようチームがLLM製品を作りたいなら、どこから始めるべきだろうか？この1年で、成功するLLMアプリケーションは一貫した軌跡をたどることを確信できるほど十分に見てきた。このセクションでは、この基本的な"始め方"のプレイブックを見ていく核心となるアイデアは、シンプルに始めて、必要に応じて複雑さを加えることだ Rule of Thumb: 洗練度の各レベルには、一般に前の段階より少なくとも1桁多い労力が必要になる。これを念頭に置いて…… プロンプトエンジニアリングが最優先まずはプロンプトエンジニアリングから始めること以前に戦術セクションで議論したすべての技法を使うこと Chain-of-thought、n-shot例、構造化された入出力はほとんど常に良いアイデアだ性能の低いモデルから性能を絞り出そうとする前に、もっとも高性能なモデルでプロトタイプを作ることプロンプトエンジニアリングで望む性能水準を達成できない場合にのみ、ファインチューニングを検討すべきだ独自モデルの利用を妨げ、自前ホスティングを要求する非機能要件（例: データプライバシー、完全な制御、コスト）がある場合には、より頻繁にそうなる同じプライバシー要件が、ファインチューニングのためのユーザーデータ利用まで妨げないよう注意すること評価を作り、データフライホイールを始動する立ち上げたばかりのチームにも評価（evals）は必要だ。そうでなければ、プロンプトエンジニアリングで十分なのか、あるいはファインチューニングしたモデルがベースモデルを置き換える準備ができているのか分からない効果的な評価はタスクに特化しており、意図したユースケースを反映している最初のレベルとして推奨する評価はユニットテストだこうした単純なアサーションは、既知または仮説上の失敗モードを検出し、初期の設計判断を下す助けになる分類、要約などの他のタスク別評価も参照することユニットテストやモデルベース評価は有用だが、人間による評価の必要性を置き換えるものではない実際に人々にモデルや製品を使ってもらい、フィードバックを提供してもらうことこれは、実際の性能と欠陥率を測定すると同時に、将来モデルをファインチューニングするために使える高品質なアノテーションデータを収集するという二重の目的を果たすこれは時間とともに複利で効く正のフィードバックループ、すなわちデータフライホイールを生み出すモデル性能を評価したり欠陥を見つけたりするための人間評価アノテーションデータを使ってモデルをファインチューニングする、あるいはプロンプトを更新する反復するたとえば、LLMが生成した要約の欠陥を監査する際、各文に対して事実不一致、無関係、あるいはスタイル不良を識別する細粒度のフィードバックラベルを付けられるその後、こうした事実不一致の注釈を使ってハルシネーション分類器を学習させたり、関連性の注釈を使って関連性報酬モデルを学習させたりできる LinkedInは、ハルシネーション、責任あるAI違反、一貫性などを推定するためにモデルベース評価者を用いた成功事例を共有している時間とともに価値が増す資産を生み出すことで、評価（evals）の構築を単なる運用コストから戦略的投資へと変え、その過程でデータフライホイールを構築する戦略4. 低コストな認知の高次トレンド（The high-level trend of low-cost cognition） 1971年、Xerox PARCの研究者たちは、私たちが今生きているネットワーク接続されたパーソナルコンピュータの世界を予測していた彼らは、それを可能にした技術（Ethernet、グラフィックレンダリング、マウス、ウィンドウなど）の発明に中核的な役割を果たすことで、その未来を生み出すことに貢献した彼らはまた、単純な演習も行っていた非常に有用だが（例：ビデオディスプレイ）、まだ経済的ではない（ビデオディスプレイを駆動するのに十分なRAMが数千ドルする）アプリケーションを検討したその後、その技術の歴史的な価格トレンド（ムーアの法則に類似）を調べ、その技術がいつ経済的になるかを予測した LLM技術についても同じことができる。ドル当たりのトランジスタ数ほどきれいではないにせよ長年使われてきた人気ベンチマーク（例：Massively-Multitask Language Understandingデータセット）と、一貫した入力手法（5-shotプロンプティング）を選ぶそして、時間の経過に伴って、このベンチマークでさまざまな性能水準を持つ言語モデルを実行するコストを比較する一定コストで見れば能力は急速に向上している。一定の能力水準で見ればコストは急速に低下している OpenAIのdavinciモデルがAPIとして公開されてからの4年間で、100万トークン（この文書約100部相当）の規模において、そのタスクに相当する性能を持つモデルを実行するコストは20ドルから10セント未満にまで低下した。半減期はわずか6か月である同様に、2024年5月時点でAPIプロバイダー経由または自前でMetaのLLaMA 3 8Bを実行するコストは100万トークン当たりわずか20セントであり、ChatGPTを可能にしたモデルであるOpenAIの text-davinci-003 と同等の性能を示しているこのモデルは、2023年11月末のリリース時点でも100万トークン当たり約20ドルかかっていた。わずか18か月で二桁の差がついた。これはムーアの法則が予測する単純な2倍化と同じ期間であるでは、非常に有用だが（Park et alのような生成型ビデオゲームキャラクターの駆動）、まだ経済的ではない（1時間当たりのコストが625ドルと推定される）LLMアプリケーションを考えてみようこの論文が2023年8月に発表されて以来、コストは約1桁下がって1時間当たり約62.50ドルになっている 9か月後には1時間当たり6.25ドルまで下がると予想できる一方、Pac-Manが1980年に発売されたとき、今日の1ドルで数分から数十分プレイできるクレジットを買うことができた。これを1時間当たり6ゲーム、または1時間当たり6ドルとしようこのざっくり計算は、魅力的なLLM強化ゲーム体験が2025年ごろには経済的に成立することを示唆しているこうしたトレンドは新しく、まだ数年しか経っていない。しかし、今後数年間でこのプロセスが鈍化すると期待すべき理由はほとんどないパラメータ当たり約20トークンという「Chinchilla比率」を超えるスケーリングのような、アルゴリズムやデータセットにおける取りやすい果実を使い切ったとしても、データセンター内部やシリコン層でのより深いイノベーションと投資がそのギャップを埋めるだろうそして、これがおそらく最も重要な戦略的事実である今日ではまったく実用不可能なフロアデモや研究論文が、数年後にはプレミアム機能となり、その直後にはコモディティになるだろうそのことを念頭に置いて、システムと組織を構築しなければならない [0から1へ進むデモは、もはや十分だ。これからは1からNへ進むプロダクトを作るとき] LLMデモを作るのは本当に楽しい。数行のコード、ベクターデータベース、慎重に書かれたプロンプトで「魔法」を生み出せるこの1年、この魔法はインターネット、スマートフォン、さらには印刷術にまで比較されてきた残念ながら、実際のソフトウェアリリース作業を経験したことがある人なら誰でも知っているように、制御された環境で動くデモと、大規模に安定動作するプロダクトの間には巨大な隔たりがある想像してデモを作るのは簡単でも、プロダクトにするのが非常に難しい問題は数多くある例えば自動運転。車が1ブロックを自動運転するのを実演するのは簡単だが、それをプロダクトにするには10年かかる - Andrej Karpathy 自動運転車を例にしてみよう 1988年、ニューラルネットワークで運転される最初の自動車が登場した 25年後、Andrej KarpathyはWaymoで最初のデモライドを体験したその10年後、同社は無人運転の認可を取得したプロトタイプから商用製品になるまでの35年間、厳格なエンジニアリング、テスト、改善、規制対応が積み重ねられた産業界と学術界の全体にわたって、この1年間の浮き沈みを観察してきた：LLMアプリケーションの1年目（Year 1 of N for LLM applications）評価、プロンプトエンジニアリング、ガードレールのような戦術から、運用スキル、チーム作り、どの機能を内製するかの選定といった戦略的観点に至るまで、私たちが学んだ教訓が2年目以降に役立つことを願っているこの刺激的な新技術を、ともに前進させていけることを楽しみにしている

(eugeneyan.com)

75 ポイント投稿者 xguru 2024-06-10 | 9件のコメント | WhatsAppで共有

大規模言語モデル（LLM）を用いた開発は、いま非常に興味深い時期にある
- この1年で、LLMは実用アプリケーションにおいて「十分に良い」水準に達し、毎年より高性能になり、より低コストになっている
- ソーシャルメディア上のデモとあわせて、2025年までにAIへ約2,000億ドルが投資されると見積もられている
- 各社のAPIによりLLMへのアクセスが容易になり、MLエンジニアや研究者だけでなく、誰もが製品にインテリジェンスを組み込めるようになった
AIで構築するための参入障壁は下がったが、デモを超えて実際に効果的な製品やシステムを作ることは依然として難しい
私たちはこの1年間にわたって構築を続け、その過程で多くの困難を発見してきた
- 私たちの失敗を避け、より速く反復できるように、学んだことを共有したい
この記事は3つのパートで構成される:
1. Tactical（戦術）: プロンプティング、RAG、ワークフローエンジニアリング、評価、モニタリングに関する実践事項
  - LLMで構築する実務者や週末プロジェクトに取り組む人向けに書かれている
2. Operational（運用）: 製品リリースにおける組織的・日常的な関心事と、効果的なチーム構築の方法
  - 持続可能かつ安定的にデプロイしたい製品・技術リーダー向けの内容
3. Strategic（戦略）: 「PMF前にGPUなし」「モデルではなくシステムに集中する」といった見解を含む、長期的で大局的な視点と反復の方法
  - 創業者や経営陣を念頭に置いて書かれている
このガイドは、LLMを使って成功する製品を構築するための実践的な案内書となることを目指している
- 私たち自身の経験に基づいており、業界全体の事例を示している

[戦術: LLM利用の核心]

このセクションでは、新たに登場しつつあるLLMスタックの中核コンポーネントに関するベストプラクティスを共有する
- 品質と信頼性を高めるためのプロンプティングのコツ、出力を評価するための戦略、グラウンディングを改善するための検索拡張生成のアイデアなどを含む
- また、Human-in-the-Loopワークフローをどう設計するかについても掘り下げる予定である

戦術1. プロンプティング

新しいアプリケーションを開発するときは、まずプロンプティングから始めることを勧める
- プロンプティングの重要性は過小評価も過大評価もしやすい
- 適切なプロンプティング技法を正しく使えば非常に大きな成果を得られるため、過小評価されがちである
- 一方で、プロンプトベースのアプリケーションも正しく動かすには、プロンプトの周辺に相当なエンジニアリングが必要になるため、過大評価されがちでもある

基本的なプロンプティング技法を最大限活用することに集中する

さまざまなモデルやタスクで、継続的に性能向上に役立ついくつかのプロンプティング技法がある
- N-shotプロンプト + コンテキスト内学習、Chain-of-Thought、関連リソースの提供などである
N-shotプロンプトとコンテキスト内学習
- N-shotプロンプトによるコンテキスト内学習の考え方は、LLMにタスクを実演し、期待に沿う出力の例をいくつか与えることにある
- Nが低すぎると、モデルがその特定の例に過度に引きずられ、汎化能力が低下する可能性がある
- 経験的には N ≥ 5 を目標にし、数十件使うこともためらわないこと
- 例は、想定される入力分布を代表しているべきである
- 入出力の完全なペアを与える必要はなく、多くの場合は望ましい出力例だけで十分である
- ツール利用をサポートするLLMを使う場合、N-shotの例でもエージェントに使ってほしいツールを実際に使うべきである
Chain-of-Thought（CoT）プロンプティング
- CoTプロンプティングでは、LLMが最終回答を返す前に思考過程を説明するよう促す
- これは、LLMがすべてをメモリ内だけで処理しなくて済むように、スケッチパッドを与えるものと考えられる
- 元々のアプローチは、単に「段階的に考えてみよう」という文言を指示の一部として加えることだったが、CoTをより具体的にすることが有効だと分かってきた
- 1〜2文で具体性を加えると、幻覚の発生率が大きく下がる場合が多い
- 最近では、この技法が信じられているほど強力なのかという疑問も提起されている
- また、CoTが使われる際に推論中に実際に何が起きているのかについても、かなり議論がある
- それでも、可能であれば試してみる価値のある技法である
関連リソースの提供
- 関連リソースを提供することは、モデルの知識基盤を拡張し、幻覚を減らし、ユーザーの信頼を高める強力なメカニズムである
- 多くの場合、検索拡張生成（Retrieval Augmented Generation, RAG）を通じて行われる
- モデルに、応答へ直接活用できるテキストスニペットを提供することは不可欠な技術である
- 関連リソースを提供する際は、単に含めるだけでは不十分である
  - モデルに対して、リソースの利用を優先し、直接参照し、ときにはリソースが十分でない場合はその旨を述べるよう指示することを忘れてはならない
- これらは、エージェントの応答をリソースコーパスに「グラウンド」させるのに役立つ

入力と出力を構造化する

構造化された入力と出力は、モデルが入力をよりよく理解し、ダウンストリームシステムと安定して統合できる出力を返すのに役立つ
- 入力にシリアライズ形式を追加すると、コンテキスト内のトークン間の関係、特定トークンに関する追加メタデータ（型など）、あるいは要求をモデルの学習データ中の類似例と結び付ける助けになる場合がある
- たとえば、インターネット上でSQL作成についての多くの質問は、SQLスキーマの指定から始まる
  - したがって、Text-to-SQLに対する効果的なプロンプティングには、構造化されたスキーマ定義を含めるべきである
構造化された出力も同様の目的を果たすが、システムのダウンストリーム構成要素との統合を簡素化する
- Instructor と Outlines は構造化出力でうまく機能する
  - （LLM API SDKを使う場合は Instructor、自前でホストするモデルに Huggingface を使う場合は Outlines を使う）
- 構造化された入力は、タスクを明確に表現し、学習データの形式にも似ているため、より良い出力が得られる可能性を高める
構造化入力を使う際は、各LLMファミリーごとに好む方式がある点に注意すべきである
- Claude は <xml> を好む一方、GPT は Markdown と JSON を好む
- XMLを使うと、<response> タグを与えて Claude の応答を事前入力することもできる

小さく、1つのことをうまくこなすプロンプトを作る

ソフトウェアでよくあるアンチパターン／コードスメルに、「すべてをこなす単一のクラスや関数」である「God Object」がある
- これはプロンプトにも同じように当てはまる
プロンプトは通常、シンプルに始まる
- 数文の指示と、いくつかの例から始められる
- しかし、性能を改善し、より多くのエッジケースに対応しようとするうちに複雑さが増していく
  - さらに多くの指示、多段階の推論、数十個の例などが追加される
- その結果、当初は単純だったプロンプトが、2,000トークンのフランケンシュタインになってしまう
  - しかも、より一般的で直感的な入力に対する性能はむしろ低下する
  - GoDaddy はこの問題を、LLM構築から得た教訓の第1位に挙げている
システムやコードをシンプルに保とうとするのと同様に、プロンプトもそうあるべきである
- 会議文字起こしの要約器に単一の万能プロンプトを使う代わりに、次のような段階に分けられる
  - 主要な決定事項、アクションアイテム、担当者を構造化形式で抽出する
  - 抽出した詳細を元の文字起こしと照合して一貫性を確認する
  - 構造化された詳細から簡潔な要約を生成する
その結果、1つのプロンプトを複数のシンプルで焦点が明確かつ理解しやすいプロンプトに分割することになる
- このように分割すれば、各プロンプトを個別に反復し、評価できるようになる

コンテキストトークンを作る

エージェントに実際に送る必要があるコンテキスト量についての前提を見直し、疑ってかかるべきである
- ミケランジェロのようにコンテキストの彫像を作り上げていくのではなく、不要な素材を削ぎ落として彫像を浮かび上がらせるべきである
- RAGは、潜在的に関連する大理石の塊をすべて集めるための一般的な手法だが、必要なものを抽出するために何をしているだろうか?
モデルに送られる最終プロンプトを取り出し、すべてのコンテキスト構成、メタプロンプティング、RAGの結果とともに空白のページに置いて読んでみることが、コンテキストの見直しに役立つと分かった
- この方法を使うと、重複、自己矛盾する表現、形式が不適切な部分を見つけられる
もう1つの重要な最適化はコンテキストの構造である
- Bag-of-docs表現は人間にとって有用ではないのだから、エージェントにとっても良いと安易に仮定すべきではない
- コンテキストの各部分の関係を強調し、抽出をできるだけ単純にできるよう、コンテキストをどう構成するかを慎重に検討すべきである

戦術2. 情報検索 / RAG

プロンプティングに加えて、LLMを調整するもう1つの効果的な方法は、プロンプトの一部として知識を提供することである
- これは与えられたコンテキストにLLMをグラウンディングするもので、インコンテキスト学習に用いられる
- これを検索拡張生成(Retrieval-Augmented Generation, RAG)と呼ぶ
- 実務家たちは、RAGが知識を提供し出力を改善するうえで効果的であり、ファインチューニングと比べてはるかに少ない労力とコストで済むことを見いだしている
- RAGの良し悪しは、検索された文書の関連性、情報密度、詳細さに左右される

RAG出力の品質は検索された文書の品質に依存し、いくつかの要素を考慮できる

1つ目で最も明白な指標は「関連性」である
- これは通常、平均逆順位(Mean Reciprocal Rank, MRR)や正規化割引累積利得(Normalized Discounted Cumulative Gain, NDCG)のようなランキング指標で定量化される
- MRRは、システムが順位リストの中で最初の関連結果をどれだけうまく配置できるかを評価する一方、NDCGはすべての結果の関連性と位置を考慮する
- これらは、関連文書をより上位に、無関係な文書をより下位にランク付けするシステムの性能を測定する
- たとえば、映画レビューの要約を生成するためにユーザー要約を検索する場合、特定の映画に対するレビューをより上位にランク付けし、別の映画に対するレビューは除外するのが望ましい
- 従来の推薦システムと同様に、検索された項目の順位は、LLMがダウンストリームのタスクをどのように実行するかに大きな影響を与える
- 影響を測定するには、検索結果をシャッフルした状態でRAGベースのタスクを実行し、RAGの出力がどう変化するかを確認するとよい
2つ目は「情報密度」である
- 2つの文書が同程度に関連しているなら、より簡潔で無関係な詳細が少ない文書を優先すべきである
- 映画の例に戻ると、映画の脚本とすべてのユーザーレビューは、広い意味では関連していると見なせる
- それでも、高評価のレビューや編集レビューのほうが情報密度は高い可能性がある
最後に、文書で提供される「詳細度」を考慮すべきである
- 自然言語からSQLクエリを生成するRAGシステムを構築すると想像してみよう
  - 列名のあるテーブルスキーマをコンテキストとして提供するだけでも十分かもしれない
  - しかし、列の説明やいくつかの代表値も含めたらどうだろうか?
- 追加の詳細情報は、LLMがテーブルの意味をよりよく理解し、より正確なSQLを生成する助けになる可能性がある

キーワード検索を忘れず、ベースラインとハイブリッド検索に使うこと

EmbeddingベースのRAGデモが広く出回っているため、情報検索分野における数十年分の研究とソリューションを忘れたり見落としたりしがちである
- それでも、埋め込みが強力なツールであることは間違いないが、万能ではない
キーワードベース検索の利点
- 第1に、埋め込みは高レベルの意味的類似性を捉えるのに優れているが、ユーザーが名前(例: Ilya)、頭字語(例: RAG)、またはID(例: claude-3-sonnet)を検索するときのような、より具体的でキーワードベースのクエリには苦戦することがある
  - BM25のようなキーワードベース検索は、このために明示的に設計されている
  - ユーザーは長年キーワード検索を使ってきたため、それを当然のものと考えており、探している文書が返ってこなければ不満を感じる可能性がある
- 第2に、キーワード検索のほうが、なぜ文書が検索されたのかを理解しやすい
  - クエリに一致したキーワードを確認できるためである
  - 一方で、埋め込みベース検索は解釈可能性が低い
- 第3に、LuceneやOpenSearchのような、数十年にわたり最適化され実運用で検証されてきたシステムのおかげで、キーワード検索のほうが一般に計算効率が高い
ほとんどの場合、ハイブリッドアプローチが最も効果的である
- 明白な一致にはキーワードマッチングを使い、同義語、上位語、スペルミス、マルチモーダル(例: 画像とテキスト)には埋め込みを使う
- Shortwaveは、クエリ書き換え、キーワード + 埋め込み検索、ランキングなど、自社のRAGパイプラインをどのように構築したかを共有している

新しい知識についてはファインチューニングよりRAGを優先する

RAGとファインチューニングはどちらも、新しい情報をLLMに統合し、特定タスクでの性能を向上させるために使える
- では、まずどちらを試すべきだろうか?
RAGの利点
- 最近の研究によれば、RAGのほうが優れている可能性がある
- ある研究では、RAGと教師なしファインチューニング(継続事前学習とも呼ばれる)を、MMLUと時事問題のサブセットで評価して比較した
  - RAGは、学習中に触れた知識と完全に新しい知識の両方において、ファインチューニングより一貫して高い性能を示した
- 別の論文では、農業データセットについてRAGと教師ありファインチューニングを比較した
  - 同様に、RAGの性能向上はファインチューニングより大きく、特にGPT-4で顕著だった(論文の表20を参照)
- 性能向上に加えて、RAGにはいくつかの実務上の利点がある
  - 第1に、継続事前学習やファインチューニングと比べて、検索インデックスを最新の状態に保つほうが容易で安価である
  - 第2に、検索インデックスに有害または偏った内容を含む問題のある文書がある場合、その文書を容易に削除または修正できる
- また、RAGのRは文書をどのように検索するかについて、よりきめ細かな制御を提供する
  - たとえば複数の組織向けにRAGシステムをホスティングする場合、検索インデックスを分割し、各組織が自分たちのインデックス内の文書だけを検索できるようにできる
  - これにより、ある組織の情報を誤って別の組織に露出させることを防げる

長文コンテキストモデルがRAGを無用にすることはない

Gemini 1.5 が最大 1,000万トークンのコンテキストウィンドウを提供するようになり、一部では RAG の未来に疑問を抱き始めている
- 1,000万トークンのコンテキストウィンドウは、従来の RAG フレームワークの大半を不要にする
  - データをコンテキストに入れて、いつもどおりモデルと対話するだけでよい
- これが、エンジニアリング上の努力の大半を RAG に注ぎ込んでいるスタートアップ、エージェント、langchain プロジェクトにどのような影響を与えるか想像してみてほしい
  - 一言で言えば、1,000万コンテキストが RAG を殺すということだ
  広告
RAG が引き続き必要とされる理由
- 長大なコンテキストが複数文書の分析や PDF とのチャットといったユースケースでゲームチェンジャーになるのは事実だが、RAG の終焉に関する噂は大きく誇張されている
  - 第一に、1,000万トークンのコンテキストウィンドウがあっても、なおモデルに入力する情報を選ぶ方法が必要である
  - 第二に、狭い needle-in-a-haystack 評価を超えて、モデルがそれほど大きなコンテキストに対して効果的に推論できることを示す説得力あるデータは、まだ見たことがない
  - したがって、優れた検索（およびランキング）がなければ、注意を散らす情報でモデルを圧倒したり、さらには完全に無関係な情報でコンテキストウィンドウを埋め尽くしたりする危険がある
最後に、コストの問題がある
- Transformer の推論コストは、コンテキスト長に応じて二乗で増加する（あるいは空間と時間の両方で線形に増加する）
- 組織全体の Google Drive の内容を読めるモデルが存在するとしても、各質問に答える前に毎回そうするのがよい考えとは限らない
- RAM の使い方に関する比喩を考えてみよう
  - 数十テラバイト級の RAM を持つコンピューティングインスタンスは存在するが、それでもなおディスクへの読み書きを行っている
したがって、まだ RAG をゴミ箱に捨てないこと
- このパターンは、コンテキストウィンドウのサイズが大きくなっても依然として有用であり続けるだろう

戦術 3. ワークフローのチューニングと最適化

LLM にプロンプトを与えることは、始まりにすぎない
- LLM を最大限活用するには、単一のプロンプトを超えてワークフローを受け入れる必要がある
- たとえば、複雑な単一タスクをどのように複数のより単純なタスクに分割できるだろうか？
- ファインチューニングやキャッシングが、性能向上とレイテンシ／コスト削減に役立つのはいつだろうか？
このセクションでは、実証済みの戦略と実例を共有し、LLM ワークフローの最適化と構築に役立てる

段階的なマルチターンの「Flow」は大きな性能向上をもたらしうる

1つの大きなプロンプトを複数の小さなプロンプトに分解することで、より良い結果が得られることはすでに知られている
- AlphaCodium がその例である
  - 単一プロンプトから多段階ワークフローへ移行することで、CodeContests における GPT-4 の精度（pass@5）を 19% から 44% へ引き上げた
- ワークフローには次が含まれる
  - 問題についての熟考
  - 公開テストに対する推論
  - 可能な解法の生成
  - 可能な解法の順位付け
  - 合成テストの生成
  - 公開テストおよび合成テストに対する解法の反復
明確な目標を持つ小さなタスクは、最良のエージェントまたはフロープロンプトを作る
- すべてのエージェントプロンプトが構造化出力を要求する必要はないが、構造化出力は、エージェントの環境との相互作用を調整するシステムとのインターフェースとして大いに役立つ
試してみる価値のあること
- できる限り厳密に定義された明示的な計画ステップ
  - あらかじめ定義された計画の中から選ぶことも検討するとよい
- 元のユーザープロンプトをエージェントプロンプトに書き換える
  - この過程では情報損失が発生するため、注意が必要である
- 線形チェーン、DAG、および状態機械としてのエージェント動作
  - さまざまな依存関係や論理関係は、異なるスケールに対して向き不向きがありうる
  - さまざまなタスクアーキテクチャで性能最適化を引き出せるだろうか？
- 計画の検証
  - 計画には、最終成果物がうまく機能するように他のエージェントの応答を評価する方法に関する指示を含めることができる
- 固定されたアップストリーム状態を前提としたプロンプトエンジニアリング
  - エージェントプロンプトが、以前に発生しうるさまざまなバリエーションに対して評価されていることを確認すること

現時点では決定論的ワークフローを優先すること

AI エージェントはユーザーの要求と環境に動的に反応できるが、その非決定論的な特性はデプロイを難しくする
- エージェントが実行する各ステップは失敗する可能性があり、エラーから回復できる可能性は低い
- したがって、エージェントが多段階タスクを成功裏に完了できる確率は、ステップ数が増えるにつれて幾何級数的に低下する
- その結果、エージェントを構築するチームは、信頼できるエージェントを本番投入することに苦労する
有望なアプローチは、決定論的な計画を生成し、それを構造化され再現可能な方法で実行するエージェントシステムを持つことである
- 最初の段階では、上位レベルの目標またはプロンプトが与えられると、エージェントが計画を生成する
- その後、計画は決定論的に実行される
- これにより、各ステップをより予測可能かつ信頼性の高いものにできる
- 利点
  - 生成された計画は、エージェントにプロンプトを与えたりファインチューニングしたりするための few-shot サンプルとして利用できる
  - 決定論的な実行はシステムの信頼性を高め、テストとデバッグを容易にする。また、失敗を計画の特定ステップまで追跡できる
  - 生成された計画は有向非巡回グラフ（DAG）として表現でき、静的プロンプトに比べて理解しやすく、新しい状況にも適応しやすい
最も成功しているエージェント構築者は、ジュニアエンジニアのマネジメント経験が豊富な人かもしれない
- 計画生成プロセスは、ジュニアを指導・管理するやり方と似ているためである
- ジュニアに曖昧でオープンエンドな指示ではなく、明確な目標と具体的な計画を与えるのと同様に、エージェントにも同じことをすべきである
結局のところ、信頼できて実際に機能するエージェントの核心は
- より構造化され、より決定論的なアプローチを採用すること、
- そして、プロンプトを改善しモデルをファインチューニングするためのデータを収集することに見いだされる可能性が高い
これがなければ、ときには非常によく動作しても、平均的にはユーザーを失望させ、定着率を低下させるエージェントを構築することになるだろう

温度パラメータ以上に多様な出力を得る

LLM の出力に多様性が必要なタスクがあると仮定しよう
- ユーザーが過去に購入した製品の一覧を考慮し、カタログから購入すべき製品を提案する LLM パイプラインを書いているかもしれない
- プロンプトを何度も実行すると、推薦結果があまりにも似通っていることに気づくかもしれない
- そこで、LLM リクエストの Temperature（温度）パラメータを上げることができる
温度パラメータを上げると、LLM の応答はより多様になる
- サンプリング時に次トークンの確率分布がより平坦になり、通常は選ばれにくいトークンがより頻繁に選ばれるようになる
しかし、温度を上げると、出力の多様性に関するいくつかの失敗モードが発生しうる
- たとえば、カタログ内の一部製品は適切であっても、LLM によって出力されないことがある
- LLM が学習時に学んだ内容に基づいてプロンプトに従う可能性が高い場合、同じ少数の製品が出力で過剰に代表されることがある
- 温度が高すぎると、存在しない製品（あるいは意味のない内容）を参照する出力が生成されることがある
温度を上げたからといって、LLM が想定どおりの確率分布（たとえば一様ランダム）から出力をサンプリングする保証はない
それでも、出力の多様性を高めるための別の工夫がある
- 最も簡単な方法は、プロンプト内の要素を調整すること
  - たとえば、プロンプトテンプレートに過去の購入履歴のような項目一覧が含まれている場合、それらの項目をプロンプトに挿入するたびに順序をシャッフルすれば、かなりの違いを生み出せる
- また、最近の出力の短いリストを保持しておくと、重複の防止に役立つ
  - 推薦製品の例では、LLM に対してこの最近のリストにある項目の提案を避けるよう指示したり、最近の提案と似た出力を拒否して再サンプリングしたりすることで、応答をさらに多様化できる
- もう1つの効果的な戦略は、プロンプトで使う表現を多様化することである
  - たとえば「ユーザーが定期的に使いたくなる項目を選ぶ」や「ユーザーが友人に勧める可能性が高い製品を選ぶ」といった文言を組み込むと、焦点が移り、推薦製品の多様性に影響を与えられる

キャッシングは過小評価されている

キャッシュは、同一入力に対する応答を再計算する必要をなくすことでコストを削減し、生成レイテンシをなくす
- また、応答が以前にガードレール適用済みであれば、こうした検証済みの応答を返すことで、有害または不適切なコンテンツを提供するリスクを減らせる
キャッシュへのシンプルなアプローチは、新しい記事や製品レビューを要約する場合のように、処理対象の項目に一意のIDを使うこと
- リクエストが来たら、要約がすでにキャッシュ内に存在するか確認できる
  - 存在するなら即座に返せるし、存在しないなら生成し、ガードレールを適用して提供したうえで、将来のリクエストに備えてキャッシュに保存できる
もう少しオープンエンドなクエリでは、オープンエンドな入力に対してもキャッシュを活用する検索分野の技術を借用できる
- オートコンプリートやスペル修正のような機能は、ユーザー入力を正規化してキャッシュヒット率を高めるのに役立つ

finetune（ファインチューニング）が必要になる時点

どれほど巧妙に設計されたプロンプトでも不十分なタスクがある
- たとえば、かなりのプロンプトエンジニアリングを行っても、システムが依然として信頼できる高品質な出力を返すには程遠い場合がある
- この場合、特定のタスク向けにモデルをファインチューニングする必要があるかもしれない
ファインチューニングが成功した事例
- HoneycombのNatural Language Query Assistant
  - 当初は「プログラミングマニュアル」が、コンテキスト内学習のためのn-shot例とともにプロンプトへ提供されていた
  - これでも適切に機能したが、モデルをファインチューニングすると、ドメイン固有言語の構文やルールに関してより良い出力を得られる
- RechatのLucy
  - LLMは、フロントエンドが正しくレンダリングするために、構造化データと非構造化データを組み合わせた非常に特定の形式で応答を生成しなければならない
  - ファインチューニングは、これを一貫して機能させるうえで不可欠である
ファインチューニングは効果的な場合があるが、かなりのコストを伴う
- ファインチューニング用データにアノテーションを付け、モデルをファインチューニングして評価し、最終的には自前でホスティングしなければならない
- そのため、より高い初期コストに見合う価値があるかを検討する必要がある
プロンプティングで90%まで到達できるなら、ファインチューニングに投資する価値はないかもしれない
- ただし、ファインチューニングすると決めたなら、人手で注釈を付けたデータの収集コストを減らすために、合成データを生成してファインチューニングしたり、オープンソースデータでブートストラップしたりできる

戦術 4. 評価とモニタリング

LLMの評価は地雷原になり得る
- LLMの入力と出力は任意のテキストであり、設定するタスクも多様である
- それでも、厳密で慎重な評価は重要である
  - OpenAIの技術リーダーたちが評価に関わり、個々の評価にフィードバックを与えているのは偶然ではない
LLMアプリケーションの評価には、さまざまな定義と切り詰め方が必要になる
- 単なるユニットテストかもしれないし、可観測性に近いものかもしれないし、単なるデータサイエンスかもしれない
- 私たちは、これらすべての観点が有用であることを見いだした
このセクションでは、評価およびモニタリングのパイプライン構築で重要な点について学んだ教訓を紹介する

実際の入出力サンプルから、いくつかのassertionベースのユニットテストを作成する

本番環境の入力と出力のサンプルから成るユニットテスト（つまりassertion）を作成し、少なくとも3つの基準に従って出力への期待値を設定する
- 3つという基準は恣意的に見えるかもしれないが、始めるには実用的な数である
  - これより少ないなら、タスクの定義が十分でないか、汎用チャットボットのようにオープンすぎる可能性がある
- こうしたユニットテストまたはassertionは、プロンプトの編集、RAGによる新しいコンテキストの追加、その他の修正といったパイプラインの変更によってトリガーされるべきである
まずは、すべての応答に含めるべき、あるいは含めてはならない語句やアイデアを指定するassertionから始めることを検討する
- また、単語数、項目数、文数が範囲内かを確認するチェックも検討する
- 他の種類の生成では、assertionの形も異なる場合がある
  - たとえばコード生成を評価する強力な方法である実行評価では、生成されたコードを実行し、ランタイム状態がユーザーの要求に十分応えているか確認する
たとえば、ユーザーがfooという新しい関数を要求したなら、エージェントが生成したコードを実行したあとにfooを呼び出せるはずである
実行評価における課題の1つは、エージェントのコードがしばしば対象コードと少し異なる形でランタイムを残すことだ
- どんな妥当な回答でも満たせる最も弱い仮定へとassertionを「緩める」ことが効果的な場合がある
顧客向けに意図されたとおりに製品を使うこと（つまり「ドッグフーディング」）は、実データにおける障害モードへの洞察を与えてくれる
- このアプローチは潜在的な弱点の特定に役立つだけでなく、評価へ変換できる有用な本番サンプルの供給源にもなる

LLM-as-Judgeは（ある程度）機能し得るが、万能ではない

LLM-as-Judgeは、強力なLLMを使って別のLLMの出力を評価する方式であり、人によっては懐疑的に受け止められている
それでも、うまく実装されれば、LLM-as-Judgeは人間の判断とかなり高い相関を達成でき、少なくとも新しいプロンプトや手法がどのように機能しそうかについて事前情報を築くのに役立つ
- 特にペア比較（例: 対照群 vs 処置群）を行う場合、LLM-as-Judgeは一般に方向性は正しく捉えるが、勝敗の差の大きさにはノイズが入り得る
広告
LLM-as-Judgeを最大限活用するための提案
- ペア比較を使う
  - LLMに単一の出力をLikert尺度で評価させるのではなく、2つの選択肢を提示して、より良いほうを選ばせる
  - このほうが、より安定した結果につながる傾向がある
- 位置バイアスを制御する
  - 提示された選択肢の順序がLLMの判断を偏らせる可能性がある
  - これを緩和するには、各ペア比較を2回実行し、そのたびにペアの順序を入れ替える
  - 入れ替えた後は、正しい選択肢に勝利を帰属させる必要がある
- 引き分けを許容する
  - 場合によっては、2つの選択肢が同じくらい良いこともある
  - したがって、LLMが恣意的に勝者を選ばなくて済むよう、引き分けを宣言できるようにする
- Chain-of-Thoughtを使う
  - 最終的な選好を示す前に、その判断を説明するようLLMに求めると、評価の信頼性が向上する場合がある
  - おまけに、これにより、より弱いが高速なLLMを使っても似た結果を得られる
  - パイプラインのこの部分はしばしばバッチモードで動くため、CoTによる追加レイテンシは問題にならない
- 応答長を制御する
  - LLMはより長い応答に偏る傾向がある
  - これを緩和するには、応答ペアの長さが近いことを確認する
LLM-as-Judgeの特に強力な適用例は、新しいプロンプト戦略に回帰がないか確認することだ
- 本番結果のコレクションを追跡しているなら、新しいプロンプト戦略でその本番サンプルを再実行し、LLM-as-Judgeを使って新しい戦略がどこで苦戦しそうかを素早く評価できる場合がある
LLM-as-Judgeのシンプルだが効果的なアプローチの例
- 単にLLMの応答、ジャッジの批評（つまりCoT）、最終結果を記録する
- その後、関係者とレビューして改善領域を特定する
- 3回の反復を通じて、人間とLLMの一致度は68%から94%へ向上した
しかし、LLM-as-Judgeは万能ではない
- 最も強力なモデルでさえ、信頼して評価できない微妙な言語的側面がある
また、従来の分類器や報酬モデルのほうが、LLM-as-Judgeより高い精度をより低いコストとレイテンシで達成できることも分かった
- コード生成では、LLM-as-Judgeは実行評価のようなより直接的な評価戦略より弱い場合がある

生成結果評価のための「インターンテスト」

生成結果を評価する際には、次のような「インターンテスト」を使うのがよい
- コンテキストを含めた言語モデルへの正確な入力を、関連分野を専攻する平均的な大学生に課題として与えた場合、その学生は成功できるだろうか？
- どれくらい時間がかかるか？
答えがノーの場合
- LLMに必要な知識が不足しているためなら、コンテキストを充実させる方法を検討する
- コンテキストを改善しても解決できないなら、現代のLLMには難しすぎるタスクかもしれない
答えがイエスだが時間がかかる場合
- タスクの複雑さを下げられないか試してみる
  - 分解できるか？
  - タスクのどの側面をよりテンプレート化できるか？
答えがイエスで、しかも素早くできる場合
- データを掘り下げるとき
  - モデルは何を誤っているのか？
  - 失敗のパターンを見つけられるか？
- 応答の前後でモデル自身に説明させてみる

特定の評価に過度に重点を置くと、全体的な性能が低下することがある

「測定指標が目標になると、それはもはや良い測定指標ではなくなる。」 - グッドハートの法則

その例としてNeedle-in-a-Haystack（NIAH）評価がある
- 元の評価は、コンテキストサイズが大きくなるにつれてモデルのリコールを定量化し、針の位置によってリコールがどう影響されるかを確認するのに役立つ
- しかし過度に強調され、Gemini 1.5レポートのFigure 1として紹介された
- この評価では、ポール・グレアムのエッセイを繰り返した長文ドキュメントに特定のフレーズ（"The special magic {city} number is: {number}"）を挿入し、その後モデルにマジックナンバーを思い出させるタスクが含まれる
一部のモデルはほぼ完璧なリコールを達成しているが、NIAHが実際のアプリケーションで必要な推論力やリコール能力を本当に反映しているのかは疑わしい
より実用的なシナリオを考える
- 1時間分の会議録音の文字起こしが与えられたとき、LLMは主要な決定事項と次のアクションを要約し、各項目を適切な担当者に正しくひも付けられるか？
- このタスクは単純な暗記を超え、複雑な議論を把握し、関連情報を特定し、要約を統合する能力も問うため、より現実的である
実用的なNIAH評価の例
- 医師と患者のビデオ通話の文字起こしを使い、LLMに患者の薬について質問する
- エスプレッソに漬けたナツメヤシ、レモン、ヤギのチーズなど、ピザのトッピングに必要なランダムな材料に関するフレーズを挿入する、より挑戦的なNIAHも含まれる
- 薬のタスクではリコールは約80%、ピザのタスクでは30%だった
NIAH評価を過度に重視すると、抽出や要約タスクの性能が下がる可能性がある
- このようなLLMはすべての文に注意を向けるよう微調整されているため、無関係な詳細や気を散らす情報まで重要なものとして扱い始めることがある
- その結果、最終出力に含まれてしまうことがある（含まれるべきでない場合でも！）
これは他の評価やユースケースにも当てはまる
- たとえば要約
  - 事実的一貫性を重視すると、より具体性が低く（したがって事実と一致しない可能性も低い）、関連性に欠ける要約が生成されることがある
  - 逆に文章スタイルや雄弁さを重視すると、事実との不一致を招きうる、より派手なマーケティング調の言語が生成されることがある

アノテーションを二値タスクまたはペアワイズ比較に単純化する

モデル出力に対して自由記述のフィードバックを与えたり、Likert尺度で評価したりするのは認知的負荷が高い
- その結果、収集されたデータは人間評価者間のばらつきによってノイズが増え、有用性が下がる
より効果的なアプローチは、タスクを単純化してアノテーターの認知負荷を減らすこと
- うまく機能する2つのタスクは、二値分類とペアワイズ比較である
二値分類では、アノテーターはモデルの出力について単純なイエス／ノーの判断を求められる
- 生成された要約が元文書と事実的に一致しているか、提案された応答が関連しているか、有害性を含んでいるか、などを問うことができる
- Likert尺度と比べて、二値の判断はより正確で、評価者間の一貫性が高く、処理量も多い
- DoorDashが一連のイエス／ノー質問を通じてメニュー項目にタグ付けするためのラベリングキューを構築した方法などがある
ペアワイズ比較（Pairwise Comparison）では、アノテーターは一対のモデル応答を受け取り、どちらがより良いかを尋ねられる
- 人間にとってAまたはBを個別に採点するより、「AはBより良い」と言うほうが簡単なので、より速く信頼性の高いアノテーションにつながる（Likert尺度よりも）
Llama2ミートアップで、Llama2論文の著者の1人であるThomas Scialomは、ペアワイズ比較のほうが、記述済みの応答のような教師あり微調整データを収集するよりも速く安価であることを確認した
- 前者のコストは1件あたり$3.5、後者のコストは1件あたり$25

参照不要（Reference-free）評価とガードレールは相互に置き換えて使える

ガードレールは不適切または有害なコンテンツを捕捉するのに役立ち、一方で評価はモデル出力の品質と正確性を測るのに役立つ
- 参照不要評価の場合、これはコインの表裏の関係と見なせる
  - 参照不要評価とは、人間が作成した回答のような「golden」referenceに依存せず、入力プロンプトとモデルの応答だけで出力品質を評価できる評価のこと
参照不要評価の例: 要約評価
- 要約の事実的一貫性と関連性を評価するには、入力文書だけを考慮すればよい
- 要約がこれらの指標で低スコアなら、ユーザーに表示しないようにできるため、評価を実質的にガードレールとして利用できる
参照不要の「翻訳」評価:
- 人間による翻訳参照がなくても翻訳の品質を評価でき、これもまたガードレールとして使える

LLMは返すべきでないときにも出力を返す

LLMを扱う際の主要な課題は、そうすべきでない場面でもLLMがしばしば出力を生成してしまうこと
- これは無害だが無意味な応答から、有害性や危険な内容のようなより深刻な欠陥まで引き起こしうる
- たとえば文書から特定の属性やメタデータを抽出するよう求められると、その値が実際には存在しない場合でも、LLMは自信満々に値を返すことがある
- また、コンテキストとして英語以外の文書を与えたために、モデルが英語以外の言語で応答することもある
LLMに「該当なし」や「不明」の応答を返すようプロンプトで指示することはできるが、完璧ではない
- ログ確率を使える場合でも、出力品質の指標としては不十分である
  - ログ確率は出力にトークンが現れる可能性を示すが、生成されたテキストの正確性を反映するわけではない
- むしろ、クエリに応答し、一貫した応答を生成するよう訓練された命令チューニングモデルでは、ログ確率の較正が不十分な場合がある
  - したがって、高いログ確率は出力が流暢で一貫していることを示すかもしれないが、正確または関連性が高いことを意味しない
慎重なプロンプトエンジニアリングはある程度役立つが、望ましくない出力を検出し、フィルタリング／再生成する強力なガードレールで補完する必要がある
- たとえばOpenAIは、ヘイトスピーチ、自傷、性的出力などの安全でない応答を識別できるコンテンツモデレーションAPIを提供している
- 同様に、個人識別情報（PII）を検出するための多数のパッケージが存在する
ガードレールの利点の1つは、ユースケースへの依存が比較的少なく、そのため特定の言語でのあらゆる出力に広く適用できること
- また、高精度な検索によって関連文書が存在しない場合、システムが明確に「わかりません」と応答できる
LLMは、出力が期待される場面で出力を生成できないこともある
- これはAPIプロバイダーの長いレイテンシのような単純な問題から、コンテンツモデレーションフィルターによって出力がブロックされるようなより複雑な問題まで、さまざまな理由で起こりうる
したがって、デバッグと監視のために、入力と（場合によっては出力不足も）一貫して記録することが重要である

幻覚（Hallucination）はしつこい問題である

コンテンツ安全性やPIIの欠陥は多くの注意が払われるためほとんど発生しない一方で、事実の不一致はしつこく残り、検出もより難しい
- より頻繁に発生し、基準発生率は5〜10%であり、LLMプロバイダーから得た知見によれば、要約のような単純なタスクでも2%未満に下げるのは難しい場合がある
これに対処するために、プロンプトエンジニアリング（生成のアップストリーム）と事実不一致ガードレール（生成のダウンストリーム）を組み合わせられる
- プロンプトエンジニアリングでは、CoTのような技法は、LLMが最終出力を返す前に推論を説明させることで、ハルシネーションの低減に役立つ
- その後、事実不一致ガードレールを適用して要約の事実性を評価し、ハルシネーションをフィルタリングまたは再生成できる
場合によっては、ハルシネーションは決定論的に検出できる
- RAG検索のリソースを使う際、出力が構造化され、どのリソースかを識別できるなら、入力コンテキストから取得されたものかを手動で確認できるはずである

[運用: 日常業務(Day-to-Day)および組織の問題 ]

運用 1. データ

材料の質が料理の味を決めるように、入力データの品質は機械学習システムの性能を制約する
また、出力データは製品が機能しているかどうかを知る唯一の方法である
すべての執筆者は、データ分布（モード、エッジケース、モデルの限界）をよりよく理解するために、毎週数時間かけて入力と出力を綿密に確認する

開発-本番バイアスの確認

従来の機械学習パイプラインにおける一般的なエラー原因は、学習-提供バイアスである
- これは、学習に使われるデータが、モデルが本番で遭遇するデータと異なるときに発生する
学習やファインチューニングなしでLLMを使えるため学習セットは存在しないが、開発-本番データバイアスという類似の問題が発生する
- 基本的には、開発中にシステムをテストするデータは、システムが本番で直面するデータを反映している必要がある
  - そうでなければ、本番精度が低下する可能性がある
LLMの開発-本番バイアスは、構造的バイアスと内容ベースのバイアスの2種類に分類できる
- 構造的バイアスには、リスト型の値を持つJSON辞書とJSONリストの違い、一貫しない大文字小文字、タイプミスや文の断片のような誤りなど、形式の不一致に関する問題が含まれる
  - こうした誤りは、さまざまなLLMが特定のデータ形式で学習されており、プロンプトが些細な変更に非常に敏感な場合があるため、予測不能なモデル性能につながり得る
- 内容ベース、または「意味論的」バイアスは、データの意味や文脈の違いを指す
従来のMLと同様に、LLMの入出力ペア間のバイアスを定期的に測定することは有用である
- 入力および出力の長さや、特定の形式要件（例: JSONまたはXML）のような単純なメトリクスは、変更を追跡する簡単な方法である
より「高度な」バイアス検出として、入出力ペアの埋め込みをクラスタリングし、ユーザーが以前モデルにさらされていない領域を探索していることを示す可能性がある、ユーザーが議論しているトピックの変化のような意味論的バイアスを検出することを検討するとよい
プロンプトエンジニアリングのような変更をテストするときは、ホールドアウトデータセットが最新の状態であり、直近のユーザーインタラクションの種類を反映していることを確認する
- たとえば、本番入力でタイプミスがよく見られるなら、ホールドアウトデータにも含まれているべきである
広告
単に数値でバイアスを測定するだけでなく、出力に対して定性的評価を行うことも有益である
- モデルの出力を定期的にレビューすること（俗に「バイブチェック」と呼ばれる実践）は、結果が期待に合致し、ユーザーのニーズに引き続き関連しているかを確認するのに役立つ
バイアス確認に非決定性を組み込むことも有用である
- テストデータセットの各入力に対してパイプラインを複数回実行し、すべての出力を分析することで、たまにしか発生しない異常を捉えられる可能性が高まる

毎日LLMの入出力サンプルを確認する

LLMは動的で、絶えず進化している
- 印象的なゼロショット能力としばしば満足のいく出力にもかかわらず、LLMの失敗モードは極めて予測しにくい
カスタムタスクでは、LLMの性能について直感的な理解を育てるために、データサンプルを定期的に確認することが不可欠である
- 本番の入出力ペアは、LLMアプリケーションにおける「現物、現場」(genchi genbutsu)であり、代替できない
最近の研究では、開発者がより多くのデータと相互作用するほど、「良い」出力と「悪い」出力に対する認識が変化することが強調されている（つまり、基準バイアス）
- 開発者はLLM出力を評価するための基準を事前にいくつか提示できるが、こうした事前定義の基準はしばしば不完全である
たとえば、開発過程で良い応答の確率を高め、悪い応答の確率を下げるために、プロンプトを更新できる
- この評価、再評価、基準更新の反復プロセスは、出力を直接観察しなければLLMの振る舞いや人間の選好を予測するのが難しいために必要である
これを効果的に管理するため、LLMの入力と出力を記録すべきである
- 毎日これらのログサンプルを調べることで、新しいパターンや失敗モードを迅速に特定し、適応できる
- 新しい問題を発見したら、すぐにそれに対するassertionまたはevalを書ける
同様に、失敗モード定義に対するあらゆる更新は、評価基準に反映されるべきである
- このような「バイブチェック」は誤った出力のシグナルであり、コードとassertionがそれを運用する
最後に、このような姿勢は組織内で共有されるべきである
- たとえば、オンコールローテーションに入力および出力のレビューや注釈付けを追加すること

運用 2. モデルとともに働く

LLM APIを使うと、少数のプロバイダーの知能に依存することになる
- これは良い面もあるが、こうした依存関係には、性能、レイテンシ、スループット、コストの面でトレードオフが伴う
また、この1年でほぼ毎月、より新しくより優れたモデルがリリースされてきたため、古いモデルを廃止して新しいモデルへ移行する際に、製品を更新する準備を整えておく必要がある
- このセクションでは、完全には制御できない技術、つまり自前でホスティングや管理ができないモデルを使う際に得た教訓を共有する
実際のユースケースの大半では、LLMの出力は何らかの機械可読形式を通じてダウンストリームアプリケーションで消費されることになる
- たとえば、不動産CRMのReChatでは、フロントエンドでウィジェットをレンダリングするために構造化された応答が必要である
- 同様に、製品戦略アイデア生成ツールのBobaでは、タイトル、要約、実現可能性スコア、時間範囲フィールドを持つ構造化出力が必要である
- 最後に、LinkedInは、使用する技術を決定し、その技術を呼び出すためのパラメータを提供するために使われるYAMLを生成するようLLMを制約する方法を共有した
このアプリケーションパターンは、Postelの法則の極端なバージョンである
- 受け入れるもの（任意の自然言語）には寛容であり、送るもの（型付けされた機械可読オブジェクト）には保守的であるべきだ
- したがって、これは非常に耐久性のあるものになると期待している
現在、InstructorとOutlinesは、LLMから構造化出力を引き出すための事実上の標準である
- LLM API（例: Anthropic、OpenAI）を使う場合はInstructorを、自前でホストするモデル（例: Huggingface）を使う場合はOutlinesを使うとよい

モデル間のプロンプト移行はつらい作業である

場合によっては、注意深く作られたプロンプトがあるモデルでは非常にうまく機能しても、別のモデルでは期待どおりに機能しないことがある
- これはさまざまなモデルプロバイダー間を切り替えるときだけでなく、同一モデルのバージョン間でアップグレードするときにも起こりうる
たとえば Voiceflow は、gpt-3.5-turbo-0301 から gpt-3.5-turbo-1106 へ移行すると、意図分類タスクで 10% の性能低下が発生することを発見した
- （幸いにも、彼らには評価基盤があった！）
同様に GoDaddy は、1106 バージョンへアップグレードすると、gpt-3.5-turbo と gpt-4 の性能差が縮まるという前向きな傾向を観測した
- （あるいは、物事を半分空ではなく半分満ちていると見る人でなければ、新しいアップグレードで gpt-4 のリードが縮まったことに失望するかもしれない）
したがって、モデル間でプロンプトを移行する必要がある場合、単に API エンドポイントを差し替える以上の時間がかかると見込むべきである
- 同じプロンプトをつなげば、同等あるいはより良い結果につながると安易に仮定してはならない
また、信頼できる自動評価は、移行前後のタスク性能の測定に役立ち、手動検証に必要な労力を減らしてくれる

モデルのバージョン管理と固定

どの機械学習パイプラインでも、「何かを変えると、すべてが変わる」
- これは特に、私たち自身で訓練しておらず、しかも知らないうちに変更される可能性がある大規模言語モデル（LLM）のようなコンポーネントに依存するときに当てはまる
幸いなことに、多くのモデルプロバイダーは特定のモデルバージョン（例: gpt-4-turbo-1106）を「固定」できるオプションを提供している
- これにより、モデル重みの特定バージョンを使用し、変更されないようにできる
本番環境でモデルバージョンを固定すれば、モデル挙動の予期しない変更を防げる
- これは、モデルが置き換わったときに起こりうる、出力が過度に冗長になる問題やその他の想定外の失敗モードに対する顧客からの不満を避ける助けになる
また、本番設定をミラーしつつ最新のモデルバージョンを使う「シャドーパイプライン」を維持することも検討するとよい
- これにより、新しいリリースで安全に実験やテストを行える
こうした新しいモデルで出力の安定性と品質を検証した後であれば、本番環境のモデルバージョンを自信を持って更新できる

タスクを完了できる最小のモデルを選ぶ

新しいアプリケーションに取り組むとき、利用可能な中で最も大きく強力なモデルを使いたくなる誘惑がある
- しかし、いったんそのタスクが技術的に実現可能だと確認できたなら、より小さなモデルで同等の結果が得られないか試してみる価値がある
小さなモデルの利点は、レイテンシとコストが低いことだ
- 性能は劣るかもしれないが、Chain-of-Thought、n-shot プロンプト、文脈内学習といった手法は、小さなモデルが本来の能力以上の働きをするのを助けられる
LLM API 以外にも、特定タスク向けのファインチューニングは性能向上に役立つことがある
総合すると、小さなモデルを使った慎重に設計されたワークフローは、より速く安価でありながら、単一の大規模モデルの出力品質に匹敵し、場合によってはそれを上回ることさえある
- たとえばこのツイートでは、Haiku + 10-shot プロンプトがゼロショットの Opus や GPT-4 を上回る方法についての逸話が共有されている
長期的には、出力品質・レイテンシ・コストの最適なバランスを目指した、小さなモデルによるフローエンジニアリングの事例がさらに増えると予想される
もうひとつの例として、地味な分類タスクがある
- DistilBERT（6,700 万パラメータ）のような軽量モデルは、驚くほど強力なベースラインである
- 4 億パラメータの DistilBART も、もうひとつの優れた選択肢だ
  - オープンソースデータでファインチューニングすれば、レイテンシとコストを 5% 未満に抑えつつ、ROC-AUC 0.84 で幻覚を識別でき、大半の LLM を上回る
要点は、小さなモデルを見過ごしてはならないということだ
- あらゆる問題に巨大なモデルを当てはめるのは簡単だが、少しの創意工夫と実験によって、私たちはしばしばより効率的な解決策を見つけられる

運用 3. プロダクト

新しい技術は新たな可能性をもたらすが、優れたプロダクトを作る原則は普遍である
- したがって、まったく新しい問題を初めて解く場合でも、プロダクト設計を一からやり直す必要はない
堅実なプロダクトの基本に LLM アプリケーション開発を基づけることで、得られるものは多い
- そうすることで、私たちがサービスを提供する人々に本当の価値を届けられる

初期段階からデザインを関与させる

デザイナーがいると、プロダクトをどう構築し、どうユーザーに提示するかを理解し、深く考えるようになる
- ときには、デザイナーを単に物事をきれいに見せる人だと固定観念で捉えてしまうことがある
- しかし実際には、ユーザーインターフェースだけでなく、既存のルールやパラダイムを壊すことになっても、ユーザー体験をどう改善できるかを再考する役割を担う
デザイナーは、ユーザーの要求をさまざまな形に再構成することに、とりわけ長けている
- その中には他の形より解きやすいものもあり、AI ソリューションにより多く、あるいはより少ない機会を与えることがある
多くの他のプロダクトと同様に、AI プロダクトの構築は、それを動かす技術ではなく、達成すべきタスクを中心に行うべきである
次のような問いを自分に投げかけることに集中するとよい
- 「ユーザーがこのプロダクトに求めているタスクは何か？そのタスクはチャットボットが得意そうなものか？オートコンプリートはどうか？もしかすると別のものかもしれない！」
既存の設計パターンと、それが達成すべきタスクにどう関係するかを検討するとよい
- これらは、デザイナーがチームの能力に加える貴重な資産である

ヒューマン・イン・ザ・ループのための UX 設計

質の高いアノテーションを得る1つの方法は、ユーザー体験（UX）に Human-in-the-Loop（HITL）を統合すること
- ユーザーが簡単にフィードバックや修正を提供できるようにすれば、即時の出力を改善でき、モデル改善に役立つデータも収集できる
ユーザーが商品をアップロードして分類するECプラットフォームを想像してみよう
- UXの設計方法はいくつもある
  1. ユーザーが正しい商品カテゴリを手動で選択し、LLMが定期的に新商品を確認してバックエンドで誤分類を修正する
  2. ユーザーはカテゴリをまったく選択せず、LLMが定期的にバックエンドで商品を分類する（潜在的な誤りを含む）
  3. LLMがリアルタイムで商品カテゴリを提案し、ユーザーは必要に応じて検証・更新できる
3つのアプローチはいずれもLLMを含むが、提供するUXは大きく異なる
- 1つ目のアプローチは初期負担をユーザーに負わせ、LLMは事後処理のチェック役を担う
- 2つ目のアプローチはユーザーの労力を一切必要としないが、透明性やコントロールは提供しない
- 3つ目のアプローチが適切なバランスを保つ
  - LLMが事前にカテゴリを提案することで、ユーザーの認知負荷を下げ、商品を分類するためにこちらの分類体系を学ぶ必要をなくす
  - 同時に、ユーザーが提案を確認して編集できるようにすることで、商品をどう分類するかの最終決定権をユーザーの手にしっかりと委ねる
- おまけに、3つ目のアプローチはモデル改善のための自然なフィードバックループを生み出す
  - 良い提案は受け入れられ（正のラベル）、悪い提案は更新される（負の後に正のラベル）
この「提案 → ユーザー検証 → データ収集」というパターンは、多くのアプリケーションで一般的に見られる
- コーディングアシスタント: ユーザーは提案を受け入れる（強い正）、受け入れて調整する（正）、または無視する（負）ことができる
- Midjourney: ユーザーは画像をアップスケールしてダウンロードする（強い正）、画像を変更する（正）、または新しい画像セットを生成する（負）ことができる
- チャットボット: ユーザーは応答に対して「いいね」（正）または「よくないね」（負）を付けたり、応答が本当にひどい場合は再生成（強い負）を選んだりできる
フィードバックは明示的な場合もあれば暗黙的な場合もある
- 明示的フィードバックは、製品からの求めに応じてユーザーが提供する情報
- 暗黙的フィードバックは、ユーザーが意図的にフィードバックを与えなくても、ユーザーとの相互作用から学習される情報
コーディングアシスタントとMidjourneyは暗黙的フィードバックの例であり、「いいね」と「よくないね」は明示的フィードバックである
- コーディングアシスタントやMidjourneyのようにUXをうまく設計すれば、製品とモデルの改善に向けた多くの暗黙的フィードバックを収集できる

容赦なく要件階層（Hierarchy）の優先順位を付ける

デモを本番環境に載せることを考えるときは、次の要件を考慮する必要がある
- 信頼性: 99.9%の稼働率、構造化出力への準拠
- 無害性: 攻撃的、NSFW、その他の有害なコンテンツを生成しないこと
- 事実的一貫性: 提供されたコンテキストに忠実で、事実を歪めないこと
- 有用性: ユーザーのニーズや要求に関連していること
- 拡張性: レイテンシSLA、サポート可能なスループット
- コスト: 予算は無限ではないため
- その他: セキュリティ、プライバシー、公平性、GDPR、DMA など
これらすべての要件を一度に解決しようとすると、何もリリースできない
- だからこそ優先順位を付けなければならない。容赦なく。
これは、製品が機能しない、あるいは成立しない可能性がある妥協不能な条件（例: 信頼性、無害性）が何かを明確にすることを意味する
- MVP（Minimum Lovable Product）を見極めることが重要である
最初のバージョンは完璧ではないと受け入れ、リリースして反復していくべきである

ユースケースに応じてリスク許容度を調整する

言語モデルとアプリケーションのレビュー水準を決める際には、ユースケースと対象を考慮する必要がある
- 医療や金融の助言を提供する顧客向けチャットボットでは、安全性と正確性に対して非常に高い基準が必要になる
  - ミスや誤った出力は現実の損害を生み、信頼を失わせる可能性がある
  広告
- 一方で、推薦システムのようなそれほど重要でないアプリケーションや、コンテンツ分類・要約のような社内向けアプリケーションでは、厳しすぎる要件は大きな価値を追加しないまま進展を遅らせるだけである
これは、多くの企業が外部向けアプリケーションよりも社内LLMアプリケーションのほうで速く動いているという最近の a16z レポートとも一致している
- 社内生産性のためにAIを試すことで、組織はより統制された環境でリスクの管理方法を学びつつ、価値の獲得を始められる
- その後、自信が付けば顧客向けユースケースへと拡張できる

運用 4. チームと役割（Roles）

どんな職務も定義は簡単ではないが、この新しい領域で仕事の職務記述書を書くのはとりわけ難しい
- 重なり合う職種のベン図や職務記述に関する提案はここでは省く
- ただし、新しい役割であるAIエンジニアの存在を認め、その役割については論じる
重要なのは、チームの残りの部分と責任をどのように割り当てるべきかを議論することである

ツールではなくプロセスに集中する

LLMのような新しいパラダイムに直面すると、ソフトウェアエンジニアはツールを好む傾向がある
- その結果、ツールが解決しようとしていた問題やプロセスを見落としてしまう
- こうして多くのエンジニアは偶発的複雑性を抱え込み、チームの長期的な生産性に悪影響を及ぼす
たとえばこの記事では、特定のツールが大規模言語モデル向けのプロンプトを自動生成する方法について説明している
- 問題解決の方法論やプロセスを先に理解せずにこうしたツールを使うエンジニアは、最終的に不要な技術的負債を背負い込むことになると主張している（IMHO もっともだ）
偶発的複雑性に加えて、ツールはしばしば仕様が不十分である
- たとえば、有害性、簡潔さ、トーンなどに関する汎用評価器を備えた「LLM評価ツールボックス」を提供するLLM評価ツール業界が成長している
- 多くのチームが、自分たちのドメイン特有の失敗モードについて批判的に考えずに、こうしたツールを採用しているのを目にする
これに対してEvalGenは、基準の指定、データのラベリング、評価の確認など、各段階にユーザーを深く関与させることで、ドメイン固有の評価を生成するプロセスを教えることに重点を置いている
- ソフトウェアはユーザーを次のようなワークフローへ導く
EvalGenが導くLLM評価作成のベストプラクティス
1. ドメイン固有のテストを定義する（プロンプトから自動的にブートストラップされる）
  - コードまたはLLM-as-a-Judgeによるアサーションとして定義される
2. テストが指定した基準を捉えているかをユーザーが確認できるようにするため、テストを人間の判断と一致させることの重要性
3. システム（プロンプトなど）が変更されるのに合わせてテストを反復する
EvalGenは開発者に評価構築プロセスのメンタルモデルを提供するが、特定のツールに固定することはない
- AIエンジニアにこの文脈を与えた後、彼らはよりシンプルなツールを選んだり、自前のツールを構築したりすることをしばしば決めると分かる
プロンプト作成と評価以外にも、LLMの構成要素は非常に多く、ここですべてを列挙することはできない
- しかし、AIエンジニアがツールを採用する前にプロセスを理解しようと努めることは重要である

常に実験する

ML製品は実験と深く結びついている
- A/Bテストやランダム化比較試験だけでなく、システムの可能な限り最小の構成要素を修正し、オフライン評価を行う頻繁な試行を意味する
- みんなが評価に熱中する理由は、実際には信頼性や確信のためではなく、実験を可能にするためである！
  - 評価が優れているほど実験をより速く反復でき、その結果、システムの最良バージョンへより早く収束できる
実験が非常に安価になったため、同じ問題を解くためにさまざまなアプローチを試すことが一般的になった
- データ収集とモデル訓練の高コストは最小化された
  - プロンプトエンジニアリングのコストは、人間の時間が少し余分にかかる程度である
- チーム全体がプロンプトエンジニアリングの基本を学べるようにすること
  - これにより全員が実験するよう促され、組織全体で多様なアイデアにつながる
探索のためだけに実験するのではなく、活用のためにも実験を使うこと！
- 新しいタスクの動作するバージョンはあるか？
  - チームの別の人が異なる方法でアプローチすることを検討してみること
- より速い可能性のある別の方法を試す
- Chain-of-ThoughtやFew-Shotのようなプロンプト技法を調べ、品質を高めること
- ツールが実験の妨げにならないようにすること
  - もしそうなら、再構築するか、改善できるものを購入すること
製品／プロジェクトの企画中には、評価の構築と複数の実験実施のための時間をあらかじめ確保すること
- エンジニアリング製品向けの製品仕様を考え、そこに評価に関する明確な基準を追加すること
ロードマップ作成時には、実験に必要な時間を過小評価しないこと
- 本番承認を得る前に、複数回の開発と評価の反復を見込むこと

誰もが新しいAI技術を使えるように権限を与える

生成AIの採用が進むにつれて、専門家だけでなくチーム全体がこの新しい技術を理解し、使えると感じてほしい
- LLMがどのように動くか（例: レイテンシ、失敗モード、UX）について直感を養うのに、これ以上良い方法はない
- LLMは比較的取り組みやすい
  - パイプラインの性能向上のためにコーディング方法を知っている必要はなく、誰もがプロンプトエンジニアリングと評価を通じて貢献できる
この大きな部分は教育である
- n-shotプロンプティングやCoTのような技法が、モデルを望ましい出力方向へ条件づけるのに役立つという、プロンプトエンジニアリングの基礎から始められる
知識を持つ人は、LLMが本質的に自己回帰的であることのような、より技術的な側面についても教育できる
- つまり、入力トークンは並列処理されるが、出力トークンは逐次生成される
- したがって、レイテンシは入力長ではなく出力長の関数である
  - これはUXを設計し、性能期待値を設定する際の主要な考慮事項である
実験と探索のための実践機会を提供することもできる
- ハッカソンはどうだろうか？
  - チーム全体が数日間、投機的なプロジェクトをハックすることに時間を使うのは高くつくように見えるかもしれないが、その結果は驚くものになるかもしれない
- ハッカソンによって、3年ロードマップを1年でほぼ完了したチームもある
  - 別のチームは、ハッカソンを通じてLLMによって初めて可能になったパラダイムシフトのUXへとつながり、それが今では今年以降の優先事項になっている

「AIエンジニアリングがすべて」という落とし穴にはまらないこと

新しい職種が生まれると、初期にはその役割に関連する能力を過大評価する傾向がある
- それはしばしば、その職業の実際の範囲が明確になるにつれて痛みを伴う修正へとつながる
- この分野の新参者や採用担当者は、大げさな主張をしたり過度な期待を抱いたりすることがある
過去10年で注目すべき例は次のとおりである
- データサイエンティスト: 「あらゆるソフトウェアエンジニアより統計学に詳しく、あらゆる統計学者よりソフトウェアエンジニアリングに詳しい人」
- 機械学習エンジニア（MLE）: 機械学習に対するソフトウェアエンジニアリング中心の視点
当初、多くの人はデータ駆動型プロジェクトにはデータサイエンティストだけで十分だと想定していた
- しかし、データサイエンティストはデータ製品を効果的に開発・展開するために、ソフトウェアエンジニアやデータエンジニアと協力しなければならないことが明らかになった
この誤解はAIエンジニアという新しい役割でも再び現れ、一部のチームはAIエンジニアだけで十分だと信じている
- 実際には、機械学習またはAI製品を構築するには幅広い専門職が必要である
私たちは12社以上に対してAI製品に関するコンサルティングを行ってきたが、彼らが「AIエンジニアリングが必要なすべて」という思い込みの罠にはまるのを一貫して観察してきた
- その結果、製品構築に必要な重要要素を見落とし、製品がデモ以上に拡張できず苦戦することが多い
たとえば、評価と測定はVibeチェック以上へ製品を拡張するために重要である
- 効果的な評価に必要なスキルは、従来は機械学習エンジニアに見られる強みの一部と一致する
  - AIエンジニアだけで構成されたチームは、こうしたスキルを欠いている可能性が高い
共同著者のHamel Husainは、データバイアス検出とドメイン固有評価設計に関する最近の取り組みで、こうしたスキルの重要性を説明している
AI製品構築の道のりで必要となる役割の種類とタイミング
1. まず製品構築に集中すること
- AIエンジニアが含まれることはあり得るが、必須ではない
- AIエンジニアは製品（UX、配管など）をプロトタイプし、迅速に反復するのに有用である
1. 次に、システムを計測しデータを収集して、正しい基盤を作ること
- データの種類と規模に応じて、プラットフォームエンジニアおよび／またはデータエンジニアが必要になる場合がある
- また、問題をデバッグするためにこのデータをクエリして分析するシステムも必要である
1. 次に、AIシステムを最適化すること
- これは必ずしもモデル訓練を含むわけではない
- 基本事項には、指標設計、評価システム構築、実験実行、RAG検索最適化、確率的システムのデバッグなどの段階が含まれる
- MLEはこの分野に非常に長けている（もちろんAIエンジニアも習得可能である）
- 先行段階を完了していない場合、MLEを採用するのは通常妥当ではない
これとは別に、常にドメイン専門家が必要である
- 小規模企業では理想的には創業チームがこの役割を担い、大企業ではプロダクトマネージャーがこの役割を果たせる
役割の進行とタイミングを認識することが重要である
- 間違ったタイミングで人を採用したり（例: MLEを早すぎる段階で採用する）、間違った順序で構築したりすることは、時間とコストの無駄であり離職を招く
また、1〜2段階でMLEと定期的にチェックインする（ただし正社員としては雇わない）ことで、会社が正しい基盤を築く助けになる

[戦略: LLMを活用した構築で後れを取らない方法]

成功する製品開発には、やみくもにプロトタイプを作ったり最新モデルやトレンドを追いかけたりするのではなく、慎重な企画と優先順位付けが必要である
AI製品開発では、自社開発するか購入するかといった主要なトレードオフを検討する必要がある
初期のLLMアプリケーション開発のための「プレイブック」を提示する

戦略1: PMF前にGPUなし

優れた製品になるには、単に他人のAPIを薄くラップしただけ以上のものになる必要がある
しかし、反対方向の失敗はさらに大きなコストを招くことがある
- 昨年には、明確な製品ビジョンやターゲット市場もないまま、モデル学習とカスタマイズに莫大なベンチャー資本が投じられた
- ある企業は実に60億ドルものシリーズA投資を受けた
このセクションでは、すぐに独自モデルの学習を始めることがなぜ誤りなのかを説明し、自前ホスティングの役割についても考察する

最初から（ほぼ）再トレーニングするのは意味がない

ほとんどの組織にとって、最初からLLMを事前学習するのは、製品開発から逸脱した非現実的な取り組みである
- 機械学習インフラの開発と維持には多くのリソースを要する
  - データ収集、モデルの学習と評価、デプロイなどが含まれる
- プロダクト・マーケット・フィットを検証する段階であれば、このような努力は中核となる製品開発からリソースを分散させる
- 計算資源、データ、技術的能力があっても、事前学習済みLLMは数か月で陳腐化する可能性がある
BloombergGPTの事例
- 金融業務に特化したLLMであるBloombergGPTは、363Bトークンで事前学習された
- AIエンジニアリング4名、ML製品および研究5名の計9名の専任スタッフによる膨大な努力が投じられた
- それにもかかわらず、1年以内にその業務でgpt-3.5-turboおよびgpt-4に後れを取った
こうした事例は、ほとんどの実アプリケーションにおいて、LLMをゼロから事前学習することがリソースの最善の使い方ではないことを示唆している
- その代わり、チームは特定の要件に合わせて利用可能な最も強力なオープンソースモデルをファインチューニングするほうがよい
もちろん例外はある
- Replitのコードモデルは、コード生成と理解に特化して事前学習された優れた事例である
- 事前学習によってCodeLlama7bなどのより大きなモデルより優れた性能を示した
- しかし、より強力なモデルが登場するにつれ、有用性を維持するには継続的な投資が必要だった
広告

必要だと確認されるまではファインチューニング禁止

ほとんどの組織で、ファインチューニングは戦略的思考よりもFOMO（Fear Of Missing Out、取り残されることへの不安）によって主導されている
- 組織は「単なるラッパー」という非難を避けるため、あまりに早い段階でファインチューニングに投資してしまう
- 実際には、ファインチューニングは、他のアプローチでは十分ではないと確信させる多くの事例を集めた後に初めて投入すべき重装備のようなものだ
1年前、多くのチームがファインチューニングへの期待を表明していたが、プロダクト・マーケット・フィットを見いだしたチームはわずかで、大半はその判断を後悔した
- ファインチューニングを行うなら、ベースモデルの改善に応じて繰り返し実施する覚悟が必要である
  - 下の「モデルは製品ではない」と「LLMOps構築」を参照
ファインチューニングが実際に正しい選択となりうる場合
- 既存モデルの学習に使われた大半のオープンなWebスケールデータセットでは利用できないデータが必要な場合
- 既存モデルでは不十分であることを示すMVPをすでに構築している場合
- ただし注意が必要である。優れた学習データをモデル開発者が容易に入手できないなら、あなたはどこから入手するのか？
LLMベースのアプリケーションは科学博覧会のプロジェクトではない
- 戦略目標や競争上の差別化への貢献度に見合った投資が行われるべきである

推論APIから始めつつ、セルフホスティングを恐れないこと

LLM APIを使えば、スタートアップは最初から独自モデルを学習させなくても、言語モデリング機能を容易に導入・統合できる
- AnthropicやOpenAIなどのプロバイダーは、数行のコードで製品にインテリジェンスを与えられる汎用APIを提供している
- こうしたサービスを使えば、労力を減らして顧客向けの価値創出に集中でき、アイデアの検証やプロダクト・マーケット・フィットへの反復をより速く進められる
しかし、データベースと同様に、マネージドサービスは規模や要件が拡大するにつれて、すべてのユースケースに適しているわけではない
- 実際、医療や金融のような規制産業、あるいは契約上の義務や機密保持要件により求められる場合、機密データや個人データをネットワーク外に送信せずにモデルを使う唯一の方法がセルフホスティングであることもある
さらにセルフホスティングは、推論プロバイダーが課すレート制限、モデル提供終了、利用制限などの制約を回避できる
- セルフホスティングはモデルに対する完全な制御権を提供し、差別化された高品質なシステムをより構築しやすくする
最後に、セルフホスティング、とくにファインチューニングは、大規模ではコスト削減につながる可能性がある
- 例えばBuzzfeedは、オープンソースLLMをファインチューニングしてコストを80%削減した事例を共有している

戦略2: より良いものに向けて反復する

長期的に競争優位を維持するには、モデルを超えて製品を差別化できる要素を考える必要がある
実行速度は重要だが、それだけが唯一の強みであってはならない

モデルは製品ではない、そのモデルを取り巻くシステムこそが製品である

モデルを構築しないチームにとって、イノベーションの速いペースは祝福である
- コンテキストサイズ、推論能力、価格対価値などの改善を追って最新モデルへ移行し、より良い製品を作れるからだ
- こうした進歩は予測できるほど魅力的である
- 総合すると、モデルはシステムの中で最も持続性の低い構成要素である可能性が高い
その代わり、継続的な価値を提供できる部分に努力を集中すべきである
- Evals: モデル全体でタスク性能を安定して測定するため
- Guardrails: モデルに関係なく望ましくない出力を防ぐため
- Caching: モデルを完全に回避することでレイテンシとコストを下げるため
- Data flywheel: 上記すべての反復的改善を推進するため
- これらの構成要素は、生のモデル機能よりも厚い製品品質の堀を築く
ただし、アプリケーションレイヤーを構築することがリスクなしという意味ではない
- OpenAIや他のモデルプロバイダーが実用的なエンタープライズソフトウェアを提供しようとしているのに、いずれ切り取られる部分を自分で作り込んではならない
例えば、一部のチームは独自モデルの構造化出力を検証するためのカスタムツール構築に投資してきた
- ここへの最小限の投資は重要だが、深く投資するのは時間の有効活用ではない
- OpenAIは、関数呼び出しを要求したときに有効な関数呼び出しを返せるようにすべきである。すべての顧客がそれを望むからだ
- ここでは「戦略的先送り」を適用し、絶対に必要なものだけを構築し、プロバイダーの機能拡張を待つべきである

小さく始めて信頼を得る

すべての人にとっての何でも屋になろうとする製品を作るのは、凡庸さへのレシピである
説得力のある製品を作るには、企業はユーザーが繰り返し戻ってくるような粘着性の高い体験を築くことに特化しなければならない
ユーザーが尋ねるあらゆる質問に答えることを目指す一般的なRAGシステムを考えてみよう
- 専門性が欠けているということは、システムが最新情報を優先したり、ドメイン特化の形式を解析したり、特定タスクのニュアンスを理解したりできないことを意味する
- その結果、ユーザーは浅く信頼できない体験をすることになり、要件を満たせず離脱してしまう
これを解決するには、特定のドメインとユースケースに集中する必要がある
- 広さより深さを加えることで範囲を絞るべきである
- そうすることで、ユーザーの共感を呼ぶドメイン特化ツールを作れる
専門化により、システムの機能と限界を率直に伝えられる
- システムにできることとできないことを透明に公開することは、自己認識を示し、ユーザーがどこで最も多くの価値を加えられるかを理解する助けとなり、結果として出力に対する信頼と確信を築く

LLMOpsを作るが、適切な理由を持つこと: 迅速な反復

DevOpsは本質的に、再現可能なワークフローやシフトレフト、あるいは2枚のピザチームへの権限委譲のことではない。YAMLファイルを書くことではなおさらない
DevOpsとは、作業とその結果のあいだのフィードバックサイクルを短縮し、エラーではなく改善が蓄積されるようにすることだ
- そのルーツはリーンスタートアップ運動を通じてリーン生産方式とトヨタ生産方式にさかのぼり、シングルミニッツ段取り替えとカイゼンを重視する
MLOpsはDevOpsの形をMLに適用したものだった
- 再現可能な実験や、モデル構築者がデプロイできるよう権限を与えるオールインワンのツール群がある。YAMLファイルも大量にある
しかし業界全体として、MLOpsはDevOpsの機能を取り入れなかった。モデルと本番環境での推論・相互作用のあいだのフィードバックギャップを縮めなかった
幸いにも、LLMOps分野はプロンプト管理のような些末な問題から離れ、反復を妨げる難しい問題である本番監視と評価へとつながる継続的改善へ方向転換した
すでに、チャットモデルやコーディングモデルに対する中立的でクラウドソーシングされた評価のための対話型アリーナがある。これは集団的かつ反復的な改善の外側のループだ
- LangSmith、Log10、LangFuse、W&B Weave、HoneyHiveなどのツールは、本番環境でのシステム出力に関するデータを収集・整理するだけでなく、開発と深く統合してそのシステムの改善に活用することを約束している。こうしたツールを採用するか、自前で構築しよう

買えるLLM機能を作らないこと

成功しているビジネスの大半はLLMビジネスではない。同時に、ほとんどのビジネスにはLLMで改善できる機会がある
この2つの観察はしばしばリーダーを誤らせ、コストを増やし品質を下げながら、LLMでシステムを拙速に作り替え、人工的で虚栄心の強い"AI"機能としてリリースさせてしまう。いまや恐れられているキラキラのアイコンの完成だ
より良い方法がある。製品目標に本当に合致し、中核業務を強化するLLMアプリケーションに集中することだ
チームの時間を浪費するいくつかの誤った試みを考えてみよう
- ビジネス向けのカスタムtext-to-SQL機能を構築する
- 文書と対話できるチャットボットを構築する
- 企業のナレッジベースをカスタマーサポート用チャットボットに統合する
上記はいずれもLLMアプリケーションのHello Worldだが、製品企業が自ら構築するのは理にかなわない
- これは多くのビジネスに共通する一般的な問題であり、有望なデモと信頼できるコンポーネントのあいだには大きな隔たりがあり、ソフトウェア企業の得意領域だからだ
- 現在のY Combinatorのバッチで大規模に解決されている一般的な問題に、貴重なR&D資源を投じるのは無駄だ
これがありきたりなビジネス助言のように聞こえるなら、それは現在の過熱した盛り上がりのなかで、"LLM"というものを最先端で差別化されたものと誤解しやすく、すでに陳腐化したアプリケーションを見落としやすいからだ

AIをループに入れ、人間を中心に置くこと

現在のLLMベースのアプリケーションは脆弱だ。膨大な量のセーフガードと防御的エンジニアリングを必要とするが、それでも予測しにくい。しかも、厳密にスコープを定めれば、こうしたアプリケーションは非常に有用になりうる。つまり、LLMはユーザーのワークフローを加速する優れたツールになれるということだ
LLMベースのアプリケーションがワークフローを完全に置き換えたり、職務機能を代替したりする姿を想像したくなるかもしれないが、今日もっとも効果的なパラダイムは人間とコンピュータのケンタウロス（Centaur chess）だ
- 有能な人間が、自身の迅速な活用のために調整されたLLM機能と組み合わされることで、作業をこなす生産性と満足感は大きく向上しうる
- LLMの代表的なアプリケーションの1つであるGitHub CoPilotは、このワークフローの力を実証した
  - "全体として、開発者はGitHub CopilotとGitHub Copilot Chatを使うと、コーディングがより簡単になり、エラーが減り、可読性が高く、再利用しやすく、簡潔で、保守しやすく、堅牢になると感じたと述べています。" - Mario Rodriguez, GitHub
長らくMLに携わってきた人は、"human-in-the-loop"という考えにすぐ飛びつきがちだが、そう急がないこと
- HITL機械学習は、MLモデルが想定どおりに動作することを保証する人間の専門家に基づくパラダイムだ
- ここで提案しているのは、関連はしていても、よりニュアンスのあるものだ。LLMベースのシステムは、今日のほとんどのワークフローの主な駆動力であるべきではなく、単なるリソースであるべきだ
人間を中心に置き、LLMがどのようにワークフローを支援できるかを問うことは、製品と設計の意思決定にかなり異なる影響をもたらす
- 最終的には、あらゆる責任を素早くLLMに丸投げしようとする競合とは異なる製品、つまりより良い製品、より有用でよりリスクの低い製品を作ることになる

戦略3. プロンプティング、Eval、データ収集から始める

前のセクションでは、技術と助言を大量に投入した。受け止めるにはかなり多い。役に立つ助言の最小セットを考えてみよう
- チームがLLM製品を作りたいなら、どこから始めるべきだろうか？
この1年で、成功するLLMアプリケーションは一貫した軌跡をたどることを確信できるほど十分に見てきた。このセクションでは、この基本的な"始め方"のプレイブックを見ていく
核心となるアイデアは、シンプルに始めて、必要に応じて複雑さを加えることだ
- Rule of Thumb: 洗練度の各レベルには、一般に前の段階より少なくとも1桁多い労力が必要になる。これを念頭に置いて……

プロンプトエンジニアリングが最優先

まずはプロンプトエンジニアリングから始めること
- 以前に戦術セクションで議論したすべての技法を使うこと
- Chain-of-thought、n-shot例、構造化された入出力はほとんど常に良いアイデアだ
- 性能の低いモデルから性能を絞り出そうとする前に、もっとも高性能なモデルでプロトタイプを作ること
プロンプトエンジニアリングで望む性能水準を達成できない場合にのみ、ファインチューニングを検討すべきだ
- 独自モデルの利用を妨げ、自前ホスティングを要求する非機能要件（例: データプライバシー、完全な制御、コスト）がある場合には、より頻繁にそうなる
- 同じプライバシー要件が、ファインチューニングのためのユーザーデータ利用まで妨げないよう注意すること

評価を作り、データフライホイールを始動する

立ち上げたばかりのチームにも評価（evals）は必要だ。そうでなければ、プロンプトエンジニアリングで十分なのか、あるいはファインチューニングしたモデルがベースモデルを置き換える準備ができているのか分からない
効果的な評価はタスクに特化しており、意図したユースケースを反映している
- 最初のレベルとして推奨する評価はユニットテストだ
- こうした単純なアサーションは、既知または仮説上の失敗モードを検出し、初期の設計判断を下す助けになる
- 分類、要約などの他のタスク別評価も参照すること
ユニットテストやモデルベース評価は有用だが、人間による評価の必要性を置き換えるものではない
- 実際に人々にモデルや製品を使ってもらい、フィードバックを提供してもらうこと
- これは、実際の性能と欠陥率を測定すると同時に、将来モデルをファインチューニングするために使える高品質なアノテーションデータを収集するという二重の目的を果たす
- これは時間とともに複利で効く正のフィードバックループ、すなわちデータフライホイールを生み出す
  - モデル性能を評価したり欠陥を見つけたりするための人間評価
  - アノテーションデータを使ってモデルをファインチューニングする、あるいはプロンプトを更新する
  - 反復する
たとえば、LLMが生成した要約の欠陥を監査する際、各文に対して事実不一致、無関係、あるいはスタイル不良を識別する細粒度のフィードバックラベルを付けられる
- その後、こうした事実不一致の注釈を使ってハルシネーション分類器を学習させたり、関連性の注釈を使って関連性報酬モデルを学習させたりできる
LinkedInは、ハルシネーション、責任あるAI違反、一貫性などを推定するためにモデルベース評価者を用いた成功事例を共有している
時間とともに価値が増す資産を生み出すことで、評価（evals）の構築を単なる運用コストから戦略的投資へと変え、その過程でデータフライホイールを構築する

戦略4. 低コストな認知の高次トレンド（The high-level trend of low-cost cognition）

1971年、Xerox PARCの研究者たちは、私たちが今生きているネットワーク接続されたパーソナルコンピュータの世界を予測していた
- 彼らは、それを可能にした技術（Ethernet、グラフィックレンダリング、マウス、ウィンドウなど）の発明に中核的な役割を果たすことで、その未来を生み出すことに貢献した
彼らはまた、単純な演習も行っていた
- 非常に有用だが（例：ビデオディスプレイ）、まだ経済的ではない（ビデオディスプレイを駆動するのに十分なRAMが数千ドルする）アプリケーションを検討した
- その後、その技術の歴史的な価格トレンド（ムーアの法則に類似）を調べ、その技術がいつ経済的になるかを予測した
LLM技術についても同じことができる。ドル当たりのトランジスタ数ほどきれいではないにせよ
- 長年使われてきた人気ベンチマーク（例：Massively-Multitask Language Understandingデータセット）と、一貫した入力手法（5-shotプロンプティング）を選ぶ
- そして、時間の経過に伴って、このベンチマークでさまざまな性能水準を持つ言語モデルを実行するコストを比較する
一定コストで見れば能力は急速に向上している。一定の能力水準で見ればコストは急速に低下している
- OpenAIのdavinciモデルがAPIとして公開されてからの4年間で、100万トークン（この文書約100部相当）の規模において、そのタスクに相当する性能を持つモデルを実行するコストは20ドルから10セント未満にまで低下した。半減期はわずか6か月である
- 同様に、2024年5月時点でAPIプロバイダー経由または自前でMetaのLLaMA 3 8Bを実行するコストは100万トークン当たりわずか20セントであり、ChatGPTを可能にしたモデルであるOpenAIの text-davinci-003 と同等の性能を示している
- このモデルは、2023年11月末のリリース時点でも100万トークン当たり約20ドルかかっていた。わずか18か月で二桁の差がついた。これはムーアの法則が予測する単純な2倍化と同じ期間である
では、非常に有用だが（Park et alのような生成型ビデオゲームキャラクターの駆動）、まだ経済的ではない（1時間当たりのコストが625ドルと推定される）LLMアプリケーションを考えてみよう
- この論文が2023年8月に発表されて以来、コストは約1桁下がって1時間当たり約62.50ドルになっている
- 9か月後には1時間当たり6.25ドルまで下がると予想できる
一方、Pac-Manが1980年に発売されたとき、今日の1ドルで数分から数十分プレイできるクレジットを買うことができた。これを1時間当たり6ゲーム、または1時間当たり6ドルとしよう
- このざっくり計算は、魅力的なLLM強化ゲーム体験が2025年ごろには経済的に成立することを示唆している
こうしたトレンドは新しく、まだ数年しか経っていない。しかし、今後数年間でこのプロセスが鈍化すると期待すべき理由はほとんどない
- パラメータ当たり約20トークンという「Chinchilla比率」を超えるスケーリングのような、アルゴリズムやデータセットにおける取りやすい果実を使い切ったとしても、データセンター内部やシリコン層でのより深いイノベーションと投資がそのギャップを埋めるだろう
そして、これがおそらく最も重要な戦略的事実である
- 今日ではまったく実用不可能なフロアデモや研究論文が、数年後にはプレミアム機能となり、その直後にはコモディティになるだろう
- そのことを念頭に置いて、システムと組織を構築しなければならない

[0から1へ進むデモは、もはや十分だ。これからは1からNへ進むプロダクトを作るとき]

LLMデモを作るのは本当に楽しい。数行のコード、ベクターデータベース、慎重に書かれたプロンプトで「魔法」を生み出せる
この1年、この魔法はインターネット、スマートフォン、さらには印刷術にまで比較されてきた
残念ながら、実際のソフトウェアリリース作業を経験したことがある人なら誰でも知っているように、制御された環境で動くデモと、大規模に安定動作するプロダクトの間には巨大な隔たりがある
想像してデモを作るのは簡単でも、プロダクトにするのが非常に難しい問題は数多くある
- 例えば自動運転。車が1ブロックを自動運転するのを実演するのは簡単だが、それをプロダクトにするには10年かかる - Andrej Karpathy
自動運転車を例にしてみよう
- 1988年、ニューラルネットワークで運転される最初の自動車が登場した
- 25年後、Andrej KarpathyはWaymoで最初のデモライドを体験した
- その10年後、同社は無人運転の認可を取得した
- プロトタイプから商用製品になるまでの35年間、厳格なエンジニアリング、テスト、改善、規制対応が積み重ねられた
産業界と学術界の全体にわたって、この1年間の浮き沈みを観察してきた：LLMアプリケーションの1年目（Year 1 of N for LLM applications）
- 評価、プロンプトエンジニアリング、ガードレールのような戦術から、運用スキル、チーム作り、どの機能を内製するかの選定といった戦略的観点に至るまで、私たちが学んだ教訓が2年目以降に役立つことを願っている
- この刺激的な新技術を、ともに前進させていけることを楽しみにしている

9件のコメント

inthelife 2024-06-17

内容が良かったので、あとで何度も見返せるように Mindmap にしてみました ^^;

https://drive.google.com/file/d/…

hheungsu 2024-06-15

とても良い文章です！！最初から最後まで、じっくり噛みしめたい有益な言葉がたくさんあります。この珠玉のような文章を翻訳して投稿してくださって、ありがとうございます！！

nutella 2024-06-12

今の時点では本当にとても役に立ちますね。

komanabi 2024-06-11

メガスタディは終わった、オメガ3がやって来る!!!

ssifood 2024-06-11

もうスカイネットは終わりだ、次はメガスタディが来る。

my0075425 2024-06-11

もう人類は終わりだ、スカイネットが来る!!

zihado 2024-06-10

元記事の執筆者のキャリアも興味深かったです
https://ja.news.hada.io/topic?id=1626

eungook 2024-06-11

わあ…ものすごく刺激を受けますね…。ご紹介ありがとうございます。

humblebee 2024-06-10

洞察と経験が生き生きと感じられる素晴らしい文章ですね！私とチームにとって大きな助けになりそうです。とても楽しく読ませていただきました。ありがとうございます ☺️