edgengram (min=3, max=7, front) + term_vector=with_positions_offsets でアナライザーを使用する場合
text = "CouchDB" を持つドキュメントの場合
「クック」で検索すると
私のハイライトは「couc」ではなく「cou」にあります
私のハイライトは、一致する最小のトークン「cou」のみにあるようですが、正確なトークン（可能であれば）または少なくとも見つかった最長のトークンにあると予想されます。
term_vector=with_positions_offsets でテキストを分析しなくても問題なく動作します
パフォーマンスの term_vector=with_positions_offsets を削除すると、どのような影響がありますか?
特定のフィールドに設定term_vector=with_positions_offsetsすると、そのフィールドのドキュメントごとに用語ベクトルが保存されることを意味します。
強調表示に関しては、用語ベクトルを使用すると、標準の蛍光ペンよりも高速な lucene 高速ベクター蛍光ペンを使用できます。その理由は、インデックスに十分な情報 (位置とオフセット) が含まれていないため、標準の蛍光ペンでは高速に強調表示する方法がないためです。フィールドの内容を再分析し、オフセットと位置を傍受し、その情報に基づいて強調表示することしかできません。特に長いテキスト フィールドでは、これにはかなりの時間がかかる場合があります。
用語ベクトルを使用すると、十分な情報が得られ、テキストを再分析する必要はありません。マイナス面は、インデックスのサイズであり、著しく増加します。ただし、Lucene 4.2 の用語ベクトルはより適切に圧縮され、最適化された方法で保存されるため、それを追加する必要があります。また、投稿リストにオフセットを格納する機能に基づく新しい PostingsHighlighter もあり、必要なスペースはさらに少なくなります。
elasticsearch は、利用可能な情報に基づいて強調表示するための最適な方法を自動的に使用します。用語ベクトルが保存されている場合は、高速なベクトル ハイライターが使用されます。それ以外の場合は、標準のハイライターが使用されます。単語ベクトルを使用せずにインデックスを再作成すると、標準の蛍光ペンを使用して強調表示が行われます。遅くなりますが、インデックスは小さくなります。
ngram フィールドに関しては、説明されている動作は奇妙です。これは、高速なベクター ハイライターが ngram フィールドをより適切にサポートする必要があるためです。したがって、まったく逆の結果が予想されます。