あなたのエンジニアリングチームはセマンティックな検索を追加する必要があります. あなたはAlgoliaを実行しています. 彼らは単にベクターを追加しました. あなたはそれを有効にし、魔法を待つ。 代わりに、インフラストラクチャの地獄の3ヶ月を得ます。セマンティックな層は、キーワードインデックスとは異なるデータを必要とします:製品属性、ユーザー行動シグナル、ビジネスロジック。それぞれの関連性の調整はすべてを再インデックスすることを意味します。ハイブリッドクエリは、2つの異なるシステムにヒットし、アプリケーションコードで結果を合併します。あなたは並列インフラストラクチャを維持しています:検索インターフェイス、埋め込みとパーソナライゼーションのためのあなたのサービス、それらを接続する粘着コード。 3ヶ月後には、検索の質を向上させるよりも、建築制約との戦いに時間を費やしていることに気づきます。 これはあなたが理解する瞬間です:あなたは機能を追加しません. あなたは別の時代に構築されたインフラストラクチャにAIのネイティブ要件を再設定しています。 キーワード検索は何のために作られたのか これがなぜ起こるのかを理解するには、実際に何のキーワード検索が解決するように設計されたのかを見る必要があります。 Algolia のようなキーワード検索エンジンは、構造化されたカタログを介して迅速かつ正確な検索で、特定の問題を素晴らしく解決しました。「赤い革ジャケットのサイズが大きい」のようなクエリを用いて、直ちに正確なマッチを返し、側面(色、材料、サイズ)でフィルターし、人気や価格のようなシグナルでシンプルにランキングします。ソリューション(BM25スコアでインバウンドインデックス)はエレガントで効果的です。ドキュメントに検索タブレットのマッピング用語を構築し、用語の頻度のための統計的重量を追加し、側面にレイヤーを加え、美しくスケールするシステムがあります。 このアーキテクチャは、古典的な電子商取引の検索、文書の検索、カタログの閲覧に最適です。キーワードの検索は、正確なマッチ、迅速なファセッティング、予測可能なランキングを印象的な効率で提供します。 問題は、キーワード検索が悪いテクノロジーであるということではありません。基本的な要件は変化しました。検索は「これらのキーワードに匹敵する文書を見つける」という意味を意味していました。今では、「複数のシグナルを含む意図を理解し、複雑で文脈的関連性によってランクインする」という意味です。 AI Native Search Shift この建築的な不一致は理論的なものではなく、検索が実際に意味する根本的な変化によって引き起こされています。 現代の検索クエリは単純なキーワード検索ではありません。ChatGPTの発売後、AlgoliaのCTOは検索クエリあたり2倍のキーワードを見ていると報告しました。ユーザーは自然言語を期待しています。「150ドル未満のマラソントレーニングのための快適なランニング靴」のようなクエリは、キーワードのマッチを検索しません。それはセマンティックな理解(マラソンに靴を快適にしますか?)、数値制限(価格)、およびカテゴリフィルター(製品タイプ、使用ケース)を含む意図を表します。 これは段階的な進化ではありません。これは段階的な変化です。ユーザーの期待は一晩を通して変化しました。今日のインフラストラクチャの選択は、今後5年間の検索速度を決定します。AIネイティブの基盤を再構築するチームは、毎週関連性を繰り返します。 AI Native Search は、以下のことを必要とします。 
 
 
 
 
 
 Semantic understanding across unstructured text, not term matching 非構造化されたテキストを含むセマンティックな理解 組み込み、行動データ、ビジネスルール、およびメタデータを一貫したランキングに組み合わせたマルチシグナルスコアリング ユーザーの文脈と履歴に適応する個別化 Multimodal reasoning handling text, images, structured attributes, and temporal signals(テキスト、画像、構造化属性、時間信号の処理) Continuous iteration through evaluation loops, not config tweaks(評価ループを通じて継続的なイテレーション) これらの機能にはインフラレベルの統合が必要です:どのようにデータをインデックスし、クエリを構築し、結果を評価します。それらはあなたが組み合わせる個々の機能ではありません。 Where Keyword-First Architecture Hits the Wall(キーワードファースト・アーキテクチャーが壁を叩く場所) 建築的な不一致は予測可能な方法で表面に現れ、そこでチームが一貫して壁にぶつかった。 Breaking Point #1: Schema Rigidity Meets Complex Scoring スケジュール あなたは電子商取引製品の検索を構築しています。あなたはセマンティックの類似性、ユーザーの行動のシグナル、ビジネス制約、および最近の状況でランクアップする必要があります。 キーワードファーストアーキテクチャでは、各信号は別々に生存します。テキスト記述は逆のインデックスに含まれます。アナリティクスにおける行動データ。アプリケーション論理におけるビジネスルール。ベクトルは別のサービスを通じて引き継がれています。あなたは4つのシステムを維持し、あなたが書いたコードで出力を統合しています。 これらの組み合わせの方法を調整したいですか? あなたはアーキテクチャと戦っています。 「セマンティックに類似した製品を見つけて、変換率で増加し、マージンでフィルタし、リリース後数日で減少する」と表現するために、あなたはカスタマイズされた合併論理を書いています、システム間のキャッシュ無効化を管理し、アプリケーション層のスコアがあなたの望むものに近いことを望んでいます。 AI ネイティブの検索では、関連性は実験的である:評価を実行し、NDCG (ランキング品質)またはMRR (回復精度)を測定し、重量を調整し、展開します。 異なるスケジュールと更新頻度を持つ複数のシステムで論理スキャッターをスコアするとき、評価は研究プロジェクトになります。 あなたは「重量ユーザーの行動が30%高い」を迅速にテストすることはできません。 Breaking Point #2:Vectors as Bolt-On vs. First-Class Primitive Enter or click to view image in full size (画像を完全に表示する) 「We added vector search」の発表は有望で、次にハイブリッド検索を構築し、シームを発見します。 キーワード検索は、逆のインデックスで行われます。別々のサブシステムでベクター検索があります。それぞれが独自のクエリパス、ランキングモデル、パフォーマンス特性を持っています。あなたは「機械学習展開の課題に関する最近の記事」を望みます:セマンティックな理解、キーワードの精度、タイムフィルタリング。アプリケーションコードに合併した2つの独立した検索が得られます。 合併は驚くほど困難です。キーワードの関連性スコアとベクターの類似性をどのように正常化しますか?キーワードの検索が100の結果を返すと、ベクターが10の結果しか見つからない場合はどうなりますか?インフラストラクチャ層に属するパフォーマンス最適化や評価フレームワークなしで、検索エンジンの仕事でなければならないランキング論理を書いています。 チケット、ドキュメント、チャットログを介してクライアントサポートの検索:ユーザーは自然言語で尋ねるが、チケットID、エラーコード、製品名の正確なマッチが必要です。 ボルトオンアーキテクチャでは、これを自分で管理します。インデックスを分離し、論理を統合し、不一致をデバッグします。インフラストラクチャは、検索の機能を変えるコア原理ではなく、アドオンとしてベクトルを扱います。 Breaking Point #3: The Iteration Gap(イテレーション・ギャップ) 検索の質を体系的に改善するときに最も深い制限の表面。 AI ネイティブの検索では、関連性は実験的である:メトリクスを定義し、評価を実行し、再起動します。キーワードの最初のプラットフォームはこれのために構築されていませんでした。 所有権の問題:あなたは独自の埋め込みモデル、カスタマイズされたリランキング、あなたのパーソナライゼーションシステムを望んでいます。 そこで、あなたは影システムを実行します。キーワード検索のためのAlgolia、埋め込みのためのインフラストラクチャ、ハイブリッドスコアリングとパーソナライゼーションのためのコードです。あなたは、実際に必要なコンポーネントを構築しながら、マネージド検索のために支払っています。コストは単に財政的なものではありません。それは操作の複雑さ、データ同期化、フランケンシュタインアーキテクチャの管理です。 改善を推進すべきフィードバックループ(実験、測定、反復)は、エンジニアリングプロジェクトになります。新しいアプローチを迅速にテストしたり、変更が関連性を向上させるかどうかを体系的に評価することはできません。 AI-Native Search Infrastructureについて これらの突破点を直接解決するいくつかの建築原則。 Principle #1: First class AI primitives 組み込み、モデル、およびハイブリッドリリースは、キーワード検索に組み込まれた機能ではありません。それらはコアアーキテクチャコンセプトです。インデックス構造は、キーワードとベクトル検索のための別々のシステムではなく、互いに補完的なメカニズムとして理解された統一されたインフラです。クエリは、自然に「セマンティックの類似性は0.7で重視され、キーワードの精度は0.3で、数値制約によってフィルタリングされます」と説明し、インフラは一貫して実行されます。 原則 #2: Flexible logic ownership プラットフォームは、生産の問題を処理します:スケールでのインデックス、クエリの遅延、信頼性、観察性. あなたは検索の論理を制御します:あなたの埋め込みモデル、スコア機能、パーソナライゼーション. これらは構成パラメータではありません。 それはプログラミング可能なインフラストラクチャです. カスタマイズされたモデルをプラグインし、ビジネス特有のランキングを実装し、既存のパーソナライゼーションシステムを統合し、すべて並列のインフラストラクチャなしで。 原則 #3 : Multi-attribute architecture 複雑なクエリには、テキスト、数値制限、カテゴリフィルター、タイムシグナル、行動データなど、複数のデータタイプが含まれています。AI検索インフラストラクチャはこれらを単一のベクターに圧縮されていない別々の、しかし調整された埋め込みとして表現します。 原則 #4: Eval driven by design システム的な改善には、完全な評価ループをサポートするインフラが必要です:メトリクスを定義し、実験を実行し、パフォーマンスを追跡し、A/Bテストの変更を変更します。 目標は検索インフラストラクチャのすべてのコンポーネントを置き換えることではなく、インフラストラクチャのコア仮定をAIネイティブ検索が実際に必要とするものと調和させることです。 Patch または Rebuild? 建築格差は拡大しつつあるが、各四半期ごとに、キーワードファーストプラットフォームが提供できるものと、ユーザーが期待するものとの間の距離は大きくなっている。 これは明日あなたのバックを引き裂くことではありません。それは軌道を理解することについてです。すべてのウォーカーアウンド(埋め込みのための影のインフラストラクチャ、アプリケーション層の合併論理、マニュアル関連性調節)は技術的な負債です。その負債は結合します。検索があなたの製品により中心的になり、ユーザーの期待が高まるにつれて、より迅速な関連性の改善を望むにつれて、建築的摩擦がボトルネックになります。 本当の疑問は、「AIのためのキーワード検索ができますか?」ではありません。人々は、十分なエンジニアリングの努力と妥協でできます。 検索品質の代わりにインフラストラクチャのプランビングのエンジニアリング時間。スピード:どれくらいの速さで実験して改善できますか?品質の限界:これらの制約の中で何が可能でしょうか? 検索品質が競争力のある差異を生むチーム、ユーザーが自然な言語理解と個人的な結果を期待するチーム、評価とイテレーションを通じて関連性が継続的に改善される必要があるチームでは、アーキテクチャの不一致が重要です。 今日あなたが行うインフラストラクチャの決定は、あなたが毎週関連性を繰り返すか、または建築の再書き換えに四半期を費やしているかを決定します。 移行は可能なものについてではなく、持続可能なものについてです. あなたの検索要件が成長するにつれて:あなたはインフラストラクチャと戦っているか、それともそれで構築しているか? Ready to evaluate your options? 
 
 
 
 ベクター DB 比較 - 30 以上のベクターデータベースを比較する VectorHub — AI native search を構築するための実用的なガイド Superlinked - AI native search infrastructure プラットフォーム ベクター DB 比較 ベクターハブ SUPERLINK

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

👉 Join The Tech Audience Accelerator 👈

Read My Stories

このオーディオは、ストーリーの元の言語で制作されています。

Keyword-First Search Can't Scale to AI. Here's What Replaces It

About Author

コメント

ラベル

この記事は

Related Stories

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

フォーラムからフィードへ: ソーシャルメディアアルゴリズムがデジタルインタラクションを形作る仕組み

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

フォーラムからフィードへ: ソーシャルメディアアルゴリズムがデジタルインタラクションを形作る仕組み

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps