このブログでは、エンタープライズサーチについて紹介していきます。 エンタープライズサーチソリューションの選定基準や、組織固有のニーズに基づいた開発におけるヒントをいくつか取り上げます。
本投稿は、エンタープライズサーチの理解を深めたい業務部門の人、事前に主要コンセプトの概要を理解しておきたい技術部門の人(エンジニアなど)の両方の役に立つ内容となっています。
これは単に「ググる」以上のものです。サーチ(検索)は、この世界に関する質問に答えるために情報(ドキュメント/記録/ファクト)を特定する手段の1つですが、エンタープライズサーチはこれを大きく超えます。
エンタープライズサーチには以下の4つのカテゴリがあります。
エンタープライズサーチは、単なるインデックス付けツールではありません。
私たちが考えるエンタープライズサーチとは、使用データに合わせてカスタマイズされた一流の検索「アプリケーション」のことです。カスタム開発されたUIがあり、自社のコンテキストに合わせて答えを返すことで、パーソナライズされた検索体験を提供します。
例えば、MarkLogicのユーザー企業の1つに、シュプリンガー・ネイチャーがあります。彼らの検索アプリケーション、SpringerLinkはエンタープライズサーチの好例です。これは一般公開されています(MarkLogicユーザー企業の検索アプリケーションのほとんどは社内向けに限定されていますが)。一見していただくと、これは Google というよりもAmazon.comに近いことがわかるでしょう。自社のコンテンツに合わせてカスタマイズされており、また収益化を目的としてデザインされています。
もう1つの例として、BBC Sportのwebサイトがあります。これはほとんど検索アプリケーションには見えません。右上に検索ボックスがあるくらいです。しかしこのサイトのコンテンツはセマンティック検索を活用しており、ユーザーに合わせてかなりカスタマイズされています。
3つめの例は、最近私たちが発表したファーマリサーチハブです。これの技術的基盤は、先ほどと同様MarkLogic® データハブプラットフォームです。しかし製薬研究データ(遺伝子、化合物、論文など)の検索用にカスタマイズされています。
これらはそれぞれ大きく異なっています。これらを見ると、検索開発者がどれほど強力かつ多様なものを生み出せるのかがわかると思います。
ここでは、まず何をやったらよいのでしょうか。
必要なステップは次のようになります。それぞれについては詳しく後述します。
「データクエリアプリケーション」では、ユーザーにかなり助けてもらっています。指定フィールドに入力してもらったり、SQL(のようなもの)を記述してもらうことすらあります。 しかし検索アプリケーションでは、いくつか言葉を入力したら完璧な結果が返ってくることをユーザーは期待しています(Google のように)。以下に、検索アプリケーションにおいて、わずかな情報に基づいてユーザーが何を求めているのかを把握する方法をいくつかご紹介します。
単語や語句ごとに、対象ドキュメントに出現する語句の表現をアプリケーション側で追加しておくものです。クエリ拡張の一般的なテクニックとして以下があります。
世界や得意分野に関する知識を活用して、検索タームを拡張して関連するタームも含めます。
例えば、今後製造を開始する製品に関する安全基準を調べたいとします。検索エンジンの場合、「心臓カテーテル」と入力すると、この語句が含まれる結果のみが返されます。しかしセマンティック検索の場合、「『心臓カテーテル』は体内埋め込み機器」であり、「『体内埋め込み機器』は『無菌状態』で使用する」といった知識を活用できます。これは重要であり、「心臓カテーテル」で検索した場合、「体内埋め込み機器」および無菌状態で使用するその他の機器に関する安全基準も返すようにできます。
ユーザーが入力を開始すると、アプリケーション側が想定する単語・語句のリストを表示します。
この機能によりタイピングが減るため、ユーザーには人気です。アプリケーションにとっても、間違っていない綴り・文字(インデックスが付いている)が使用されるので、好ましいです。またオートコンプリートによってアプリケーションがユーザーを導くことができます(人気順/新着順/ユーザーの分野・業務における重要度などで並べることで)。
検索画面に一連のファセットを追加することで、検索対象を明示的に絞り込めます。ほとんどのユーザーはファセットに馴染みがあります。例えば、Amazon.comでは、ブランドや価格帯で検索を絞り込めます。
ファセットでは、アプリケーションがユーザーにさらに作業してもらうようになっていて、データクエリユーザーがフォームに入力するのにちょっと似ています。しかしこの方が、ユーザーが本当は何を探しているのかがさらにはっきりと分かるようになります。ファセット検索はより厳密な検索に適しています。インサイト(検索結果の概要と件数を表示)および検索領域の探索に適しています。
「次の検索結果を表示しています [x]」。サジェスト機能により、アプリケーションはユーザーが本当に言いたかったことを確認できます。例えば、ユーザーが「Apache」と入力した際、「知りたいのはApacheヘリコプター、Apache族、Apacheソフトウェア財団のどれですか」とアプリケーションがユーザーに聞くことができます。
開発者は、タームの重み/フィールドの重み/ドキュメントのクオリティなどに基づいて検索結果を並べ替えることができます。最も関連性が高いものを検索結果の一番上に表示できることが重要です。「最も関連性が高い」というのは若干主観的です。これは、ユーザー/ロール/作業中のタスク/検索対象分野/入力された検索ターム/結果のコンテンツによって変わってくるからです。
通常、各結果の関連度(重要度)スコアはTF-IDFに基づいて検索インデックスによって計算されます。
例えば、ユーザーが「president」を検索している場合、検索インデックスは各結果における「president」の出現件数を数えます。これがTF(term frequency:単語の出現頻度)です。またこの単語を含むコーパス全体のドキュメント数も数えます。これがDF(document frequency:ドキュメントの出現頻度)です。珍しい単語の方がより重要なので、インデックスはその珍しさの指標としてIDF(inverse document frequency:逆ドキュメント頻度)を計算します(ある単語がドキュメント2件に1回だけ出現する場合、IDFは1/2。ドキュメント1000件に1回だけ出現する場合は、IDFは1/1000)。 これにより、「president OR Nixon」で検索した場合、「Nixon」を含むドキュメントの方が「president」を含むドキュメントよりも上位に返されることになるでしょう。
検索アプリケーションでは、こういったデフォルトスコアの計算方法をコンテキストやユースケースに応じて開発者がファインチューニング(微調整)できます。
以下に検索アプリケーションのファインチューニングの仕方をいくつか上げておきます。
いずれの技法においても、「コンテキスト」(どのような種類の情報が検索されているか、ユーザーのロール/タスク/関心)が重要になってきます。検索アプリケーションの構築においては、コンテキストの活用を促進することでユーザーの満足度を向上できます。
適切なドキュメントやデータを見つけたいユーザーに対してインサイトを与えたり、対象領域を探索できるようにすることで、答えとなるデータが見つかるようにします。注釈(アノテーション)を付けることで、適切な検索によって適切な情報が見つけられるようにします。
情報が「神聖不可侵」(変更せずにそのまま保持しなければならない)場合もOKです。その場合、注釈データをオリジナルへのリンクとともに別途格納することもできます。情報がXMLまたはJSONドキュメントとして保存されている場合はさらに好都合で、オリジナルを論理的エンベロープでラップできます。ここでは、注釈をオリジナルと物理的に同じ場所に持つことができます。またオリジナルはそのままのかたちで保持できます。 これは「エンベロープパターン」と呼ばれます。
まず最初に、検索にマッチすべきドキュメントを示す「注釈」から始めます。こうするとドキュメント自体が「もし犬(あるいはニクソンや中国)に関する情報を探しているのなら、私を見つけて!」と言ってくるようになります。これにより検索アプリケーションによってデータを(少なくともメタデータに関しては)完全に制御できるようになります。
これは検索のパラダイムをひっくり返すものです。というのもそれぞれのドキュメントに「自分のことを自分で説明せよ」といっているようなものだからです。具体的には、「見つけられるべきときにユーザーにどんなふうに検索してもらいたいか説明せよ」ということです。
役に立つ「私を見つけて!」注釈には、以下のようなものがあります。
一般的なエンティティタイプとしては、他に会社/組織、場所、物(武器、薬など)、パターン(数値、日付、クレジットカード番号など)があります。これにより、リッチな検索(「北朝鮮から1000マイル以内のアジアの国に、70年代にアメリカ大統領が訪問したことを記述しているレコードをすべて探せ」など)ができるようになります。
エンティティはデータ内にも発生します。データ統合時の問題として、自分たちがどのようなデータを持っているのかを把握していない、ということがよくあります。エンティティを特定することで、どのレコード(の部分)が場所、人、物(武器、薬など)を表現しているのかわかるようになります。
ここまでのところは大丈夫でしょう。検索の開発が順調に進んできて、なかなか良さそうな結果が得られそうです。
しかしこれでも、検索によっては「当たり前だと思われる」ベストな結果が返されないことがあります。例えば、法務データベースで「シチズンズ・ユナイテッド」を検索した場合、一番最初に表示される結果は「シチズンズ・ユナイテッド対FEC裁判、558 U.S. 310」になるべきです。これは対象ドキュメントにおける「シチズンズ・ユナイテッド」の出現回数に関係なくそうなるべきなのです。
この問題に対処するために検索結果をファインチューニングする方法はいくつかあります。
どのようなコーパスにおいても、レコードによってクオリティは異なります。法務データベースにおいては、「シチズンズ・ユナイテッド」に対する判決自体は、この判決に関する議論よりもクオリティが高くなります。別の言い方をすると、これには「より権威がある(公式である)」と言えます。
web検索において、ラリー・ペイジとセルゲイ・ブリンが「ページランク」アルゴリズムを発明しました。これは、Google 検索の成功の大きな要因となっています。ページランクでは、権威あるページが数多くリンクされているwebページほど権威があるということになります。しかし残念ながら、このリンク分析はエンタープライズサーチでは利用できません。
クオリティはさまざまなものの集合体である可能性があります。例えば、ソース(出典)/著者/ドキュメントタイプなどすべてがクオリティに影響します。このため、大企業の社内wikiページ「社員周知事項」に掲載されている社長によるPDFレポートは、「その他」ページに投稿された作者不明の「覚書」というメモ帳ファイルよりもクオリティが高くなります。
検索アプリケーションでは、ドキュメントのクオリティ設定を完全に制御できます。また検索コーパスに関する自分の知識/ロール/タスク/ドキュメントのコンテンツを考慮できます。
クオリティは完全にドキュメント/レコードの属性であり、ユーザーの検索からは独立していることに注意してください。
検索の開発者は、「検索エンジン」およびそのインデックスをリバースエンジニアリングすることで、ユーザーが求めているものを提供するためにかなりの時間と労力を割いています。「検索アプリケーション」では、開発者はいつでもユーザーエクスペリエンスに介入し、自分がしたいように作ることができます。
任意のものから任意のものへ、手作業でマッピングすることもできます。例えば、ユーザーの検索に「シチズンズ・ユナイテッド」という語句が含まれていた場合、結果のトップに必ず「シチズンズ・ユナイテッド対FEC裁判、558 U.S. 310」を返すようにし、「これは2010年1月21日における米国最高裁判所の所見である」という説明を付けることができます。
これはユーザー/分野/ロール/タスクに特化したものです。ユーザーが法学部の学生だった場合、すぐに判決文を見たいと思うでしょう。一方、ユーザーが「シチズンズ・ユナイテッド」に言及したスピーチについて記事を書こうとしている記者の場合、判決文よりもWikiページを見たいかもしれません。
検索(あるいは検索の一部)にベストな結果を割り当てておくこの実践的な手法は「ベスト・ベット」と呼ばれます。ベスト・ベットを追加しておくことで、結果の質およびパフォーマンスが改善されます(ベスト・ベットは検索ではなくシンプルなマッピングであるため)。
一般的な検索エンジンの結果ページでは、ドキュメントの青いリンクがリスト表示されているだけですが、これをもっと素敵にすることもできます。
このステップは大切なので飛ばさないでください。というのも、これはブラウザの機能や視覚化、またコンテキスト情報を最大活用するチャンスだからです。検索対象領域に関するインサイトや、次に何をすべきなのかのヒントをユーザーに与えられます。
検索結果から、ユーザーは次の2つを知りたいと思うでしょう。「結果の上位には何があるのか?」「結果の全体の様子はどのようなものか?」。
ユーザーは上位の検索結果に関する情報を見て、どれをクリックすれば答えが得られるのかを判断します。結果に関する情報が優れている場合、検索結果を見ただけで十分知りたかったことがわかってしまうこともあります。
各結果の情報(今回の検索で解決したい問題に関するドキュメントやレコード)を表示する方法をいくつかご紹介します。
よく利用されている手法として、結果ページの各ドキュメントのリンクの下に「スニペット」を表示します。これはドキュメントの内の数行を表示したもので、検索タームが強調表示されています。スニペットの目的は、一目で「ドキュメントがどんなものか」、「何に関するものなのか」をわかるようにすることです。これにより、これをクリックすべきかどうかを判断できます。
スニペットをよりリッチにする方法を以下にいくつか取り上げます。
各結果に関する情報に加えて、ユーザーはコンテキストも求めています(「結果セットの全体の様子はどのようなものか?」「ユーザーのタスクに役立つ情報としてアプリケーションは他に何を知っているのか?」)。
ファセットについては、ほとんどの人々がAmazon.comなどの小売りサイトで馴染みがあることでしょう。これによって、特定のブランド、価格帯、その他の属性に基づいて検索できます。これについては、検索対象の絞り込み方法の1つとして前述しています。ファセット(および件数)は、結果ページにおいて重要な役割を担っています。これにより結果セットの概要を把握できます。
検索の結果、欲しかったものにかなり近い結果が得られたとします。あるいはユーザーは自分が探していたものを見つけることができたけれど、さらにそれを深堀りしたいとします。ここで、それぞれの結果にリコメンデーションのリンクをつけて、似た結果をさらに提供できます。「似たもの」としては、カテゴリ/メタデータ/エンティティから構成されるものが想定されます。
ワードクラウドは、結果セットにおける最も重要な語を示した画像です。重要なものほど文字が大きくなります。ワードクラウドによっては、色で何らかの内容(感情やエンティティのタイプなど)を表現するものもあります。
関連性(重要度)は通常、この語が出現する結果の件数であり、出現件数とこの語の希少性に基づいて重み付けされていることが多いです(極めて珍しい語が頻出しているものは極めて重要だということです)。ワードクラウドは、結果の概要を示すことができます。つまり「この検索の結果がどのようなものになるのか」を表現します。これがクリック可能な場合、ユーザーが本当に探しているものを提供できます。
ワードクラウドの概念は、さまざな方向に拡張できます。
検索によっては、新しい情報が発生したらすぐに知らせたいこともあります。例えば、ユーザーがブラジルの石油掘削施設のニュースをトラッキングしているとします。ここでアナリストが、毎日(あるいは1時間ごとに)「石油掘削施設 ブラジル」と検索して、何か新しい情報がないか調べることもできます。
このような保存した検索の利用では、満足いくユーザーエクスペリエンスは得られません。第1に、何か新しいことがないかを確認するために同じクエリを何度も実行しなければなりません。第2に、毎日定時にチェックしている場合、情報取得までに最大で1日の遅れが発生する可能性があります。第3に、新しい情報が大量の結果セットのなかに埋もれてしまい、全く目に入らなかったということも起こりえます。
検索アプリケーションでは、検索を保存して後から実行できます。検索を保存したならば、検索が条件を満たした際に取るアクションを割り当てることができます。「石油掘削施設 ブラジル」の例では、この検索に新しいドキュメントが該当した場合にアラートが出る(画面上のフラグあるいはメール通知)ようにアプリケーションを設定できます。該当ドキュメントが読み込まれるとすぐにアラートが自動表示されます(ユーザーが何もしなくても)。
これを効率的に行うには、使用する検索エンジンにアラート用の特別なインデックスが必要です。多くの検索システムにはベーシックなリアルタイムアラートしか備わっていないため、大規模導入においてはうまく機能しません。
「ユーザーは何を検索しているのでしょうか?」「これらの検索は時間の経過に伴いどのように変化しましたか?」「これらの検索では、適切な結果が返されていますか?」「うまくいかない検索はどのくらいの頻度で発生しますか?」「結果が返ってくるスピードは十分早いですか?」
検索アプリケーションを開発している人は、こういった問いに答える必要があります。さらに、文書化されたしっかりとしたSLA(サービスレベル合意書)を持つべきです。 自分のアプリケーションをこのSLAに照らし合わせて定期的(かつ頻繁)に査定し、可能な限りSLAを向上させてください。
これらの問いについてさらに確認していきましょう。
検索アプリケーションのモニタリングの基本は、各検索のテキストをログとして記録することです。誰かが毎日検索ログを確認すべきです。リストをざっと見るだけで驚くほどの情報が得られます。
例えば、ユーザーが欲しがっている結果は何なのか、人間には当たり前にわかることがよくあります。そのような結果となるように、クエリ/データ処理を改善したり、「ベスト・ベット」を使ったりできます。
でも「ユーザーが数百人もいて、何千もの検索をやっているのですよ。すべての検索をモニタリングするには大量のスタッフが必要です」という声が聴こえてきそうです。アルファテストでユーザーが利用を開始したらすぐに検索のモニタリングを始めてください。パターンを発見したならば、この処理を楽にするスクリプトを書くことができます。しかし成熟したスクリプトがあったとしても、一番多い検索は何なのかを毎日確認すべきです。ほとんどの実装では、上位20~50位の検索がユーザーアクティビティの80%を占めます。
検索タームの変化(スパイクや新しい語)を確認しましょう。
スパイク:例えば、金融サービスのユーザーの多くが突然X社に関するドキュメントを検索しはじめたとします。これはX社の収支報告や不正、あるいは他の何らかのスキャンダルがニュースになったことが理由かもしれません。このようなスパイクを初めて見た場合、「ベスト・ベット」(上記参照)を追加し、X社への検索を「完璧な検索結果」や「事前に準備されたドキュメントリスト」にマッピングしておけます。
その後、検索内の会社名を特定し、この会社のスパイクが発生したらアラートを出すスクリプトを追加することもできます。
そのうち、この金融サービス企業が収支報告書を発表するたびにスパイクが発生することがわかったとします。この場合、収支報告書発表前日に「ベスト・ベット」を作成しておくことで事前に対応しておくべきかもしれません。
新しいターム:新商品の発表/企業による宣伝/街の噂などによって、新しいタームの検索が始まることがあります。検索ログに対するシンプルなスクリプトによって、新しいタームを特定できます。特定したならば、クエリ処理(同義語、タームの拡大/縮小など)の対象としてこの新しいタームを含めます。
ユーザーの疑問が解決されたならば、検索が成功したということになります。「検索の成功/失敗」の判断基準を決めるのは難しいですが、確認しておくべき事項はいくつかあります。
検索ログに、ユーザーと時間のインデックスを付けておけば、このユーザーの次回の検索を確認できます。もしこのユーザーが2、3回検索した後、何もクリックしないで終えていた場合、これはかなりダメな状態です。このような場合、2番めおよび3番めの検索をヒントとして最初の検索を改善してください。
最高の検索アプリケーションでも、検索が「失敗する」ことがあります。SLAをきつめに設定しましょう(最大でも10%以下)。またユーザーからフィードバックが貰える仕組みを追加しておきましょう。ほとんどの場合、ユーザーからフィードバックをもらうのは極めて困難です。とはいえユーザーは最悪な検索結果について文句を言いたがるものです。
パフォーマンスの現実的な目標値を設定する場合、「何に比べて良い/悪いのか」を考えてください。
理想的には、タスクの最初から最後までにかかった時間を計測し、これと同じタスクをこの検索アプリケーションを使わずに行った際の時間と比較できるといいでしょう。これが絶対的な基準値となります。次に現在のアプリケーション/プラットフォームのタスク時間を、検索アプリケーションプロジェクトの評価フェーズにおいて検討した他のアプリケーション/プラットフォームの(想定)タスク時間と比較します。この際、現在のパフォーマンスを、全然違う作業を全然違うハードウェア上で実行しているほぼ別種のアプリケーション(Google など)と比較しないことが重要です。
またユーザーの期待値を把握しておくことも重要ではありますが、物理的に不可能なものをパフォーマンス目標にはできません(「無限の量のデータに対する検索をほぼ0秒で返してほしい」)。これはすべてトレードオフになります。検索開発者の仕事の1つとして、機能/パフォーマンス/リソース消費量間のトレードオフを計測し、他の人と共有するということがあります。
ここでは少なくとも2つの重要な指標があります。「何らかの結果が表示されはじめるまでの時間」と「結果ページが完全に表示し終わる時間」です。まずは何らかの結果を素早く表示することに注力しましょう。それから残りの部分を時間をかけて表示させるように調整します。
エンタープライズサーチアプリケーションは継続的に「世話」しなくてはなりません。機械学習はどんどん改善されてきてはいますが、それでもSLAを確認し、クエリ/データ/世の中の変化に応じてシステムを調整していく人員が必要です。
自分の作業のROIに注意してください。完璧は求めず、SLAに大きな改善をもたらすであろう小さくかつ容易な変更を探してください。
他のエンタープライズアプリケーションと同様の導入ルールに従ってください。小さく始めて、関係者と密にやり取りし、合意済みの目標(SLA)に基づいて、継続的にクオリティやパフォーマンスを査定してください。利用者にもっと喜んでもらえるように、さらにカスタイマイズし、結果の可視化を改善し、よりスマートなリコメンデーションを提供できるよう、常に新しいやり方を追求してください。
「まずは『公開済み』のすべての情報を検索可能にすることに注力し、セキュリティについては後から考えよう」というのは誤りです。第1に、想定よりもすぐにセキュリティ問題が発生します。効果的な検索アプリケーションは、一見存在しなかった情報を明らかにするものなのです。第2に、ある段階に到達した際でも、使用中のプラットフォームが必要なセキュリティを実現できると確信できることが必要です。
セキュリティを「情報へのアクセスを制約するもの」だと考えずに、「『データ共有』の管理」の観点から考えてください。セキュリティが優れているほど、共有できる情報も増えます。あらゆる情報へのあらゆるアクセスを制限するのは、とても簡単です。検索の開発者がやるべき仕事とは、「適切な限り最大限の情報に対して最大限のアクセスを提供する」ということです(それ以上のものではありません)。
以下を確認してください。
セキュリティのもう1つの要素として、運用上のセキュリティがあります。例えば、情報のバックアップとリストアが必要です。つまり災害対応用に同期コピーを保持し、高可用性システム上で実行することで、障害発生時においてもユーザーが常にアクセスできるようにしておきます。また、テスト/パートナー用に情報の墨塗りコピー(リダクション:一部の機密情報を隠したもの)を提供できる必要があります。
お客様と話していると、「うちの社内チームは、情報を探すための社内システムはもう諦めて、単に Google を使っています」と言われることがよくあります。もちろん Google はプライベートデータは扱えないのですが、「なぜ社内のエンタープライズサーチは Google ほど良くないのか」という疑問は出てきます。ここで問題なのは、「エンタープライズサーチは、Google のインターネット検索とは全く違う」ということです。
Google は、2002年にGSA(Google Search Appliance)でエンタープライズサーチ業界に進出してきました。GSAは、究極にコモディティ化されたエンタープライズサーチを目指していました。Google が送ってきたブラックボックス的なハードウェアを社内イントラネットに接続し電源を入れると、組織内のすべてのドキュメントを発見し、webページから検索できるようになります。
実際には、エンタープライズサーチはそんなに単純ではなく、そんなに同質的なものでないことは明らかです。組織ごとにニーズは違っています。またエンタープライズサーチはインターネット検索と多くの点で大きく異なっています。
Google Search Appliance は失敗として広く認識され、2016年に終了しました。当時、CMSWire は、「これは明らかに検索のコモディティ化の終焉を示すものだ。またこれはweb検索とエンタープライズサーチは完全に違うという事実をはっきりさせた」と述べています。
ユーザーの期待値が Google のパフォーマンスを基準としている場合、以下のように反論できます。「Google は確かに速いけれど…」。
もう1つの反論として聞かれるのは、「自分でクエリを処理し、データを処理し、全部トラッキングし、関連度を常に調整しなくてはならないのですか?Googleではそんなことはしませんよ」。
実は Google もこういったことを(ほとんどすべて)やっています。最高の結果を得るために、間違いなくクエリを処理しています。またあらゆるものをトラッキングしています(Google の一番の強みは、自らの関連度チューニング用に莫大な量のクエリがあるということです)。そして関連度や結果の表示について常に調整しています。
彼らがやっていないのはデータの処理だけです。Google の人間が、検索対象となるwebページに手を入れて見つけやすくなるように変更することはありません。しかしそもそも、Google はそんなことをやる必要はないのです。というのも、コンテンツを作っている人の方が、SEO対策として自らのコンテンツが見つけられやすくなるように調整してくれるのですから。
ここで Google の悪口を言うつもりはありません。Google のインターネット検索は最高です。高速で正確だし、結果ページはリッチで、常に既存の機能を強化しつづけ、新機能(カードやカルーセルなど)を追加しています。
検索開発者は、間違いなくGoogleをお手本にすべきです。Google の機能をフォローし、新機能(カルーセルなど)が追加されたらこれを自分たちの検索アプリケーションに追加することを検討すべきです(エンタープライズ用に味付けして)。自分たちのユーザーに対して、より優れた/パーソナライズされた体験を提供することに注力すべきです。Google が大衆用に最適化している一方、あなたの検索アプリケーションはよりディープでパーソナライズされた検索向けにカスタマイズされたものとなります。
これで素晴らしいエンタープライズサーチには何が必要なのか分かったと思います。それでは開発を始めましょう。
MarkLogic のビルトイン検索についてさらに知りたい方はこちらをクリックしてください。
さらに技術的な内容を知りたい方は、メアリー・ホルスティージによる第一原則に基づく検索の設計のビデオをご覧ください。
開発を始めようとしている方には、無料のトレーニングも提供しています。提供しているトレーニングのほとんどでは、MarkLogic データハブにおける検索を扱っていますが、検索アプリケーション開発に特化したトレーニングクラスもあります。
スティーヴン・バクストンは、独立系コンサルティング会社BTCの社長です。以前は、MarkLogicで検索およびセマンティックのプロダクトマネージャを務めており、プロダクトチームには2005年から加わっていました。
『Querying XML』の共著者であり、モーガン・カウフマン氏の『Know It All』シリーズの1つである『Database Design』にも寄稿しています。
MarkLogic入社以前は、オラクルでテキストおよびXMLの製品管理担当ディレクターを務めていました。
より優れた業務アプリケーションやウェブサイトの開発に役立つ、ニュース、情報、チュートリアルをご案内します。