Difyチームの皆様、
まず、新しいRAGパイプライン機能の素晴らしい仕事に感謝いたします。グラフベースのワークフローエンジンは、以前のハードコードされたChatAppRunnerフローからの大幅な改善です。ソースコードを読ませていただき、パイプラインのUXに関して2つの質問/提案があります。
- LLMを使用してパイプラインテンプレートを自動マッチングしないのはなぜですか？
現在、ナレッジベースを作成する際、ユーザーは手動でパイプラインテンプレート（PipelineBuiltInTemplate / PipelineCustomizedTemplate）を閲覧し、選択する必要があります。LLMがアップロードされたドキュメントを自動的に分析し、最も適切なテンプレートを推奨/選択するのではなく、この決定の背後にある設計思想について興味があります。
いくつか考えられる理由があります：
不可逆性のリスク：テンプレートの選択は、ドキュメントがどのようにチャンク化、埋め込み、インデックス化されるかに直接影響します。LLMが間違ったテンプレートを選択した場合、ユーザーはデータセット全体を削除して再処理する必要があり、これはコストのかかる間違いです。
ハルシネーションの懸念：LLMは、特に曖昧なファイルタイプやドメイン固有のドキュメントに対して、自信を持って誤ったテンプレートを選択する可能性があります。
ビジネスコンテキストのギャップ：適切なテンプレートを選択することは、「これはどのような種類のドキュメントか」ということだけでなく、チャンク構造、埋め込み戦略、および下流のリトリーバルニーズに関する決定も伴います。これらは、LLMがファイルコンテンツだけでは推測できないビジネスレベルの決定です。
追加コストとレイテンシー：ドキュメントをアップロードするたびに、余分なLLM推論呼び出しが必要となり、インデックス作成が始まる前でさえ、トークンコストと処理遅延が追加されます。
これらが実際の考慮事項であるかどうか、チームで確認していただけますでしょうか？将来的に、オプションの「スマートテンプレート提案」機能（自動選択ではなく推奨として）を提供する計画はありますか？
- LLMを使用してワンクリックでパラメータを自動構成しないのはなぜですか？
テンプレートの選択を超えて、各パイプラインワークフローには複数のノードレベルのパラメータ（チャンクサイズ、オーバーラップ、セパレーター、埋め込みモデル、リトリーバル戦略など）が含まれています。RAGの専門家ではないユーザーにとって、これらのパラメータを構成することは大きな障壁となります。
チームは、「LLM支援による自動構成」モードを検討しましたか？このモードでは：
ユーザーがサンプルドキュメントをアップロードする
LLMがドキュメント構造（例：長文テキスト vs 構造化テーブル vs コード）を分析する
システムが各ノードに最適なパラメータを自動的に提案または入力する
懸念事項としては以下が考えられます：
決定論：パラメータ構成には正確で決定論的な値が必要ですが、LLMは実行ごとに一貫性のない提案をする可能性があります。
説明責任：自動構成されたパラメータが低いリトリーバル品質につながる場合、ユーザーがデバッグするのがより困難になります。
費用対効果：ルールベースのヒューリスティック（例：「ドキュメントがテーブルを含むPDFの場合 → より小さなチャンクサイズを使用する」）は、LLMコストなしで90%のメリットを達成できる可能性があります。
お時間をいただきありがとうございます！