Domino IQ の RAG を実際に運用するにあたって、気になる点を順に整理します。
アクセス権と RAG
Domino IQ の RAG サポートでは、対象の文書を事前にベクトル化し、Qdrant に保存します。ベクトル化は Domino サーバ上で行われるため、サーバ側でアクセス可能な文書がベクトル化の対象となります。
では、RAG の対象 DB にアクセス権のないユーザが Domino IQ を利用した場合、どのように動作するのでしょうか？
今回も、これまでと同じ評価環境を利用して検証を進めます。
RAG には dxlSuite のヘルプをベクトル化させてますが、この DB に対する ACL を一時的に ”なし” に変更します。
この状態で RAG を有効にして質問すると ”I don't know.” となりました。DB にアクセス権限がないため、RAG から有効な情報が取得できず、このような回答になったと考えられます。
続いて、ACL を ”投稿者” に変更して同じ質問をします。
結果は、こちらも ”I don't know.” でした。
ただし、詳細ログを比較すると、両者の処理には違いがあることがわかりました。RAG サポートの詳細ログは、処理ごとに次の3種類に分かれています。
| 処理 | ACL なし | ACL 投稿者 | 詳細ログファイル名 |
| 質問のベクトル化 | 詳細ログなし | あり | domiqembthr・・・.log |
| RAG 問い合わせ | 詳細ログなし | あり | domiqvecthr・・・.log |
| LLM 回答を生成 | あり | あり | domiqllmthr・・・.log |
DominoIQ を利用するには、LLM Command 文書を指定します。この文書内には RAG の対象となる DB が指定されています
ACL が ”なし” の場合、ユーザは対象 DB にアクセスできません。そのため質問のベクトル化や RAG の問い合わせを行わず、LLM による回答生成だけが行われた可能性があります。
実際、domiqllmthr の詳細ログを確認すると、LLM に送信されたプロンプトには、RAG のコンテキストが 空 の状態で含まれていました。
|
DATA-OUT: { "model": "Qwen/Qwen3-8B-GGUF", "messages": [ { "role": "system", "content": "あなたは LotusScript と dxlSuiteの専門家です。 初心者にも分かりやすく説明してください。 回答は日本語で行ってください。" }, { "role": "user", "content": "Use the following context to answer the user query: <context> </context> dxlSuite でイメージを使用する機能について教えてください。 If the context does not help answer the question, respond with 'I don't know.' Do not make up an answer." } ], "max_tokens": 512, "temperature": 0.7 } |
参照権限と RAG
次の ACL が ”投稿者” の場合を詳しく見ていきましょう。
”投稿者” では、DB にはアクセスできても、文書が参照できません。このとき、RAG はどのように動作するのでしょうか？ 順を追って確認しましょう。
まず、Qdrant への問い合わせを記録した domiqvecthr 詳細ログを確認します。レスポンスの DATA-IN には検索に合致したことが記録されていました。
|
DATA-IN: { "result": { "points": [ { "id": "5e4e53ba-94a2-4eb6-9b7d-05edef9563f5", "version": 516, "score": 0.80133533, "payload": { "type": 0, "noteId": 10294, "itemName": "Title", "dupItemID": 0, "itemSequence": 1, "itemOrder": 0, "itemOffsets": [ { "offset": 0, "length": 30 } ], "chunkLength": 32 } }, { "id": "b15176cf-466c-4c7c-99bd-32102d1c2568", "version": 537, "score": 0.77039313, "payload": { "type": 0, "noteId": 10310, "itemName": "Title", "dupItemID": 0, "itemSequence": 1, |
このように、Qdrant は検索結果を返しています。つまり、少なくとも今回の検証では、参照権限のない文書に対応するベクトルも検索結果に含まれていました。
ところが、LLM 回答を生成を記録した domiqllmthr ログを確認すると、ACL が ”なし” の場合と同様に、<context> ～ </context> の間は 空 になっていました。文書が参照できないため、コンテキストに内容が含まれなかったと考えられます。
その理由は詳細ログだけではわかりませんでしたが、Domino サーバのコンソールログに手掛かりがありました。
|
[5ABC:0095-4910] 2026/10/24 14:55:44.24 GenerateContext> Warning: No access to note 28DE while generating context. Skipping. [5ABC:0095-4910] 2026/10/24 14:55:44.24 GenerateContext> Warning: No access to note 2856 while generating context. Skipping. [5ABC:0095-4910] 2026/10/24 14:55:44.24 GenerateContext> Warning: No access to note 28A6 while generating context. Skipping. [5ABC:0095-4910] 2026/10/24 14:55:44.24 GenerateContext> Warning: No access to note 2846 while generating context. Skipping. [5ABC:0095-4910] 2026/10/24 14:55:44.24 GenerateContext> Warning: No access to note 2836 while generating context. Skipping. [5ABC:0095-4910] 2026/10/24 14:55:44.24 GenerateContext> Warning: No access to note 284A while generating context. Skipping. [5ABC:0095-4910] 2026/10/24 14:55:44.24 GenerateContext> Warning: No access to note 285A while generating context. Skipping. [5ABC:0095-4910] 2026/10/24 14:55:44.24 GenerateContext> Warning: No access to note 28D2 while generating context. Skipping. [5ABC:0095-4910] 2026/10/24 14:55:44.24 GenerateContext> Warning: No access to note 28B2 while generating context. Skipping. |
この警告は、コンテキストを生成する際に対象文書へのアクセス権がないことを検出し、その文書をスキップしたことを示しています。
Note ID は詳細ログでは 10 進数、コンソールログでは 16 進数で表示されているため、そのマンで比較しづらいのですが、Qdrant の検索結果に含まれていた文書と一致しました。
この検証結果から、Domino IQ は次のように動作していると考えられます。
- Qdrantは、参照権限のない文書に対応するベクトルも検索結果として返す
- Domino IQは、検索結果をもとにコンテキストを生成する段階で、元の Notes 文書へのアクセスを試みる
- アクセスできない文書はスキップされる
- 今回は取得できる文書がなく、LLM に渡された CONTEXT が空になった
つまり、今回の検証では、Qdrant の検索結果をそのまま LLM に渡すのではなく、コンテキストを生成する段階で文書へのアクセス権が確認されていることがわかりました。
文書の削除と RAG
続いて、文書が削除された場合の挙動に関して確認します。
RAG の対象 DB からすべての文書を削除し、同じ質問を DominoIQ に投げてみました。結果は ACL が ”投稿者” の場合と同じく ”I don't know.” でした。しかし、コンソールログには、先ほどと異なる警告が記録されていました。
| [5ABC:0094-3394] 2026/10/24 15:18:13.61 GenerateContext> Warning: Note 28DE was deleted since the search was run. Skipping. |
先ほどの警告は ”No access to note” と記録されていましたが、今回は ”was deleted” となっています。削除されたことを検出し、スキップしたことがわかります。
また、警告メッセージには ”since the search was run” と表現されています。対象の文書をベクトル化してコンテキストの作成までの間に削除されたこと示しています。
この結果から、Qdrant の検索結果に含まれた文書が、コンテキスト生成時にはすでに削除されていた場合でも、Domino IQ がその文書をスキップすることを確認できました。
まとめ
今回は、Domino IQ の RAG サポートについて、データベースや文書のアクセス権、そして文書が削除された場合の挙動を検証しました。
今回の実験では、次のことが確認できました。
- Domino IQ はコンテキストを生成する段階で文書へのアクセス権を確認し、アクセスできない文書をスキップする
- 文書が削除された場合も、コンテキスト生成時に削除を検出してスキップする
- アクセス権のない DB には質問のベクトル化や Qdrant の検索など不要な処理処理はスキップしていそう
少し話はそれますが、Domino のドメイン検索では、索引の更新タイミングによって、削除した文書が検索結果に現れることがあります。
今回の Domino IQ の検証では、少なくともコンテキスト生成時に、文書へのアクセス権や削除の状態が確認されていることがわかりました。この仕組みは、RAG を運用するうえで重要なポイントといえそうです。
