ナレッジベースとドキュメント質問
ナレッジベースは、Aivoryの長期的なドキュメントストアです: 一連のドキュメントを一度にアップロードし、その後どのセッションでも検索質問としてアップロードし、自動的にソース参照を提供します。このページには、ナレッジベースの作成、ドキュメントのライブラリ、セッションの使用方法、検索原理、および「検索結果は空の」の完全なチェックリストが含まれています。
ナレッジベースと並行して、同じ解析と検索エンジンを共有する2つのドキュメント役割フィールドがあります。
| 役割領域 | 保管場所 | 検索範囲 | 典型的な用途 |
|---|---|---|---|
| 会話 臨時文書 | その会話をアップします。 | ただの会話 | 質問は「このPDFを読んでください」です。 |
| ナレッジベース | 独立したナレッジベースページ | どんな会話でも載せてます。 | 長期再利用の情報集 |
| プロジェクト ナレッジベース | プロジェクト | このプロジェクトのすべての会話 | チーム/トピック情報、見るチームワークスペースプロジェクト機能 |
前提条件
ナレッジベース バックエンド能力の3つのカテゴリーに依存し、どれが何に劣化するかは、まず明らかにします。
| 依存 | 役割 | 配置されていない時の行動 |
|---|---|---|
入力モデル(kind='embedding'環境変数(環境変数) | 文書量化と問い合わせ量化 | 埋め込みが完了できず、大きなドキュメントは取り戻せません;小さなドキュメントはまだ完全に注入できます |
Qdrant(QDRANT_URL) | 厚いベータの検索 | Vector Recovery を無効にし、RAG が全文に戻る |
| MinerU + オブジェクト ストレージ(S3 / アリ クラウド OSS) | スキャンパス PDF、Office ドキュメント、画像のクラウド解像度と OCR | 非純テキスト文書解析が失敗し、ナレッジベースの文書が失敗としてマークされます |
- Docker Compose を生産するには、Qdrant コンテナが組み込まれています。Docker Compose デプロイ。
- 埋め込みモデル 管理コンソール「チャンネル/モデル」で設定:OpenAIタイプチャンネルに貼り付けて、モデル名と次元、OpenAIのあらゆる露出を要求する。
/v1/embeddingsフォーマットのサービス(OpenAI、Voyage、デプロイ自体のBGE-M3など)がご利用いただけます。チャンネルとモデル与コア配置。 - MinerU の API アドレス、トークン、オブジェクト ストレージ クレジットは、管理コンソールの「ドキュメント」ページで保存され、再起動する必要はありません。
同じナレッジベースのすべてのベクトル(質問時に問うベクトルを含む)は、同じ埋め込みモデルから来なければならず、異なるモデルのベクトルスペースは互いに互いに互換性がない。したがって、埋め込みモデルは、建造時に選択され、建造後に置き換えられず、交換は全量の再埋め込みに等しい。
ナレッジベースを作成
入力:サイドバーの下部のヘッダーメニューの「ナレッジベース」から、ナレッジベースリストページへ、「新しいナレッジベース」をクリックします。
会話のフィールドを作成する:
| フィールド | 必填 | 説明 |
|---|---|---|
| 名称 | 是 | 同じアカウント(同じスペース)で名前を変えることはできません。 |
| 描写 | 否 | あなたとリクエストルートを理解するために、このライブラリが何であるかを助ける |
| 埋め込みモデル | 是 | 管理者が有効にした埋め込みモデルから選択し、下のラリで各モデルの名前と次元(たとえば、dim 1536) |
サイズは自動決定: ベクトルサイズは選択された埋め込みモデルの構成によって決まっており、手動で埋め込む必要もありません。 リストカードを作成した後、「N 次元ベクトル」が表示されます。 同じ次元のナレッジベースは Qdrant でコレクションを共有し、 payload でレンタカーを隔離します。
最初のドキュメントをアップロードした後 埋め込みモデル がロックされ、ライブラリ全体のベクトル空間を決定します。 間違った選択は、ライブラリを削除するだけで再構築できます。 複数のナレッジベース 同じセッションで同時に埋め込みする場合は、同じ 埋め込みモデル を使用してください (理由については、下記のリストを参照してください。
一般ユーザーが作成できるナレッジベースの数は、ユーザー グループに制限されます(管理者がユーザー グループの編集ページで「最大ナレッジベース数」を設定し、0 を無制限にします)。ユーザーとクォーター。
ファイルアップ
ナレッジベース 詳細ページにアクセスし、「ドキュメントをアップロード」をクリックします。アップロード 会話ボックスには、タグページが 2 つあります。
- 文書アップ●地元の文書を選択する
- テキスト貼り: 文書の一部を文書ライブラリとして直接挿入し、分散メモに適しています。
サポートされるファイルタイプと解析パス
| タイプ | 解析方法 | スピード |
|---|---|---|
| 純粋なテキスト(txt / md / csv / log / json / yaml / xml / html) | 現地で直接読み込み、マークダウンのように切り込む | ミリ秒レベル |
| PDF(文字列付き) | 現地でテキストレイヤーを即時抽出し、グラフもOCRも送らない | 秒レベル |
| PDF(スキャンパーツ / テキストレイヤーなし) | MinerU クラウド OCR | 時間はページ数による。 |
| DOC / DOCX / PPT / PPTX / XLS / XLSX / 写真 | MinerU クラウド解析(テーブルと公式の識別を含む) | ミニレベル |
スキャン要素の判断規則: 文書には画像が含まれており、テキスト密度がページあたり200文字未満の場合、MinerU OCR を使用してスキャン要素とみなされ、それ以外はローカルに抽出され、花の OCR 時間は本当に必要な場所にのみ費やされます。
実際にアップロードできる拡張名は、管理者のアップロードホワイトリストとサイズ上限制御(管理コンソール「ドキュメント」ページ)により、上限ファイルはアップロード時に拒否され、具体的な上限を提示されます。
非純テキスト文書を解析すると、元のファイルが最初に設定された S3 / OSS バーチャルに落ち、MinerU は 1 時間有効な事前署名 URL を取得し、あなたのストレージ証明書はドメインから外されません。
状態の流れ
文書を非同期流水線にアップロードした後、詳細ページの文書表は、リアルタイムの状態のバッグを表示します。
| 状態 | 示す | 意味 |
|---|---|---|
| pending | 列に | 入隊して待機。 |
| parsing | 分析中 | テキストを抽出し、この段階でスキャンする OCR |
| embedding | 組み込み中 | 構造化されたカットの後、バッテリー呼び出し 埋め込みモデル(バッテリーごとに最大 128 個) |
| ready | 準備 | 既に取得可能で、表は切片の数を同時に表示します |
| failed | 失敗 | 流水線の自動再試行は3回失敗し、失敗の原因を記録 |
ドキュメント テーブル 列: ファイル、状態、カット数、追加時間。
失敗と再試行
- 各ドキュメントの内部の流水線自動再試行 3 回再試行時に解析したコンテンツはキャッシュされ、失敗した埋め込み段階のみを再起動し、請求の MinerU OCRを再度呼び出すことはありません。
- 3 回失敗すると「失敗」に設定され、原因を記録します(例: MinerU が構成されていない、オブジェクトのストレージが利用できない、埋め込みモデル エラーの報告など)。インターフェイスは「インデックスが失敗した後、ドキュメントを削除して再アップロードしてください」というメッセージを表示します。
- 失敗したファイルの解析ノーベクトル化され、占拠コンテンツで検出結果を汚染しない。
- 同じ名前のドキュメントを繰り返しアップロードするか、失敗した後に再入力する場合は、クライアントに古い切片を重ねることはありません。
会話で使用する
ナレッジベース
チャット入力ボックスのツールバーには、本のアイコンの「ナレッジベース」セレクターがあります。
- 開いた後、1つまたは複数のナレッジベースを選択し、貼り付け状態を縛る現在の会話会話に影響を及ぼさず、変えていく。
- アイコンの横には既存の数が表示されます。
- 狭い画面(携帯電話)では、入力ボックスの「+」メニューで入力する。
- まだ ナレッジ ベース がない場合に「まだ ナレッジ ベース はありません」を表示します。
アップロード後、それぞれの質問は、下の検索プロセスに従って自動的にライブラリを検索し、特別な指示は必要ありません。 答えの下に「ソース」の角が表示され、ドキュメント名、ページコード、章のパスとオリジナルテキストのパーツを見ることができます。
チームワークスペース内では、そのスペースのナレッジベースのみを貼り付けますが、個人スペースのナレッジベースとワークスペースは隔離されています。チームワークスペース。
単一文書質問(会話 暫定文書)
図書館を構築しないで、ファイルを直接チャット入力ボックスに押し込むこともできます。
- アップロード後、付属チップに「インデックス中...」が表示され、解析が完了した後には送信されますが、文字列のあるPDFは通常数秒で完了します。
- 小さなドキュメント(管理者によって設定された全体の注入値の限度値を超えず、デフォルトでは約8000トークン)全文注入この質問ラウンドでは、ベクトル化は行われず、Qdrant および埋め込みモデルを構成しない場合でも使用できます。
- 大型ドキュメントは、「クエリのルーティング + 検索」プロセスを完全に実行します(以下のセクションを参照)。
- 解析が失敗した場合、チップに「このファイルを読み取れない」と表示され、「再試行」ボタンが表示されます。
- インデックス済みの PDF は、モデル側の反復解析が遅くなるのを避けるため、モデルに完全なコピーを送信しなくなります。
セッション 臨時ファイルは、セッション内でのみ検索できます。 セッション プロジェクトに存在する場合、臨時ファイルを「プロジェクトに加わる ナレッジベース」キーでプロジェクト共有ドキュメントにアップロードできます。
ニュースの検索状況
各ラウンドの答えの一番上に、このラウンドのドキュメント処理方法を小さなカードでマークし、いくつかの一般的な方法があります。
| 提示する | 意味 |
|---|---|
| 源泉検索 | ベクトル + キーワードを混合して検索し、命中断片を注入 |
| 完全なドキュメントを入力しました。 | ファイルが小さいので、全文入ります。 |
| 全文は以下の通り。 | 質問ルートは、グローバルクラスの質問(概要/概要)と判断し、全文で処理します。 |
| 飛び跳ね検索 | リクエストルートは、この文は文書と無関係で、リクエスト費用はゼロです。 |
| 文書分析中 | ドキュメントはまだ準備ができていませんが、このラウンドは使われていません |
ツール検索(オプション)
デフォルトの自動注入に加えて、プラットフォームはもう1つsearch_knowledge_baseツール: ネイティブの function calling をサポートするモデルは、1 つの応答で複数回、複数回にわたって独自にリクエストを開始できます。 ドキュメントの質問へのメインパスはそれに依存しません。
検索原理
流水線の理解は、「なぜ回収されていないのか」を判断するのに役立ちます。
入庫:解析、切断、埋め込み
上传 → 解析(本地 / MinerU) → 结构感知切块 → 批量嵌入 → 向量写 Qdrant,文本与元数据写数据库
断片は固定文字で硬くない:
- トークンはタイトル、段落、句の境界線で切断され、ターゲットブロックごとに400〜800トークン、決してセクション、テーブル、コードブロックの真ん中から切断されず、隣接ブロックは約10%〜15%の重複を保持します。
- 「第3章 > 3.2 収益分析」などのタイトルパンフレットにそれぞれのスタートを組み込むことで、個別なデジタルフラットがコンテンツに含まれます。
- 父子構造(small-to-big):小ブロックのベクトルインデックスで位置の正確性を確保し、その場所にある父級の大段をモデルに返す。
質問:ルートの検索
ドキュメントをアップロードする セッションでは、それぞれの質問には、安価なタスク モデル 呼び出し(約 300 ～ 800 ミリ秒増加)が 1 つずつ行われます。
- 意図分類:
retrieve(具体的に調べてみると、full_doc(概要をまとめ、全文で取り扱う)none(文書と無関係で、ジャンプ) - 問い合わせ書き換え言語の問題を複数の正確な検索単語に分割し、最近の歴史の回数を組み合わせて「それ / このドキュメント」などの指標を消去します。
ルート解析の失敗または過剰な時間は、retrieveむしろ、文書を漏らさないほうがいい。
検索: 密度 + キーワード混合
查询向量化 → Qdrant 向量检索 top-30
∥ 数据库关键词全文检索 top-30(中文分词)
→ RRF 融合排序 → 取 top-K → 回表取完整父级片段 → 注入上下文
- 両方融合は、独自の単語、番号類の問い合わせ(「ケース98」、「条項4.2」)の命中率を大幅に高め、これは純粋なベータ検索の弱点です。
- Top-K デフォルト 8 管理者変更可能ダイナミック TOP-Kその後、固定数を取るのではなく、余弦の類似度が限界値に達した断片をすべて注入する。
- 関連検索パラメータ(全文入力値)
rag_full_text_threshold、rag_top_k、rag_dynamic_topk、rag_similarity_threshold) 管理コンソールの「ドキュメント」ページで変更、保存が有効になります。
引用元
モデルを注入するパーツの統一番号とソースのメタデータ:
[1] 《2025年度报告.pdf》第12页 · 第3章 > 3.2 营收分析
营收同比增长23%,主要来自……
モデル ナンバー引用で、前端がソースコーナーとしてレンダリングされ、ネット検索の引用と同一のUIを共有します。 コンテンツを注入するパッケージは明確な境界標識で、システムのヒントで、ユーザー指示ではなく参考資料として宣言し、ドキュメントのコンテンツにヒントを注入するリスクを減らします。
ナレッジベースの管理
| 操作 | 位置 | 行動 |
|---|---|---|
| 再命名 | 詳細ページメニュー「改名」 | 名前だけを変更し、ドキュメントやベータに影響を与えない |
| 個々のファイルの削除 | 詳細ページ 文書行の削除ボタン | 確認後、ドキュメントとそのすべての切片とベータを削除します。 |
| 削除 ナレッジベース | リスト列の端に「⋯」メニュー、または詳細ページのヘッダーに「⋯」メニュー | 会いましょう |
削除 ナレッジベース はレベルの共通のクリーニング: 確認スイッチは「本ライブラリとそのすべての文書とベクトルを永久に削除し、引用する セッション は自動的に引用を削除し、この操作は復元できない」と明示します。
- クーンのすべての文書の記録とカット;
- Qdrant で適切なベータ;
- ディスク上のオリジナルドキュメント
- このライブラリの会話は自動的に引用を解除し、会話自体は影響を受けません。
管理者は、コンソールのユーザーリストのより多くのメニューでユーザーのライブラリページにアクセスし、そのナレッジベースと各ドキュメントの状態、切片数、サイズ、詳細を見るだけで読むことができます。ユーザーとクォーター。
空気検査リストを検索
ナレッジベースを載せたが、答えの源はなく、またはモデルが「関連するコンテンツが見つかりません」と答えるときは、次の順序でチェックします。
- ファイルの状態は「準備完了」ですか?: ナレッジベース 詳細ページ ステータスバッグを表示し、ランク付け中 / 解析中 / 埋め込み / 失敗したドキュメントは回収に参加しません。 失敗したドキュメントは失敗の原因を開きます。
- Qdrant が設定されているか:
QDRANT_URLエアタイムベクトルの回収は完全に無効となっており、全文の回収のみが残り、小さなドキュメントが利用可能で、大きなドキュメントが回収されません。 生産コンポーネントは、Qdrant でデフォルトされています。 環境変数と容器の状態をチェックするカスタマイズデプロイは、コンポーネントを参照してください。コア配置。 - 組み込みモデル 可用性: ナレッジベースの埋め込みモデルが無効、チャンネルキーが無効、またはサービスが利用できない場合、新しいドキュメントカードが埋め込み段階または失敗に指定され、クエリベクトリ化も失敗します。
- サイズが一致するかコレクション : Qdrant collection 次元別名称(
aivory_c<维度>) 出力次元を異なる 埋め込みモデルに置き換えると、同期次元設定がなければ、ベクトルは誤った collection に書き込み、正常に書き込まれるが、永遠に取り戻せないようにします。ベクトルメンテナンスリベクトル再構築:データベースから保存されたテキストを再埋め込み、元のファイルは必要ありませんが、埋め込まれた API 呼び出しを消費します。バックアップと移行。 - 複数の組み込みモデルが一致するか同一セッションが複数のナレッジベースを持ち込む場合、システムはその組み込まれたモデルの一致性を検証し、不一致が間違いを明確に報告する代わりに、間違った結果を静かに返す。
- スキャン版の PDF が MinerU を搭載しているか: MinerU + オブジェクトのストレージがない場合、スキャンパーはコンテンツを解析できず、ドキュメントは失敗としてマークされます。
上記2、4、6条は、よくある質問「なぜナレッジベースの検索結果が空いているのか」、「EMBEDDING_DIM が埋め込まれたモデルと一致しないか」、「PDF がスキャンされた後で解消されない」の関連項目には、より完全な設定例が含まれています。
最速の検証方法は、数KBの純テキストの小さなファイルをセッション中に直接質問するように送信することです。小さなファイルは、Qdrantや埋め込みモデルに頼らず、全文を注入し、問題はモデル側ではなくリクエストリンクにあり、小さなファイルが正常で、大きなファイルが正常でない場合は、上記のリストをクリックしてベクトルリンクを参照してください。