意味的類似性によるドキュメントの検索
バッチ処理機能を備えたセマンティック検索エンドポイント
Last updated
バッチ処理機能を備えたセマンティック検索エンドポイント
Last updated
q
文字列
必須。 検索クエリテキスト(最大400語)。
n
整数
返す結果の数。デフォルト: 3。より包括的な結果を得るために高い値(例: 10)を使用します。
from
文字列
検索対象の文書の時間範囲の開始、ISO 8601形式。
to
文字列
検索対象の文書の時間範囲の終了、ISO 8601形式。
prev_chunks
整数
コンテキストのために含める前のチャンクの数。デフォルト: 2。
next_chunks
整数
コンテキストのために含める後のチャンクの数。デフォルト: 2。
質問への答えを探すときは、理想的な答えのようにクエリを構成してみてください。例えば:
代わりに: "ベクトル埋め込みとは何ですか?" 試してみてください: "ベクトル埋め込みは、テキストを高次元空間の数値ベクトルに変換する技術です。"
高い関連性のある結果を迅速に得るために n=3
から始める
より包括的な情報を得るために n=10
以上に増やす
検索結果が不十分な場合は、n
パラメータを増やしてみる
from
および to
パラメータを使用して、特定の期間の文書に焦点を当てます:
最近の文書:from
を最近の日付に設定
歴史的分析:特定の日付範囲を指定
古い情報を除外:適切な to
日付を設定
大量の検索クエリを効率的に処理するために、Rememberizerはパフォーマンスを最適化し、APIコールのオーバーヘッドを削減するためのバッチ操作をサポートしています。
バッチ操作を実装する際は、以下のベストプラクティスを考慮してください。
最適なバッチサイズ: 5-10 クエリのバッチサイズから始め、アプリケーションのパフォーマンス特性に基づいて調整します。
レート制限: API のスロットリングを防ぐために、バッチ間に遅延を含めます。バッチ間に 1 秒の遅延を設けるのが良い出発点です。
エラーハンドリング: バッチ内の失敗したリクエストを管理するために、堅牢なエラーハンドリングを実装します。
リソース管理: 特に大きなバッチサイズの場合、クライアント側のリソース使用状況を監視し、過剰なメモリ消費を防ぎます。
レスポンス処理: 可能な限り非同期でバッチ結果を処理し、ユーザーエクスペリエンスを向上させます。
高ボリュームのアプリケーションでは、大量の検索リクエストを効率的に管理するためにキューシステムの実装を検討してください。
このエンドポイントは、あなたの知識ベース全体にわたる強力なセマンティック検索機能を提供します。意味に基づいてコンテンツを見つけるためにベクトル埋め込みを使用し、正確なキーワード一致ではなく意味に基づいています。
ベクトル埋め込みがどのように機能し、この検索アプローチがなぜ効果的であるかをより深く理解するには、を参照してください。
Initiate a search operation with a query text of up to 400 words and receive the most semantically similar responses from the stored knowledge. For question-answering, convert your question into an ideal answer and submit it to receive similar real answers.
Up to 400 words sentence for which you wish to find semantically similar chunks of knowledge.
Number of semantically similar chunks of text to return. Use 'n=3' for up to 5, and 'n=10' for more information. If you do not receive enough information, consider trying again with a larger 'n' value.
Start of the time range for documents to be searched, in ISO 8601 format.
End of the time range for documents to be searched, in ISO 8601 format.