日本語の質問を「?」で終えると、セマンティック検索が実行されない場合がありました。FessのPR #3677・#3678・#3683では、こうした入力、引用符、追加の除外条件の扱いを修正しています。
疑問符を含む質問も埋め込みへ渡す
これまではデフォルトフィールドのワイルドカードを含むとベクトル検索を省略していました。空白のない「パスワードを変更するには?」も、その末尾が1文字ワイルドカードと解釈され、キーワード検索だけになる例です。
変更後はデフォルトフィールドのワイルドカード・前方一致・曖昧検索の語を、記号を含むテキストとして埋め込みへ渡します。検索フィールドではない「Q:」なども、条件として誤適用せず文字列として扱います。site:やlabel:など、認識されるフィールドの条件は引き続き絞り込みに使います。
「?」や「*」だけで文字・数字を含まない入力、フレーズ、除外語、ブースト、範囲、正規表現、sort:、allintitle:・allinurl:などには制限が残ります。すべての検索式がセマンティック検索になる変更ではありません。新しく対象となる質問も埋め込みプロバイダーへ送られる点を、外部サービスを使う構成では確認します。
追加の除外条件をベクトル側にも適用する
QueryHelperのadditionalQueryは、標準では未設定です。独自に「-label:internal」などを追加した構成で、キーワード側だけが除外し、ベクトル側から対象文書が戻る問題を修正します。追加条件は埋め込み文字列に混ぜず、ベクトル検索の条件として適用します。既存の閲覧ロールや仮想ホストの権限チェックを新設する変更ではありません。
追加クエリーに通常の語や変換不能な式が含まれる場合は、条件を捨てて検索を続けず、警告を出してセマンティック側を省略します。導入時は既存の追加条件を調べ、internal文書が戻らないこと、通常の文書は見つかることを同じ検索で比較します。
引用符を含む入力とAPIクライアント
PR #3678は、閉じ忘れた二重引用符を含む検索の再試行時に引用符もエスケープします。fields.*の値に含む引用符とバックスラッシュも、文字として保ちます。独自クライアントで値を事前エスケープしていた場合、そのバックスラッシュが残るため、通常のURLエンコードと検索構文のエスケープを混同しないよう見直します。ex_qは検索式を渡す契約のままで、不正な引用符が自動修復されるわけではありません。
この変更だけでベクトル検索が有効になるわけではなく、起動時のcontent_chunker.search.enabled=trueに加え、チャンク生成と利用可能な埋め込みプロバイダーが必要です。rank.fusion.engine.enabledの初期値はfalseで、このPRを理由に変更する必要はありません。修正を含む環境で、自然文・条件付き自然文・キーワードのみになる式を分けて確認します。PRの小規模インデックスによる検証を、大規模な近似検索の精度保証とは扱いません。