CustomBreakIteratorのパフォーマンスに関する問題

トピック作成者:ks-solruserml-bot (2024/05/22 21:37 投稿)
2
CloseClose

(The bot translated the original post https://lists.apache.org/thread/4kryrpfp9bdl3dbyb77vnmlfdlcg0dcd
into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)

こんにちは、

現在、統合ハイライト機能でカスタムBreakIteratorを動作させる作業をしており、パフォーマンスに苦労しています。

私はパッセージの見出しをきれいにハイライトするためにBreakIteratorが必要です。これにより、ハイライトの開始が文の開始であり、終了が単語の終わりであるようにしたいです。また、いくつかの奇妙なエッジケースもあります。

すでにBreakIteratorをコーディングし、カスタムUnifiedHighlighterクラスに統合しましたが、このIteratorを使用すると、すべてのリクエストのqTimeが約1000から12000以上に上昇し、このアプリケーションでは許容できません。

こちらが私の実装へのリンクです。どこが非常に非効率的なのかを見つけることができません。(これらの関数が非常に頻繁に呼び出されることはわかっています)

他のアプローチも含め、すべての提案を歓迎します。

したがって、BreakIteratorや関連する情報について詳しく学ぶための良いリソースはありますか?ここではコードの調査が非常に難しいです。

次に検討しているもう1つのアプローチは、最終的なハイライトが見つかったときにこのハイライトの「トリミング」を行うことです。これにより、呼び出されるロジックの量が減少しますが、SOLRのスコアリングシステムが正しく考慮されない可能性があると思われます。

私が言ったように、すべての提案を歓迎し、先にお礼を申し上げます。

Jan Ulrich Robens

返信投稿者:ks-solruserml-bot (2024/05/22 21:37 投稿)

もちろん、リンクが壊れてしまいました: https://drive.google.com/file/d/1wfZFQD6loTeA9_-eGrdwi9YGtJcNjKli/view?usp=sharing

返信投稿者:ks-solruserml-bot (2024/05/22 21:38 投稿)

JDK(およびおそらくIBM ICU)のBreakIteratorの実装は遅く、このハイライト機能のパフォーマンスを支配することがあります。大規模な検索プロジェクト(UnifiedHighlighterの作成につながった)で作業をしていましたが、BreakIteratorの位置をテキストに直接エンコードするテクニックを使用しました。それは特別な文字でした。たとえば、「垂直タブ」を使用するかもしれませんか? Solr側では、これがすでにLucene/Solrに含まれている非常に簡単な文字ベースのイテレータになります。あなたも同じことができます。これらの文字を挿入するカスタムSolr UpdateRequestProcessor(URP)を追加できます。

〜 David Smiley
Apache Lucene/Solr検索開発者
http://www.linkedin.com/in/davidwsmiley

トピックへ返信するには、ログインが必要です。

KandaSearch

Copyright © 2006-2024 RONDHUIT Co, Ltd. All Rights Reserved.

投稿の削除

この投稿を削除します。よろしいですか?