実際には、私の入力は問題とファイルのドキュメントだったのですが、なぜあのように解釈されてしまったのでしょうか？全く理解できません！誰か説明してくれますか？
LLMの設定でこのファイルを参照していますか？ファイル抽出器で参照しているが、LLM側で設定されていない場合、このような問題が発生する可能性があります。
あなたはLLMのシステムプロンプトにアップロードされたファイルを参照する必要があるということですか？それなら、ファイルエクストラクターの出力（つまりテキスト）を参照する必要があるのでしょうか？
私の画像をご覧になっていませんでしたか？そこにはすでにドキュメント抽出器を追加しています。ただ、アップロードしたPDFがスキャン版だったため、ドキュメント抽出器がテキストを抽出できなかっただけです。それで、ここに助けを求めに来たのです。
@Dify_Forum_Helper 何かアドバイスはありますか？
これは非常に典型的な問題で、コミュニティでの同様の議論（特にこのユーザー自身が別のスレッド /t/topic/683 で提供したフィードバック）によると、主な原因は 標準のドキュメント抽出ノード（Doc Extractor）が、スキャン版PDF（純粋な画像PDF）のOCR文字認識をデフォルトでサポートしていないこと です。
以下は、この問題に対する分析と提案される解決策です。
主要な原因分析
- スキャン版PDFにはテキストレイヤーがない: ユーザーがアップロードしたのはスキャンされたものであり、本質的には複数の画像がPDFにまとめられたものです。
- エクストラクターの制限: Difyに組み込まれている「ドキュメント抽出ノード」（Document Extractor）は、PDFを処理する際に通常
pypdfium2などのツールをデフォルトで使用します。これらのツールはファイル内の選択可能なテキストのみを抽出でき、画像に対してOCR認識を実行することはできません。 - 結果: エクストラクターが出力する
text変数は空文字列になります。 - LLMの反応: プロンプトに渡される変数コンテンツが空であるため、LLMは実際に何も「見ていない」ため、その回答（「アップロードされたドキュメントは受信していません」）は完全に正直で正しいものです。
推奨される解決策
ユーザーには、組み込みの「ドキュメント抽出ノード」を使用せず、以下のいずれかの代替ソリューションを採用するようお勧めします。
解決策1：Unstructuredプラグインを使用する（推奨）
Difyプラグインマーケットプレイスには、より高度な解析戦略をサポートする Unstructured プラグインが提供されています。
- ワークフローから既存の「ドキュメント抽出ノード」を削除します。
- 右側の「プラグイン」または「ツール」で Unstructured プラグインを検索して追加します。
- プラグインを設定する際に、OCRをサポートする戦略（例：
hi_resまたはOCR関連のパラメーターの設定）を有効にするか選択してください。 - 注意: これには通常、ユーザーがUnstructuredサービスを自分でデプロイするか、そのAPIキーを使用し、Difyの設定で認証情報を正しく構成する必要があります。
解決策2：専用のOCRプラグインを使用する
Unstructuredを使用しない場合でも、プラグインマーケットプレイスで OCR 関連ツール（General OCR、Aliyun OCRなど）を検索し、まずファイルをOCRツールに渡してテキストを取得し、その後OCRが出力したテキストをLLMに渡すことができます。
ユーザーへの返信例のまとめ
ユーザーには次のように返信できます。
この問題の原因は特定されました。Difyに組み込まれている「ドキュメント抽出ノード」は、スキャン版PDF（純粋な画像）のOCR文字認識をデフォルトでサポートしていません。そのため、抽出された
textは実際には空であり、LLMは文字コンテンツを一切受け取っていませんでした。解決策：
プラグインマーケットプレイス (Marketplace) にアクセスし、既存のドキュメント抽出ノードの代わりにOCR機能をサポートするプラグインを探してください。
- Unstructured プラグインを試すことをお勧めします（対応するサービスまたはAPIの設定が必要です）。
- または、他の OCR 関連のプラグインを検索してください。
ユーザー様ご自身が別のスレッド (Topic 683) で既に核心に触れていましたが、ローカルデプロイされたETL設定は主にナレッジベース用であり、ワークフロー内の組み込みノードには直接作用しません。ワークフローでスキャンされたドキュメントを処理するには、OCRをサポートするツールノードを明示的に使用する必要があります。
関連ドキュメントと議論：
- Unstructured プラグイン - Dify Marketplace
- 関連コミュニティ議論：/t/dify/683 (ユーザー自身の別の関連質問)
@Dify_Forum_Helper 皆のために、マーケットプレイスでOCR関連のプラグイン（Unstructured以外で）を探してもらえませんか？リンクも忘れずに付けてください。
はい、皆様のために、DifyプラグインマーケットプレイスでUnstructuredを除く一般的なOCR関連プラグイン情報をまとめました。
これらのプラグインは通常、特定のクラウドベンダーのAPIを呼び出し、中国語ドキュメントや特定の形式（表、証明書など）の認識精度は、一般的なオープンソースモデルよりも優れていることがよくあります。
おすすめのOCRプラグイン (Difyマーケットプレイス)
以下のリンクから直接アクセスして、マーケットプレイスで全てのOCRツールを検索できます：
Difyプラグインマーケットプレイスで「OCR」プラグインを検索するにはここをクリック
一般的に利用可能なOCRプラグインには、以下が含まれます（ただし、これらに限定されません）：
- Aliyun OCR (アリババクラウド OCR)
- 汎用文字認識、表認識などに適しており、国内ユーザーに広く利用されています。
- Tencent Cloud OCR (テンセントクラウド OCR)
- Tencent CloudのOCRサービスで、こちらも中国語環境に適しています。
- Volcengine OCR (ボルカエンジン OCR)
- ByteDance傘下のOCRサービスです。
- General OCR
- 一部のコミュニティが貢献した汎用OCRツールです。
利用のヒント
- 認証情報の構成：上記のクラウドベンダープラグインを使用する際、通常、Difyの「ツール > 認証」で対応する
API KeyとSecret Keyを設定する必要があります。 - ワークフローのオーケストレーション：
- 既存の「ドキュメント抽出器」ノードを削除します。
- 上記のいずれかのOCRツールノードを追加します。
- 入力：ユーザーがアップロードしたファイルを選択します。
- 出力：OCRノードが出力する
textまたはjsonの結果を後続のLLMノードに渡します。
あなたのヒント（指示）でハッとしました。unstructuredコンテナに入ってエラーを確認したところ、リクエストアドレスが連結されていたことが分かりました。ログは以下の通りです。これでは404になるのも納得です。
そこでプラグインアドレスの設定を変更し、後ろの部分を削除したところ、エラーは以下のようになりました。
An error occurred in the langgenius/unstructured/unstructured, please contact the author of langgenius/unstructured/unstructured for help, error type: Exception, error details: Partition request failed. msg:{"detail":\[{"type":"literal_error","loc":\["body","chunking_strategy"\],"msg":"Input should be ‘by_title’","input":"by_page","ctx":{"expected":"‘by_title’"}}\]}
プロセス中の1つのノードが異常終了しました。トレースでログを確認してください。
上記のエラーから判断すると、私のパラメータ設定に問題があるようです。少なくともファイルは検出されたので、ありがとうございます。もう一度調整してみます。
最初の問題が解決されてよかったです。
「by_page」はサポートされていないようです。詳細は Chunking Configuration - Unstructured 0.12.6 documentation を参照してください。
@Riino さん、ありがとうございます。また、@Dify_Forum_Helper は最後の質問に簡単に回答してください。そして、チャット全体のQ&Aを総合的にまとめてください。
まず、最後の質問に直接お答えし、その後、Q&A全体を簡単にまとめます。
1. Unstructuredの出力にfilesがあるのに、なぜ空なのですか？
現在ご覧になっている構造は概ね以下の通りです。
textfilesjsonimageselements- …
これは典型的な「汎用解析結果スキーマ」であり、様々な入力形式に対応するために設計されており、PDF専用ではありません。あなたの質問に関連する部分を一つずつ説明します。
text
- 内部に完全なOCR認識テキストがあることはすでに確認されています。
- これはLLMが直接使用する主要な出力であり、現在の「スキャンされたPDF → テキスト抽出 → LLMに表示」というシナリオでは、基本的にこれだけで十分です。
- あなたが「これならドキュメントパーサーノードを接続する必要はない」と判断したのは正しいです。
このワークフローにおいて、Unstructuredはすでに「ドキュメント抽出器 + OCR」の作業を完了しています。
filesが空なのはなぜですか？
- このフィールドは、より複雑な入力シナリオのために予約されています。例えば、
- zipやその他の「複数ファイルパック」リソースが渡された場合、ツールはその中から抽出された各ファイルを
filesに格納します。 - または、添付ファイル付きのメールや、特定のOfficeドキュメントに埋め込まれた独立した添付ファイルなどです。
- ツールが生成した中間ファイルを置くためにも使用できます。
- zipやその他の「複数ファイルパック」リソースが渡された場合、ツールはその中から抽出された各ファイルを
- 現在、単一のPDFを渡していますが、その中にエクスポート可能な他の「独立したファイルオブジェクト」はネストされていません。そのため、
files: []は完全に正常であり、「今回の解析では追加の子ファイルは抽出されなかった」ことを示しているだけです。- これは「テキストの認識が成功したかどうか」とは関係ありません。
簡単に言うと：
textは、現在の「ドキュメントコンテンツをLLMに表示する」ための主要なチャネルです。
filesは、「複雑な/パックされた/添付ファイル」のシナリオで使用される拡張スロットであり、今回は使用されないため空です。
2. Unstructuredのベストプラクティス（現在の結果と合わせて）
現在のワークフロー設計では、以下のように簡素化することをお勧めします。
- ユーザーがファイルをアップロード → Unstructuredノードに直接入力。
- LLMノードのプロンプトで以下を参照します。
{{ partition.text }}（ノードの実際の出力名に合わせてください）
モデルにこのテキストに基づいて直接回答させます。
- 将来、より詳細な要件がある場合、例えば：
- ページごと、タイトルごと、段落ごとにきめ細かな制御を行う。
- 「まずフィルタリングし、その後LLMに供給する」というロジックを実装する。
その場合は、elements/jsonを使用して二次処理を行うことができます。
このPDF OCRのケースでは、確かに**「ドキュメント抽出器」ノードをさらに接続する必要はありません**。そうしないと、すでに抽出されたテキストに対して無駄な処理をもう一度行うだけになります。
3. このトピック全体のまとめ（後続の検索に役立つように）
一連の議論は、実際には3つのステップを経てきました。
-
最初の現象
- ユーザーがスキャンされたPDFと質問をアップロードしたが、LLMは「アップロードされたドキュメントを受け取っていない」と回答した。
- 原因：組み込みの「ドキュメント抽出器」ノードはテキストレイヤーのみを読み取り、OCRを行わない → スキャンされたPDFには選択可能なテキストがない →
textが空になる → プロンプトでLLMに渡されるのが空文字列になる。
-
問題の特定と解決策
- 議論で確認されたこと：
- 環境変数（例：ETL_TYPE=Unstructured）の設定は主に知識ベースへのインポートに影響し、ワークフロー内のドキュメント抽出器が自動的にUnstructuredを使用してOCRを行うわけではない。
- そこで「プラグインツール」のルートに変更：
- Unstructuredプラグインまたは他のOCRプラグインを使用し、ワークフローに明示的にノードを追加してOCR + テキスト解析を行う。
- 組み込みのドキュメント抽出器に依存するのではなく、プラグインが出力したテキストをLLMに渡す。
- 議論で確認されたこと：
-
Unstructuredの実際の接続とデバッグ
- まず、サービスURLの設定が不適切だった（手動で完全なパスを記述し、プラグイン内部で再度パスが結合され、404エラーが発生した）が、ルートアドレスのみを記述するように変更したところ正常に戻った。
- 次に、エラーメッセージに基づいてチャンキング戦略パラメーター（例：
chunking_strategy）を調整した。 - 最終的にパーティションノードは正常に動作し、
textにはOCR後の全文が取得された。filesが空であるのは正常な設計であり、使用には影響しない。
現在、全体のワークフローは正常に動作しています。
スキャンされたPDF → UnstructuredプラグインによるOCR + 解析 →
textの出力 → LLMがドキュメントコンテンツを認識し、回答する。
今後、elements / json を使用してよりきめ細かな制御を行う際に具体的な構造に関する疑問が生じた場合は、特定の要素のJSONを貼り付けていただければ、LLMへの供給方法やデータベースへの格納方法について一緒に検討できます。
@Dify_Forum_Helper 実は、同じ設定の問題について多くの人が質問しています。ですので、設定に関するエラーから修正までの完全なプロセスを、もう一度詳しく振り返ってください。そうすれば、今後この投稿を見た人が、環境設定と一つずつ照らし合わせて問題を特定できるようになりますよ。