「パフォーマンス」が2つの異なる意味を持つ理由
記事は、技術分野における「パフォーマンス」の定義が文脈によって異なることを指摘する。開発者や企業は、処理速度とリソース効率の両面を考慮し、具体的な指標に基づいて評価する必要がある。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
TLDR: AI アプリケーションにおける「パフォーマンス」は、インフラストラクチャの指標（レイテンシ、スループット、コスト）と結果の品質（精度、適合度、関連性）という 2 つの異なる概念を指します。これらを混同すると混乱が生じます。本稿ではその違いを解説し、両者を独立して議論することがなぜ重要かを説明します。
AI アプリケーションに関する会話では、「パフォーマンス」という言葉が頻繁に飛び交います。チームは往々にして「パフォーマンスのために最適化する必要がある」や「最新デプロイ後にパフォーマンスが後退した」と発言しますが、結局のところ「パフォーマンス」という単語自体は特定の指標を指しているわけではありません。
パフォーマンスは、インフラストラクチャの速度と効率性（how fast and efficient your infrastructure is）と、結果の正確性と有用性（how accurate and useful your results are）という 2 つの根本的に異なる技術的概念を記述するものです。これらを混同すると、チーム間の整合性が失われ、ステークホルダーとの間で期待が外れる原因となります。本稿では、各タイプの意味、それらが独立している理由、そしてどのように取り組むべきかを明確にします。
2 つのパフォーマンスのタイプ
信頼性の高い AI プロダクトを構築するには、2 つの別々の「スコアボード」を監視する必要があります。これらはしばしば互いに影響し合いますが、測定には全く異なるツールが用いられます。
インフラストラクチャ・パフォーマンス: これはデータベースチームやプラットフォームチームにアラートが通知されるものです。これは決定論的（deterministic）で定量化可能であり、頻繁にベンチマークされます。これが失敗すれば、従来の意味においてシステムは「破損」していることになります。
- レイテンシ：クエリは 50 ミリ秒で返されたのか、それともユーザーは読み込みスピナーを見つめているのか？
- スループット：トラフィックの急増時にシステムは 1 秒あたり 10,000 クエリを処理できるか？
- コスト：100 万回の操作あたりのコストはいくらか。アプリのユニットエコノミクスは持続可能か？
結果の質： これはユーザーが実際に体験するものであり、プロダクトチームが最も重視する点です。結果の質は検索パイプライン全体によって決定されます。これが失敗すれば、システムは「幻覚」を起こしているか無意味な状態となり、どれだけ高速であっても意味をなしません。
- チャンキング戦略：埋め込み前に文書がどのように分割され、構造化されるか。
- 埋め込みモデル：データをベクトルに埋め込むためのどのモデルを使用するか。
- クエリ埋め込みアプローチ：ユーザーの質問をどのようにベクトル化するか。
- 検索パラメータ：返す結果の数（k 近傍探索）と、フィルタリング対象となるメタデータの種類。
- クエリのルーティングと拡張：1 つのクエリを複数のクエリに分割するかどうか、 tailored な結果のために書き換えるかどうか、および/または返された結果周辺のコンテキストを拡張するかどうか。
- セマンティック検索（意味検索）：インデックスサイズやメタデータフィルタリングを考慮し、埋め込みのどの割合を検索対象とするか。
- 再ランク付けの結果：LLM に到達する前に、関連性に基づいて結果の順序を再配置するための検索後のスコアリング。
- LLM プロンプト、コンテキスト、ガードレール：取得されたコンテキストが最終回答にどのように統合されるか。
ベクトルデータベースの要因: 結果品質のパイプラインは、高品質なセマンティック検索（意味検索）を促進することに中核を置いています。優れたベクトルデータベースは、高い精度でのリコールだけでなく、トップクラスのインデックス化と検索性能を発揮することで、AI インフラストラクチャ層をすぐに使える状態（out-of-the-box）で解決すべきです。これにより、開発者は低レベルのシステム最適化について心配する必要がなくなり、「パフォーマンス予算」をより広範な検索パイプラインに集中させることができます。
なぜこの区別が重要なのか
インフラストラクチャのパフォーマンスと結果の品質は、逆方向に動く可能性があります。ある評価では、チームは 2 つのデータセット版をテストしました。2 つ目のバージョンはコスト削減のためにデータセットサイズの 40% をカットするように最適化されていました。彼らは以下を見つけました：
- インフラのパフォーマンスが改善した：インデックスが小さくなったことでスループットが増加し、コストが低下しました。
- 結果の質が後退した：LLM-as-a-judge（LLM を判定者として用いる手法）を用いて正答性をスコアリングしたところ、新バージョンは期待された性能を発揮できませんでした。根本原因は、関連する回答に不可欠なチャンクを削除してしまった過度なデータプルーニングでした。
- 精度とコストの間のトレードオフが明確になりました。両方のパフォーマンスタイプを独立して測定していなければ、チームはユーザーエクスペリエンスを実質的に低下させる「最適化」を称賛していたでしょう。
何をすべきか
どのパフォーマンスを測定しているのかを明確にしてください。
インフラのパフォーマンスは必須条件です。レイテンシが高い場合やコストが予測不可能であれば、他の要素は何も意味を持ちません。p95 レイテンシ、1 秒あたりのクエリ数、およびクエリあたりのコストを追跡してください。
結果の質はユーザーが目にするものです。正確性スコア、タスク完了率、ユーザーフィードバックを考慮してください。これはパイプライン全体で変更を検証することで最適化し、単一の側面のみを対象にしないようにしてください。
チームがパフォーマンスの後退を報告した際、最初に問うべきは「どのタイプか？」です。
原文を表示
TLDR: In AI applications, "performance" refers to two distinct concepts: infrastructure metrics (latency, throughput, cost) and result quality (accuracy, precision, relevance). Conflating them causes confusion. This post breaks down the difference and shows why discussing both independently matters.
We see "performance" thrown around constantly in conversations about AI applications. Teams often say "we need to optimize for performance" or "performance regressed after the latest deploy". Ultimately, the word "performance" doesn't refer to any specific metric.
Performance describes two fundamentally different technical concepts: how fast and efficient your infrastructure is versus how accurate and useful your results are. Conflating them creates misalignment between teams and missed expectations with stakeholders. This post clarifies what each type means, why they're independent, and how to approach them.
Two Types of Performance
To build a reliable AI product, you must monitor two separate "scoreboards." While they often influence one another, they are measured with entirely different tools.
Infrastructure Performance: This is what database and platform teams get alerted on. It’s deterministic, quantifiable, and frequently benchmarked. If this fails, your system is "broken" in the traditional sense.
- Latency: Did the query return in 50ms, or is the user staring at a loading spinner?
- Throughput: Can the system handle 10,000 queries per second during a traffic spike?
- Cost: What is the cost per million operations? Is the unit economics of the app sustainable?
Result Quality: This is what users actually experience and what product teams care about. Result quality is determined by the entire retrieval pipeline. If this fails, your system is "hallucinating" or useless, even if it’s lightning-fast.
- Chunking strategy: How documents are split and structured before embedding.
- Embedding model: Which model embeds data into vectors.
- Query embedding approach: How user questions get vectorized.
- Retrieval parameters: How many results to return ($k$-nearest neighbors) and what metadata to filter on.
- Query routing and expansion: Whether to split one query into multiple, rewrite it for tailored results, and/or expand the context around returned results.
- Semantic Search: What proportion of embeddings are searched over, accounting for index size and metadata filtering.
- Reranking results: Post-retrieval scoring to reorder results by relevance before they reach the LLM.
- LLM prompt, context, and guardrails: How the retrieved context is synthesized into a final answer.
The Vector Database Factor: The result quality pipeline is centered on fostering a high quality semantic search. A good vector database should solve the AI infrastructure layer out-of-the-box by excelling not only in highly accurate recall, but in top performing indexing and retrieval. This allows developers to stop worrying about low-level systems optimization and focus their "performance budget" on their greater retrieval pipeline.
Why the Distinction Matters
Infrastructure performance and result quality can move in opposite directions. In one evaluation, a team tested two dataset versions where the second was optimized to reduce cost by cutting 40% of the dataset’s size. They found:
- Infrastructure performance improved: Throughput increased and costs fell because the index was smaller.
- Result quality regressed: Using an LLM-as-a-judge to score correctness, the new version underperformed. The root cause was aggressive data pruning that removed chunks critical for relevant answers.
The tradeoff between accuracy and cost became clear. Without measuring both types of performance independently, the team would have celebrated an "optimization" that actually degraded the user experience.
What to Do
Be explicit about which performance is being measured.
Infrastructure performance is table stakes. If latency is high or cost is unpredictable, nothing else matters. Track p95 latency, queries per second, and cost per query.
Result quality is what users see. Consider accuracy scores, task completion rates, and user feedback. Optimize it by testing changes across the entire pipeline, not just one aspect.
When teams report performance regressions, the first question should be: which type?
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み