あなたのクラウドの請求書を爆破せずにLLMアプリケーションをスケールする方法

「Help! Our AI Model Costs Are Through the Roof!」 ChatGPTとその従兄弟は、AI駆動アプリケーションの黄金の流れを引き起こしたが、LLMに基づくアプリケーションを構築する現実は、WebインターフェイスにAPI呼び出しを叩くよりも複雑である。 毎日、私のLinkedInは新しい「AI駆動型」製品を供給しています。いくつかは法律文書を分析し、他の人はマーケティングコピーを書く、そして勇敢な数人はソフトウェア開発を自動化しようとします。これらの「ウラッパー企業」(時には軽蔑的に呼ばれる)は、独自のモデルを訓練していないかもしれませんが、多くは顧客のための実際の問題を解決し、企業の現在の要求に基づいて本物の製品市場に適合します。 しかし、ここでは、あなたがゼロからモデルを訓練していない場合でも、概念の証明から生産にAIアプリケーションをスケーリングすることは、盲目的に迷路を歩くようなものです。 To understand it better, let's break this down with a real-world example. Imagine we're building “ResearchIt” (not a real product, but bear with me), an application that helps researchers digest academic papers. Want a quick summary of that dense methodology section? Need to extract key findings from a 50-page paper? Our app has got you covered. Version 1.0: The Naive Approach バージョン 1.0: The Naive Approach 私たちはOpenAIのハイプ列車で高く乗っています - 私たちの最初のバージョンは美しくシンプルです。 研究者は紙の部分をアップロードします(特定の、関連するセクション) 私たちのバックエンドは、「あなたは役に立つ研究アシスタントです。以下のテキストを分析し、ユーザーが提供するセクションから厳密に洞察を提供します。 Magic happens, and our users get their insights. マジックが起こる、そして私たちのユーザーは彼らの洞察を得る シンプルさは素晴らしい! コストは?それほどではない。 より多くの研究者が私たちのツールを発見するにつれて、私たちの毎月のAPI請求書は電話番号のように見え始めています。問題は、トヨタ・コロラがしばしばうまくいくときに、言語モデルのRolls-RoyceのGPT-5にすべてのクエリを送っていることです。 はい、GPT-5は、その128kのコンテキストウィンドウと強力な推論能力で強力ですが、1Mの入力トークンあたり1.25ドルと1Mの出力トークンあたり10ドルで、コストが急速に増加します。 MetaのLLaMA(3または4シリーズ)やMistralのさまざまなモデルなどのオープンソースモデルは、一般的またはドメイン特有のタスクのための柔軟かつコスト効率的なオプションを提供します。 本当の選択は、以下のことに依存します。 出力品質: モデルはアプリケーションに必要な精度を一貫して提供できますか? モデルは使用したい言語をサポートしていますか? 応答速度:ユーザーはこれらの追加ミリ秒を待つだろうか? より良い結果を得るために、どのアプリの典型的な応答時間は、ユーザーが興味を失わないために10秒のマーク内でなければならないので、スピードは間違いなく重要です。 データ整合性:あなたのデータはどれほど敏感であり、プライバシーの要求は何ですか? Resource Constraints: What's your budget, both for costs and engineering time? 私たちの研究論文アナリストのために、私たちは量子物理学についての詩を必要としませんが、信頼性の高い、費用対効果の高い概要が必要です。 Bottom Line:あなたのアプリケーションニーズを知る Bottom Line:あなたのアプリケーションニーズを知る あなたの実際の要件に基づいてあなたのLLMを選択し、純粋なパワーではなく、あなたが迅速なセットアップを必要とする場合、独自のモデルはコストを正当化することができます。 研究者は密集した学術論文を概要する方法を愛し、私たちのユーザーベースは急速に成長しています。しかし、今、彼らはもっと欲しがっています;彼らがアップロードするセクションを概要する代わりに、彼らは効果的に論文全体でターゲットされた質問を質問する柔軟性を望んでいます。シンプルに聞こえます、正しいですか? 単に全体の文書をGPT-5に送信して魔法を働かせてください。 あまり速くありません。学術論文は長いです。GPT-5の寛大な128Kトークン制限でさえ、クエリごとに完全な文書を送信することは高価なオーバーキルです。 最先端の研究を実施する際に有害である。 劣化 劣化 では、その解決策は何でしょうか。 Version 2.0: Smarter chunking and retrieval バージョン 2.0: Smarter Chunking and Retrieval ここで重要な質問は、APIの請求書を火に付けることなく、この要件を満たすためにどのようにスケールするか、そしてシステムの精度を維持するかです。 **Answer is: \ (RAG) LLMにすべてのドキュメントを投げ込む代わりに、私たちはクエリをする前に最も関連するセクションを賢く取得します。この方法では、トークンを保存するためにLLMに毎回すべてのドキュメントを送信する必要はありませんが、関連するブロックがLLMがそれを使用して回答するための文脈として回収されることを確認します。 「Retrieval-Augmented Generation」 「Retrieval-Augmented Generation」 There are 3 important aspects to consider here: チャンピオン ストレージ & Chunk Retrieval 先進的なリサイクル技術を用いた精製。 Step 1: Chunking - ドキュメントをスマートに分割する 我々は関連するセクションを取得する前に、我々は管理可能なブロックに紙を分割する必要がある。天才的なアプローチは、テキストを固定サイズのセグメントに分割するかもしれない(言い換えれば、500単語ごとに)しかし、これは中途半端にコンテキストを失うリスクを冒します。 もし一つのブロックが「実験は98%の成功率を示した......」で終わったら想像してください・・・そして次のブロックは、「初期段階の肺がん検出における偽ポジティブを減らす」で始まる。 Section-based chunking: 論理的な分割を作成するために、ドキュメントの構造(タイトル、抽象、方法論など)を使用します。 Sliding window chunking: Overlap chunks slightly (e.g., 200-token overlap) to preserve context across boundaries. スライディングウィンドウクンクンキング:スライディングウィンドウクンクンキング: Overlap chunks slightly (e.g., 200-token overlap) to preserve context across boundaries. : Dynamically adjust chunk sizes based on sentence boundaries and key topics. アダプティブ Chunking セクションベース Chunking スライディングウィンドウ Chunking アダプティブ Chunking Step 2: Intelligent Storage and Retrieval (インテリジェントなストレージとリクエスト) あなたのドキュメントのブロックが準備ができたら、次の課題は効率的に保存し、回収することです。 数百万のブロックを処理する現代のLLMアプリケーションで、あなたのストレージ選択はパフォーマンスに直接影響を与えます。 ストレージと回収を分離する伝統的なアプローチはしばしば短縮されます。 代わりに、ストレージアーキテクチャは、異なるパターンがスピード、スケーラビリティ、柔軟性のための異なる交換を提供するので、回収を念頭に設計する必要があります。 構造化データのためのリレーショナルデータベースと非構造化データのためのNoSQLを使用するという従来の区別は依然として適用されますが、一方で、LLMアプリケーションはテキストだけでなく、セマンティックな表現(埋め込み)を保存します。 従来の設定では、ドキュメントのブロックとその埋め込みはPostgreSQLまたはMongoDBに格納される可能性があります. This works for small to medium-scale applications but has clear limitations as data and query volume grow. ここでの課題はストレージではなく、検索メカニズムです。伝統的なデータベースは正確なマッチと範囲のクエリで優れているが、それらはセマンティックな類似性の検索のために構築されていなかった。 ベクターの類似性の検索を可能にします。これはベクターデータベースが本当に輝く場所です - 彼らはLLMアプリケーションが要求するストアとリトリビューブパターンのための目的で構築されています - クエリの主な属性として埋め込みを扱い、最も近い隣の検索のために最適化します。本当の魔法は、彼らが類似性の計算を処理する方法にあります。伝統的なデータベースはしばしばクエリ時に複雑な数学的操作を必要としますが、ベクターデータベースは、クエリの時点で専門的なインデックス構造を使用します。 (Hierarchical Navigable Small World) Inverted File Index)は、類似性の検索を驚くほど速くするためです。 pgvector HNSW IVF pgvector HNSW IVF 彼らは通常、2 つの主要な類似性メトリクスをサポートします: Euclidean Distance: ベクター間の絶対的な違いが重要である場合に適合し、特に埋め込みが等級関係をコードする場合に役立ちます。 コジン類似性:セマンティック検索の標準選択 - これは、大きさではなくベクトルの方向に焦点を当てています. これは、同じ意味を有する2つの文書が異なる長さでも効果的に一致することができることを意味します。 Choosing the right vector database is critical for optimizing retrieval performance in LLM applications, as it impacts scalability, query efficiency, and operational complexity. HNSW-based solutions like そして 効率的なリコールと迅速な ANN 検索を提供 - 自動的にスケーリングを処理し、最小限のオペレーティングオーバーヘッドでダイナミックなワークロードに最適です。 (IVFベース) は、より多くのコントロールとコスト効率性を提供しますが、慎重な調節が必要です。 pgvector は Postgres と統合され、ハイブリッド検索を可能にしますが、高出力ワークロードでは限界に達する可能性があります。 Pinecone Weaviate ミルヴァス ピネコ Weaviate ミルヴァス ステップ3: Advanced Retrieval Strategies Building an effective retrieval system requires more than just running a basic vector similarity search. While dense embeddings allow for powerful semantic matching, real-world applications often require additional layers of refinement to improve accuracy, relevance, and efficiency. By combining multiple retrieval methods and leveraging Large Language Models (LLMs) for intelligent post-processing, we can significantly enhance retrieval quality. 検索システムにおける共通の課題は、正確さと回顧のバランスをとることです。キーワードベースの検索(例えば、BM25,TF-IDF)は、正確な用語の匹敵を見つけるのに優れていますが、セマンティックな理解に苦労します。 これを克服するために、ハイブリッド回収戦略は、両方の方法の強みを組み合わせています。 これは関連する: Retrieving candidates – running both a keyword and vector similarity search in parallel. 合併結果 - クエリの種類とアプリケーションのニーズに基づいて各検索方法の影響を制御します。 最適な順序のための再ランキング - 最も関連する情報がセマンティック要件に基づいてトップに表示されることを保証します。 もう一つの課題は、伝統的なベクトル検索がトップKの最も近い埋め込みを取得することです。LLMは文脈ウィンドウに依存するため、トップKの結果を盲目的に選択すると、無関係な情報を入力するか、重要な詳細を見逃す可能性があります。この問題の解決策の1つは、LLM自体を精密化するために使用することです。より具体的に、私たちは、ユーザーの質問に基づいて一貫性と関連性を検証するために、リクエストされた候補者をLLMに送ります。 LLMの洗練に使用されるいくつかの技術は次のとおりです。 Semantic Coherence Filtering: Raw top-K 結果を供給する代わりに、LLM は、検索された文書がクエリに関連する論理的進展に従っているかどうかを評価します。 : Models like Cohere Rerank, BGE, or MonoT5 can re-evaluate retrieved documents, capturing fine-grained relevance patterns and improving results beyond raw similarity scores. Relevance-Based Rerankingについて Context Expansion with Iterative Retrieval: Static retrieval can miss indirectly relevant information. LLMs can identify gaps, generate follow-up queries, and adjust the retrieval strategy dynamically to gather missing context. LLMs can identify gaps, generate follow-up queries, and adjust the retrieval strategy dynamically to gather missing context. LLMs can identify gaps, generate follow-up queries, and adjust the retrieval strategy dynamically to gather missing context. LLMs can identify gaps, generate follow-up queries, and adjust the retrieval strategy dynamically to gather missing context. Semantic Coherence フィルタリング Relevance-Based Rerankingについて コンテキスト拡張 Iterative Retrieval 現在、これらの更新により、私たちのシステムは複雑な質問を複数の紙のセクションで処理するのにより良い設備を備えていますが、回答を提供されたコンテンツに厳密に基づいて正確性を維持します。 Version 3.0 - Building a Comprehensive and Reliable System Version 3.0 - Building a Comprehensive and Reliable System この時点で、「ResearchIt」は単純な質問回答システムから、アップロードされた論文から重要なセクションを抽出し、方法を強調し、技術的なコンテンツを正確に概要する有能な研究アシスタントに成長しました。 単一の論文を概要または解釈するために設計されたシステムとして始まったものは、研究者が深く、クロスドメインの推論のために使用したいツールになりました。 新たな質問の波は、次のように見えます。 「どのトランスフォーマーの最適化技術が、ベンチマーク、オープンソースの実装、および最近の研究論文から得られた洞察を組み合わせるときに最も効率性の向上を示しているのですか?」 「この論文で報告されたモデル圧縮の結果は、他の論文やベンチマークデータセットで報告されたパフォーマンスとどのように一致するのですか?」 これらはもはや単純なリサイクルタスクではありません。 複雑な情報を統合し解釈し、計画し、適応し、ツールを効果的に使用し、エラーから回復し、根拠に基づいた証拠ベースの合成を生成する能力。 マルチソース推論 Despite its strong comprehension abilities, “ResearchIt” 2.0 struggles with two major limitations when reasoning across diverse information sources: クロスセクション分析: 答えが解釈と計算の両方を必要とする場合(例えば、テーブルからFLOPまたは正確性を抽出し、条件を越えてそれらを比較する) モデルは、数字を抽出するだけでなく、文脈と意味を理解する必要があります。 クロスソース合成:関連するデータが複数のシステム(PDF、実験ログ、GitHub repos、または構造化されたCSV)に存在する場合、モデルは検索を調整し、矛盾する結果を結合し、一つの一貫した説明を生み出す必要があります。 These issues aren’t just theoretical. They reflect real-world challenges in AI scalability. As data ecosystems grow more complex, organizations need to move beyond basic retrieval toward reasoned orchestration - systems that can plan, act, evaluate, and continuously adapt. トランスフォーマー最適化技術の分析に関する最初の質問を、私たちは人間としてこの問題をどのように解決するでしょうか。 研究者や学生のグループは、「文献レビュー」に取り組むこと、すなわち、トピックに関する論文をまとめ、オープンソースのgithub reposを研究し、ベンチマークデータセットを識別します。彼らはその後、FLOP、遅延、これらのリソースからの正確さなどのデータとメトリクスを抽出し、標準化および計算合計を生成し、生成された結果を検証します。 So, what exactly did we do here? 総合的な質問をより小さい、焦点を当てたサブ問題に分解します - どのソースを検索するか、どのようなメトリクスを分析するか、どのように比較を実行するべきか。 Consult domain experts or trusted sources to fill knowledge gaps, cross-verify metrics, and interpret trade-offs. 最後に、洞察を一貫した、証拠に基づく結論に合成し、結果を比較し、反復を通じて一貫性あるいは影響力のある結果を強調します。 これは、本質的に、推論されたオーケストラ化 - 複数のシステムや視点で情報を計画し、収集し、分析し、合成する調整されたプロセスです。 Step 1: Chain of Thought / 計画の連鎖 第一の側面に取り組むには、答える前に複数のステップを通して推論する能力、 (CoT) was introduced. CoT allows models to plan before execution, eliciting structured reasoning that improves their interpretability and consistency. For e.g, in analyzing transformer optimization techniques, a CoT model would first outline its reasoning path - defining the scope (training efficiency/ model performance/scalability), identifying relevant sources, selecting evaluation criteria and the method of comparison and establishing an execution sequence. 思考の連鎖 思考の連鎖 この構造化された推理アプローチは、LangChainベースのオーケストラーションの基礎となった。質問がより複雑になっていくにつれて、単一の推理の「チェーン」がTree of Thought(ToT)またはGraph of Thought(GoT)アプローチへと進化し、分岐推理と「前向きに考える」行動を可能にし、モデルが最良の方法に合致する前に複数の解決方法を探求する。 もちろん、これらの推理に重いモデルを採用することは、実践的な考慮を導入します - 主に、コスト。 複数のステップ推理チェーンを実行することは計算的に高価であるので、モデル選択は重要です。 OpenAIのo3とo4ミニのような閉鎖型モデルは、高品質の推論と強力なオーケストラ能力を提供しています。 DeepSeek-R1のようなオープンソースの代替品は、より柔軟性とエンジニアリングの努力を伴う透明な推論を提供します。 非思考のLLMs(LLaMA 3のように)はまだCoT推奨を通じて推論を模することができますが、真のCoTまたはToTモデルは本質的に構造化した推論をネイティブに実行します。 Step 2: Multi-source workflows - エージェントを呼び出す機能 複雑な問題を論理的ステップに分解することは、戦いの半分に過ぎません。 システムは、次のような質問に答え、タスクを実行し、データを収集し、環境との反復的な相互作用を通じてその理解を改善するために、さまざまな専門ツールを組み合わせなければなりません。 OpenAI introduced as the first step to address this situation. Function calling/ tools gave the LLMs its first real ability to 単にテキストを予測するのではなく、モデルにツールキットを提供します - 例えば、 または モデルは、どちらを呼ぶか、いつ呼ぶか、どの順序で決定します。 呼び出し機能 行動する search_papers()、 extract_table()、 統計(統計) 呼び出し機能 Task: “Compute the average reported accuracy for BERT fine-tuning.” 関数呼び出しを使用するモデルは、このような線形チェーンを実行することによって応答する可能性があります。 search_papers("BERT fine-tuning accuracy") extract_table() for each paper (各紙のためのテーブル) calculate_statistics() to calculate the mean を計算する LLMとツールのセットが事前定義されたコードパスを通じてオーケストラレートされる単純な決定的なパイプラインのこの愚かな例は、単純で効果的であり、しばしばさまざまな用例の目的を果たすことができます。 and . When more complexity is warranted, an might be the better option when flexibility, better task performance and model-driven decision-making are needed at scale (with the tradeoff of latency and cost). ラインナップ 非適応 agentic workflow エージェントワークフロー Iterative agentic workflows are systems that don’t just execute once but . Like a human researcher, the model learns to recheck its steps, refine its queries, and reconcile conflicting data before drawing conclusions. Reflect, Revise, and Re-Run Think of it as a well-coordinated research lab, where each member plays a distinct role: Retrieval Agent: The information scout. It expands the initial query, runs both semantic and keyword searches across research papers, APIs, github repos, and structured datasets, ensuring that no relevant source is overlooked. 最初のクエリを拡張し、研究論文、API、github repos、および構造化されたデータセットを介して、関連するソースが無視されないようにします。 抽出エージェント: データワンガラー. It parses PDFs, tables, and JSON outputs, then standardizes the extracted data - normalizing metrics, reconciling units, and preparing clean inputs for downstream analysis. 抽出エージェント: データワンガラー. それはPDF、テーブル、JSON出力を解析し、その後抽出されたデータを標準化します。 コンピュータエージェント:アナリスト. それは、トレンドを定量化し、抽出されたデータが意味があることを確認するために必要な計算、統計テスト、および一貫性チェックを実行します。 認証エージェント:品質ゲートケーパー. それは異常、欠けているエントリ、または矛盾する発見を識別し、何かが見えなくなったら、自動的に再実行または追加の検索を引き起こし、空白を埋める。 Synthesis Agent: The integrator. It pulls together all verified insights and composes the final evidence-backed summary or report. それぞれが明確化を要求し、分析を再開したり、文脈が不完全であるときに新しい検索を引き起こしたり、本質的に自己修正ループを形成することができる - 実際の研究チームがどのように機能するかを反映する専門的な推論システム間の進化する対話。 これを、これらのエージェントが私たちのトランスフォーマー効率の問題にどのように作用するかについて、より具体的な例に翻訳する: Initial Planning (Reasoning LLM): The orchestrator begins by breaking the task into sub-objectives discussed before. First Retrieval Loop: The Retrieval Agent executes the plan by gathering candidate materials — academic papers, MLPerf benchmark results, and open-source repositories related to transformer optimization. During this step, it detects that two benchmark results reference outdated datasets and flags them for review, prompting the orchestrator to mark those as lower confidence. Extraction & Computation Loop: Next, the Extraction Agent processes the retrieved documents, parsing FLOPs and latency metrics from tables and converting inconsistent units (e.g., TFLOPs vs GFLOPs) into a standardized format. The cleaned dataset is then passed to the Computation Agent, which calculates aggregated improvements across optimization techniques. Meanwhile, the Validation Agent identifies an anomaly - an unusually high accuracy score from one repository. It initiates a follow-up query and discovers the result was computed on a smaller test subset. This correction is fed back to the orchestrator, which dynamically revises the reasoning plan to account for the new context. Iterative Refinement: Following the Validation Agent’s discovery that the smaller test set introduced inconsistencies in the reported results - the Retrieval Agent initiates a secondary, targeted search to gather additional benchmark data and papers on quantization techniques. The goal is to fill missing entries, verify reported accuracy-loss trade-offs, and ensure comparable evaluation settings across sources. The Extraction and Computation Agents then process this newly retrieved data, recalculating averages and confidence intervals for all optimization methods. An optional Citation Agent could examine citation frequency and publication timelines to identify which techniques are gaining traction in recent research. Final Synthesis: Once all agents agree, the orchestrator compiles a verified, grounded summary like - “ ” Across 14 evaluated studies, structured pruning yields 40–60 % FLOPs reduction with < 2 % accuracy loss (Chen 2023; Liu 2024). Quantization maintains ≈ 99 % accuracy while reducing memory by 75 % (Park 2024). Efficient-attention techniques achieve linear-time scaling (Wang 2024) with only minor degradation on long-context tasks (Zhao 2024). Recent citation trends show a 3× rise in attention-based optimization research since 2023, suggesting a growing consensus toward hybrid pruning + linear-attention approaches. パワフルなのは、ここで終わりの結果だけではなく、それは . process それぞれのエージェントは、貢献し、挑戦し、安定した複数のソースの結論が出るまで他者の仕事を改良します。 そして MCP は、モデルやツールが収集された文書、パスティングテーブル、または計算された結果などの構造化された情報を交換する方法を標準化し、各エージェントが他者の出力を理解して構築できるようにします。これを補完することにより、A2A コミュニケーションは、エージェントが相互に直接調整することを可能にします - 中間的な推論状態を共有し、明確化を要求したり、介入なしにフォローアップアクションを引き起こしたりします。 モデル・コンテキスト・プロトコル(MCP) Agent-to-Agent (A2A) モデル・コンテキスト・プロトコル(MCP) Agent-to-Agent (A2A) Step 3: Ensuring Groundedness and Reliability At this stage, you now have an agentic system that is capable of breaking down relatively complex and abstract research questions into logical steps, gathering data from multiple sources, performing calculations or transformations where needed, and assembling the results into a coherent, evidence-backed summary. But there’s one last challenge that can make or break trust in such a system: hallucinations. LLMs don’t actually facts - they predict the next most likely token based on patterns in their training data. That means their output is fluent and convincing, but not always 改善されたデータセットと訓練目標が役立つ一方で、実際のセキュリティは、モデルがリアルタイムで生成するものを検証し、訂正できるメカニズムを追加することから来ています。 know 正解 Here are a few techniques that make this possible: ルールベースのフィルタリング: ユーザーに到達する前に明らかなエラーをキャッチするドメイン特有のルールやパターンを定義します. For example, if a model outputs an impossible metric, a missing data field, or a malformed document ID, the system can flag and regenerate it. クロス検証: 信頼できる API、構造化データベース、またはベンチマークを自動的に再クエリして、キー番号や事実を確認します。 モデルが「構造化された切断がFLOPを50%削減する」と述べている場合、システムはそれを受け入れる前にベンチマークデータに対してクロス検証します。 Self-Consistency Checks: Multiple reasoning passes generate and compare them. Hallucinated details tend to vary between runs, while factual results remain stable - so the model keeps only the majority-consistent conclusions. 幻想的な詳細は実行間で異なりますが、実際の結果は安定しています。 共に、これらの層は最終的な保護を形成します - 論理のループを閉じます. システムが生成するすべての答えは、単に良好に構造化されているだけでなく、 . verified そしてここに - 単純なリサーチベースのモデルとして始まったものは、今では強力な研究アシスタントに発展しました: 基本的なQ&Aに答えるだけでなく、複数のソースのデータを統合し、計算を実行し、地盤の洞察を生み出すことによって深い分析の質問に取り組むだけでなく、幻覚や誤った情報に対する積極的な防御をしながら。