カテゴリー: Fess

Fessでキーワード検索ではなく、ベクトル検索をしないなっと思って、いろいろと挑戦していたけど、いい感じの形にならなかったので、どうしたものかと考えていたのですが、そんなとき、OpenSearch 2.4でneural-searchプラグインが標準で搭載されました。これをアレコレと確認したところ、Fessではこれをベースに作ったほうが良いかもと思い、fess-webapp-semantic-searchプラグインを作り始めました。

fess-webapp-semantic-searchプラグインは、neural-searchプラグインをFessでいい感じに利用できるようにする機能を提供して、Fess 14.6から使えるようにしようと思っています。今回、利用できるようにするために、あちこちと修正した気もしますが、ちょっと悩んだのが、検索語の入力方法で、クエリーのパースをどのようにしておくのが、Fessとして自然な利用になるのか？というところです。とりあえず、検索語入力欄に文章みたいなの入っていたら、それをneural queryにして、単語みたいなのはterm queryにするみたいな感じにすることを考えています。なので、クエリーパーサーの部分にも工夫が必要かなと考えています。

semantic-searchプラグインとしては、そんな感じで、クエリー処理周りをいい感じにするなどを対応していき、ベクトルをどう作るか？はneural-searchプラグインがTorchScriptで処理できるモデルをDJLで読み込んで処理する感じです。そのため、オレオレモデルを作っていくためには、TorchScriptで利用できるようなモデルを作る必要があります。そのうち、この辺も考えていこうかなと思っています。

あとは、雑談的な話としては、Fessもニューラルサーチプラグイン的な感じでも良いかなと思ったのですが、neural searchは日本で商標登録されているので、リスク回避のため、無難にsemantic searchプラグインにしました。

という感じで、セマンティックサーチの機能も地道に改善していければなと思っています。

fess.codelibs.orgのサイトですが、Fessの公開以降、大した見た目の変更もせず、Sphinxが適用しているデザインをほぼそのまま使ってきました。見た目の変更は、何年か前に表示幅を広げるくらいな調整をしたくらいです。そのうち、デザインを変更をしたいなぁーと思い、時間が過ぎてしまっていましたが、このたび、見た目の変更に取り組むことにしました。

とはいえ、このサイトはHTML以外にもPDFを生成する必要もあるため、Sphinx以外の仕組みに移行するのはちょっと厳しい状況にあります…。あとは、Fessの管理画面からオンラインヘルプでサイトの情報を参照するようにしているので、URLの構造を変えるのも難しい感じです。なので、Sphinxは引き続き利用して、デザインを変える必要があります。

見た目の方は別途調達して、それをSphinxのテンプレートとして、反映していくことになります。Sphinxは自由にタグレベルで簡単に変えられるのかと思ったら、そうではなさそうな感じでした…。TOCの表示とかを変えたかったのですが、Pythonレベルでハードコードされており、テンプレートレベルではどうすることもできなそうな雰囲気…。（私のSphinx力が足りないだけの可能性もあるが…）という感じで、これだけのために時間を使ってはいられないので、生成されたHTMLを正規表現で書き換える力技で乗り切ることにしました。

という感じで、ざっくりとはデザイン変更ができた感じです。まだ、英語のトップページがなかったり、細かいところで改善したほうが良いところがいろいろとある感じではありますが、時間があるときにちょこちょこ改善していこうかなと思っています。そんなか感じで、気長に見ていただければと…。

Fess 14.5をリリースしました。本当はもっと早くリリースしたかったのですが、Elasticsearch 8.5には、クローズしたインデックスがあると/_node/statsでエラーを返すというバグがあり、これが修正されたら、リリースするかと思っていたのですが、どうやら、8.5系では修正する感じではなさそうなので…。この辺の話は後回しにして、Fess 14.5の修正内容を見ていくと、

#2685は、xalanの依存関係を消すというものです。過去の遺産的なライブラリ感もあるので、今後のメンテなども考え、xalanを取り除き、今風？な状態にしました。

#2686は、クロール負荷などをCPUの状況を見て、調整するパラメータがあるのですが、世の中の利用動向を見ると、激しいクロール設定を作って、Fessが重い…という使い方の問題を定期的に見るので、デフォルトで、このパラメータを50にすることで、クロールなどがCPU負荷の50%を超えると待ち状態になるようにしました。ということで、Fessが重い、と言う人は減ると思いますが、クロールが遅い、という人が出てくるかなとも思いつつ、CPU負荷が高いと言われるよりマシかなと…。そんな感じで、意図的にCPUを全力で利用したい人は0を設定してください。

#2687と#2688は、Playwrightによるクロール対応になります。Playwrightを利用したクロールを参照してください。

#2689は、SAMLによるログインで利用しているoneloginのライブラリが無駄なログを出すので、そのログを抑制するためのものです。

#2690は、フォーラムとかで問い合わせがあったりもしたので、SAMLのライブラリを更新して、それに合わせて、コードを整理しました。

#2691は、クロール設定でパラメーターのキー名が古い形式のものが使えなくなってしまっていたので、古い形式の指定方法でも使えるようにしました。

#2692では、Groovy 4にバージョンを上げました。

#2693は、実装的な話ですが、InterruptedRuntimeExceptionを使うべき場所では利用する、ようにしました。

#2694は、APIでエラー系のレスポンスがボディを返していなかったので、返すようにしました。#2695はそれに合わせて、レスポンス内のエラーメッセージをコード値を返せるようにもしました。

#2696は、log4jのバージョンを上げたら、scriptを設定ファイルで使うためにはいろいろとやらないとダメになったため、シンプルにscriptを使わないように変更しました。それに合わせて、コンソールでの出力をしないようにしました。コンソール出力は開発時に便利なので利用していましたが、通常利用では関係ないので、影響はないと思います。

という感じです。そして、話をElasticsearchに戻しますが、現状、FessはElasticsearchとOpenSearchをサポートしています。Elasticsearchはオープンソースでもないですし、今回のバグもすぐに修正される感じもないですし、今後は、FessはOpenSearchとElasticsearchをサポートする感じにします。どっちも今までどおりサポートされますが、簡単に言うと、サポートの優先順位が変わります。（あとは、OpenSearch 2.4とか見ると、いろいろと面白い取り組みがあり、Fessでもそれらを活用して、何かできそうな感じでもありました）

そんな感じではありますが、何かあれば、フォーラムをご利用ください。