今回は DominoIQ の RAG サポートがどのように動作しているのか、ログベースで確認します。前回 紹介した下図の問い合わせを例に使って、確認を進めます。
なお、評価に使用した環境は、前回 紹介した通り、デバッグパラメータを有効にしております。ご了承ください。
RAG サポートの挙動とログの種類
まず、RAG を有効にした場合の DominoIQ の挙動は次の通りとなります。
- 質問のベクトル化
- RAG 問い合わせ
- LLM 回答を生成
この流れに合わせて、コンソールログに処理状況が記録されます。
さらに、詳細なログが別ファイルにも出力されます。ログの最初に接続情報が記録されています。そのポート番号は、Domino IQ Configuration DB で設定したポートと合致しますので、どの処理に対応するログか判断できます。
| TEXT: Connected to localhost (127.0.0.1) port 8080 |
各処理と詳細ログファイル名は次のような関係になっています。
| port | 処理 | 詳細ログファイル名 |
| 8082 | 質問のベクトル化 | domiqembthr・・・.log |
| 6333 | RAG 問い合わせ | domiqvecthr・・・.log |
| 8080 | LLM 回答を生成 | domiqllmthr・・・.log |
それでは、各フェーズごとのログを確認していきましょう。
1. 質問のベクトル化
ベクトル化は Embedding Model が担当します。質問を送信すると、下記のようなベクトル化を行っているログが出力されています。このログには、ベクトル化したモデル名称やベクトル化した結果が含まれていることがわかります。
|
[4BE4:0094-47E4] 2026/10/15 11:20:38 DominoIQ: PerformRequest() LLM Embedding Request Start time: 2026/10/15 11:20:37 [4BE4:0094-47E4] 2026/10/15 11:20:38 DominoIQ: PerformRequest() LLM Embedding Request End time: 2026/10/15 11:20:37 [4BE4:0094-47E4] 2026/10/15 11:20:38 DominoIQ: PerformRequest() LLM Embedding Request Duration: 0 secs [4BE4:0094-47E4] 2026/10/15 11:20:38 DominoIQ: PerformRequest() returned Headers : HTTP/1.1 200 OK Server: llama.cpp Access-Control-Allow-Origin: Content-Type: application/json; charset=utf-8 Content-Length: 21873 Keep-Alive: timeout=5, max=100 [4BE4:0094-47E4] 2026/10/15 11:20:38 DominoIQ: PerformRequest() returned Data : {"model":"bge-m3-Q6_K", "object":"list","usage":{"prompt_tokens":11,"total_tokens":11},"data":[ {"embedding":[-0.07655056565999985,0.00689056096598506,-0.0036124647594988346,-0.040055856108665466,・・・ |
◇ 詳細ログ
上記コンソールログだけでは、どのような質問文をベクトル化したか、詳細は確認できませんが、詳細ログ domiqembthr を参照すればより詳しく理解できます。
まず DATA-OUT にはベクトル化する質問文が表示されています。
| DATA-OUT:{"input":"dxlSuite を知っていますか？","model":"bge-m3-Q6_K","encoding_format":"float"} |
DATA-IN では、ベクトル化の結果を確認できます。embedding には、質問文を数値の配列に変換したベクトルが格納されています。
|
DATA-IN: { "model": "bge-m3-Q6_K", "object": "list", "usage": { "prompt_tokens": 11, "total_tokens": 11 }, "data": [{ "embedding": [-0.07655056565999985,0.00689056096598506,-0.0036124647594988346, ・・・], "index": 0, "object": "embedding" }] } |
今回使用した Embedding Model「bge-m3-Q6_K」のベクトルは 1024 次元です。そのため、embedding には 1024 個の数値が並んでいると考えられます（実際に数えたわけではありません）。
数値を眺めるだけでは、質問文の意味を読み取ることはできませんね...。
2. RAG 問い合わせ
質問がベクトル化できたので、それを使って事前にベクトル化した DB を検索します。Qdrant に対してベクトル検索するということですね。
コンソールログでは、次の部分が該当します。returned Data に検索結果が出力されていますが、ログが途中で途切れており、内容をすべて確認することはできません。
|
[4BE4:0094-47E4] 2026/10/15 11:20:38 DominoIQ: PerformRequest() LLM Embedding Request Start time: 2026/10/15 11:20:37 [4BE4:0094-47E4] 2026/10/15 11:20:38 DominoIQ: PerformRequest() LLM Embedding Request End time: 2026/10/15 11:20:37 [4BE4:0094-47E4] 2026/10/15 11:20:38 DominoIQ: PerformRequest() LLM Embedding Request Duration: 0 secs [4BE4:0094-47E4] 2026/10/15 11:20:38 DominoIQ: PerformRequest() returned Headers : HTTP/1.1 200 OK content-length: 2554 content-type: application/json vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers date: Thu, 15 Oct 2026 02:20:37 GMT [4BE4:0094-47E4] 2026/10/15 11:20:38 DominoIQ: PerformRequest() returned Data : {"result":{"points":[{"id":"b3ac9561-78f3-4a8d-a380-47babdf791c6","version":3,"score":0.8422835,"payload":{"type":0,"noteId":6586,"itemName":"Title","dupItemID":0,"itemSequence":1,"itemOrder":0,"itemOffsets":[{"offset":0,"length":30}],"chunkLength":32}},{"id":"5941da2d-8667-4dd2-a156-5c8c19485180","version":242,"score":0.8189756,"payload":{"type":0,"noteId":6778,"itemName":"Note","dupItemID":0,"itemSequence":1,"itemOrder":0,"itemOffsets" |
◇ 詳細ログ
このタイミングで出力される詳細ログ（domiqvecthr で始まるログ）には処理結果がすべて含まれています。コンソールログで途切れていた returned Data のJSON は DATA-IN という項目に出力されています。
points 配列に、Qdrant の検索結果が格納されています。今回の検証では、配列に 9 件の検索結果が含まれていました。
各要素を見ると、score があり、類似度を表すと想定できます。さらに詳細を確認すると、文書ID（noteid）やフィールド名（itemName）が発見できます。
|
{ "result": { "points": [ { "id": "b3ac9561-78f3-4a8d-a380-47babdf791c6", "version": 3, "score": 0.8422835, "payload": { "type": 0, "noteId": 6586, "itemName": "Title", "dupItemID": 0, "itemSequence": 1, "itemOrder": 0, "itemOffsets": [ { "offset": 0, "length": 30 } ], "chunkLength": 32 } }, { "id": "5941da2d-8667-4dd2-a156-5c8c19485180", "version": 242, ・・・ |
特に興味深いのは、検索結果に noteId や itemName だけでなく、itemOffsets という位置情報も含まれていることです。
例えば、noteId: 6778、itemName: "Body" のデータでは、itemOffsets に複数の offset と length の組み合わせが記録されています。
つまり、Qdrant の検索結果には、類似度の高いデータを示す情報だけでなく、元の Notes 文書のどのフィールドに関連するデータなのか、さらにそのフィールド内の位置に関する情報も保持されているようです。
| ・・・ { "id": "6109e49c-6792-4965-9002-2838ca46de65", "version": 240, "score": 0.74068475, "payload": { "type": 0, "noteId": 6778, "itemName": "Body", "dupItemID": 0, "itemSequence": 1, "itemOrder": 0, "itemOffsets": [ { "offset": 102, "length": 18 }, { "offset": 134, "length": 196 }, ・・・ { "offset": 1798, "length": 36 }, { "offset": 1848, "length": 117 } ], "chunkLength": 1292 } }, ・・・ |
3. LLM 回答を生成
最後に、Qdrant の検索結果を利用して LLM に回答を生成させます。コンソールログでは以下の部分が該当します。
|
[4BE4:0094-47E4] 2026/10/15 11:20:38 DominoIQ: PerformRequest() LLM Request Start time: 2026/10/15 11:20:37 2026/10/15 11:20:49.39 InvokeLLM> PerformRequest() returned (200): NotesError : , Error = , ErrorOperation = [4BE4:0094-47E4] 2026/10/15 11:20:49 DominoIQ: PerformRequest() LLM Request End time: 2026/10/15 11:20:49 [4BE4:0094-47E4] 2026/10/15 11:20:49 DominoIQ: PerformRequest() LLM Request Duration: 11 secs [4BE4:0094-47E4] 2026/10/15 11:20:49 DominoIQ: PerformRequest() returned Headers : HTTP/1.1 200 OK Server: llama.cpp Access-Control-Allow-Origin: Content-Type: application/json; charset=utf-8 Content-Length: 2737 Keep-Alive: timeout=5, max=100 [4BE4:0094-47E4] 2026/10/15 11:20:49 DominoIQ: PerformRequest() returned Data : {"choices":[{"finish_reason":"stop","index":0,"message":{"role":"assistant","content":"はい、dxlSuiteについて知っています。 \ndxlSuite for LotusScriptは、DXL（Domino XML）を使用して、ノーツのオブジェクト（特に文書）にアクセスするためのLotusScript用のクラスライブラリです。主な特徴は以下の通りです： \n\n1. **使いやすい** \n Domino Designerの機能を活か |
コンソールログの returned Data を見る限り、DominoIQ の最終的な返答が表示されているようですね。
◇ 詳細ログ
domiqllmthr で始まるログを確認すると、LLM に渡された情報や、生成された回答を確認できます。DATA-OUT には LLM に渡す JSON が記録されています。整形して色付けしてみました。
- 青字 LLM System Prompt 文書作成に設定した LLM の役割
- 黄字 RAG 問い合わせ結果
- 紫字 ユーザが入力した質問
|
{ "model": "Qwen/Qwen3-8B-GGUF", "messages": [ { "role": "system", "content": "あなたは LotusScript と dxlSuiteの専門家です。 初心者にも分かりやすく説明してください。 回答は日本語で行ってください。" }, { "role": "user", "content": "Use the following context to answer the user query: <CONTEXT> dxlSuite を使ってみよう dxlSuite for LotusScript とは？ dxlSuite の構成と利用条件 dxlSuite は Script 操作に対応 既存の文書を dxlSuite でアクセスします。 dxlSuite とは？ dxlSuite for LotusScript は DXL（Domino XML） を使用して、ノーツのオブジェクト（主に文書）にアクセスするための、LotusScript 用クラスライブラリです。 dxlSuite には次のような特徴があります。 使いやすい！ 簡単 標準クラスを超える機能 1. 使いやすい Domino Designer の特徴を生かし、開発者が開発しやすいよう工夫しています。 ライブラリはクラスで提供されますので、タイプアヘッド機能を利用でき、同時にポップアップヘルプに必要な情報が表示されます。 また、開発支援機能を搭載していますので、効率的に開発できます。 2. 簡単 ノーツの構造に沿ったクラス構造となってます。また、ノーツにはさまざまなオブジェクトがありますが、それに応じたクラスを用意しています。 リッチテキスト内には大量のオブジェクトが順不同に存在しますが、それぞれに効率よくアクセスできるよう検索機能を用意しています。 3. 標準クラスを超える機能 リッチテキスト関連の標準クラスは、ノーツクライアントと同等の操作ができません。 既存の文書を dxlSuite で更新します。 dxlSuite と NotesDocument の連携 dxlSuite の構成や使い方、利用条件や動作環境などをまとめます。 </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 } |
<CONTEXT> と </CONTEXT> で囲まれた部分に、検索結果に関連するテキストがまとめられています。このテキストは全部で 9 件分あり、RAG の検索結果である points 配列の要素数と合致します。
その後にユーザの質問が続きます。
このように、検索で得られた情報と質問をまとめて LLM に渡すことで、Notes 文書の内容を踏まえた回答を生成する仕組みになっていることがわかります。
まとめ
今回は DominoIQ の RAG サポートの挙動をログから詳細に確認しました。この流れを理解しておけば、思い通りの結果が得られない場合も、各処理のログを順に確認することで、問題の切り分けに役立ちそうですね。
ところで、今回のログを調べていて、もう一つ気になる点がありました。検索結果には itemName が含まれており、フィールドごとに関連付けられたデータが検索されているように見えます。
では、製品名、できること、できないことが別々のフィールドに格納されている場合、DominoIQ はそれらの情報をどのように検索し、回答に利用するのでしょうか？各フィールドの関連性は考慮してくれるのでしょうか？
このあたりは、実際のデータを使って別途検証してみたいと思います。
0 件のコメント:
コメントを投稿