Platform For AI:アプリケーションフローの開発

Start

Start ノードは、アプリケーションフローの実行の開始を示し、フローの入力パラメーターを構成できます。

• 会話型アプリケーションフローの場合、システムは History と User input の 2 つのデフォルトフィールドを提供します。必要に応じてカスタム変数を追加できます。また、ファイルタイプの入力変数を定義して、ユーザーがアップロードしたファイルを受け取ることもできます。詳細については、「ファイルタイプの入力と出力」をご参照ください。

  

• アプリケーションフローを実行するときに、チャットパネルで現在のセッションの入力パラメーターを構成できます。

  

LLM

LLM ノードは、アプリケーションフローのコアコンポーネントであり、大規模言語モデルを呼び出して自然言語タスクを処理するように設計されています。このノードは、質問に答えたり、複雑な自然言語入力を処理したりするために、インテリジェントなテキスト応答を取得します。さらに、LLM ノードは柔軟な構成オプションを提供し、ユーザーがモデルパラメーターを調整したり、会話履歴を管理したり、プロンプトをカスタマイズして応答の品質と精度を最適化したりできます。

• シナリオ

  • テキスト生成: トピックまたはキーワードに基づいてテキストコンテンツを生成します。

  • コンテンツ分類: メールタイプ (問い合わせ、苦情、迷惑メール) を自動的に分類します。

  • テキスト変換: テキストを指定された言語に翻訳します。

  • RAG: 取得した知識を組み合わせてユーザーの質問に答えます。

• 構成インターフェイス

  

• 入力

  • モデル設定: ModelGallery からデプロイされたモデルサービス、その他のカスタムデプロイされたモデルサービス、または Dashscope や DeepSeek などのプロバイダーのモデルを使用できます。パフォーマンスを向上させるには、より高性能なモデルを選択することをお勧めします。次のモデルパラメーターを構成できます。

    • Temperature: 通常 0 から 1 の間の値で、モデルの出力のランダム性を制御します。0 に近い値は結果をより決定論的で一貫性のあるものにし、1 に近い値はよりランダムで多様なものにします。

    • Top P: 結果の多様性を制御します。モデルは候補単語のリストから選択し、選択された単語の累積確率が設定されたしきい値 P を超えないようにします。

    • Top K: 結果を生成する際に選択できる候補単語の数を制限することで、モデルの出力を制御します。具体的には、Top K は値 K を設定し、モデルは最も確率の高い上位 K 個の単語からのみ選択します。このメソッドはランダム性を減らし、出力をより可能性の高い単語に集中させます。Top P と比較して、Top K は累積確率に依存するのではなく、候補の数をより直接的に制限します。

    • Presence penalty: モデルが同じエンティティや情報を繰り返す傾向を減らします。すでに生成されたコンテンツにペナルティを課すことで、モデルは新しいまたは異なるコンテンツを生成するように促されます。値が高いほどペナルティが大きくなり、繰り返しが発生しにくくなります。

    • Frequency penalty: 頻繁に出現しすぎる単語やフレーズの生成確率を減らします。値が高いほど、一般的な単語やフレーズに大きなペナルティが課され、テキストの語彙の多様性を高めるのに役立ちます。

    • Maximum tokens: モデルが 1 回のターンで生成できる出力の最大長を設定します。値が低いとテキストが短くなったり切り捨てられたりする可能性があり、値が高いとより長い出力が可能になります。これにより、生成されるコンテンツの規模と複雑さを制御して、長さの要件を満たすことができます。

    • Seed: シード値が指定されている場合、モデルは決定論的なサンプリングを実行しようとします。そのため、同じシードとパラメーターでリクエストを繰り返すと、同じ結果が生成されるはずです。ただし、完全な決定論は保証されません。潜在的な変更を監視するには、system_fingerprint レスポンスパラメーターを参照してください。詳細については、「system_fingerprint」をご参照ください (プロキシが必要な場合があります)。

    • Stop sequences: 最大 4 つの停止シーケンスを指定できます。モデルがこれらのシーケンスのいずれかを検出すると、それ以上のトークンの生成を停止し、返されるテキストには停止シーケンス自体は含まれません。

  • History: 有効にすると、アプリケーションフローのチャット履歴がプロンプトに自動的に挿入されます。

  • 入力変数: このノードでは、先行するすべてのノードの出力を参照できます。

  • Prompt: SYSTEM、USER、および ASSISTANT プロンプトのコンテンツをカスタマイズします。プロンプトは Jinja2 テンプレートであり、{{variable}} のように二重中括弧を使用して入力変数を参照できます。

• 出力

  ノードはデフォルトで文字列形式のデータを出力しますが、JSON 形式で出力するように構成することもできます。JSON タイプでは、カスタム出力変数を追加でき、LLM は変数名の意味に基づいて出力を生成します。

• ユースケース

  • LangStudio に基づいて金融およびヘルスケアセクター向けの DeepSeek+RAG ベースの Q&A アプリケーションフローを構築する

  • LangStudio と DeepSeek に基づく RAG と Web 検索チャットボットソリューション

Python 開発 (Python)

アプリケーションフローは、カスタムの Python コードノードをサポートしており、複雑なデータ処理ロジックを実装し、ストリーミング入出力をサポートできます。構成インターフェイスは次のとおりです。

Python コードを入力するだけで、入力と出力がコードから自動的に解析されます。次の点に注意してください。

• エントリポイント関数は、ノードとして認識されるように @tool で装飾する必要があります。

  説明

  Python ノードのストリーミング入力を有効にするには、@tool(properties={"streaming_pass_through": True}) を構成する必要があります。そうしないと、LLM からの入力など、Python ノードへのすべての入力は、ストリームではなく完全なテキスト出力になります。

• 関数のサポートされている入出力タイプ: int、float、bool、str、dict、TypedDict、dataclass (出力のみ)、list、および File。

• エントリポイント関数の入力パラメーターは、ノードの入力として動的に解析されます。関数の出力は output ディクショナリに配置され、他のノードから参照できます。

  重要

  Python ノードの入出力パラメーターの自動解析は、ランタイムに依存します。ランタイムが開始されていない場合、ノードの入出力情報を構成することはできません。

• Python コードに依存関係が必要な場合は、キャンバスの右上隅にある [依存関係のインストール] をクリックし、パッケージを指定します。requirements.txt ファイルは、アプリケーションフローとともに保存されます。ランタイムが開始されるか、サービスがデプロイされると、依存関係は対応する環境にインストールされます。

  

  

ユースケース 1: コードエリアに次のコードを入力します。コードはノードの入力と出力にマッピングされます。

from langstudio.core import tool
from dataclasses import dataclass

@dataclass
class Result:
    output1: str
    output2: int

@tool
def invoke(foo: str, bar: int) -> Result:    
    return Result(
        output1="hello" + foo,
        output2=bar + 10
    )

ユースケース 2: ストリーミング入出力。最終的なテキスト出力ストリームを取得するには、Python ノードを使用して、LLM または Agent ノードからのテキストストリーム出力 (思考プロセスを含む可能性がある) をトリミングし、思考コンテンツの <think>\n\n<think> 部分を破棄します。以下に例を示します。

import re
from typing import Iterator
from langstudio.core import tool

@tool(properties={"streaming_pass_through": True})
def strip_think(
    stream: Iterator[str],
) -> Iterator[str]:  # 入力はストリーミング文字列イテレータで、出力はフィルタリングされたストリーミング文字列イテレータです
    # <think>\n...\n</think> 構造に一致させ、閉じタグの後のテキストをキャプチャします
    pattern = re.compile(r"<think>\n[\s\S]*\n</think>(.*)")
    in_thinking = True  # 現在の位置が <think> ブロック内にあるかどうかをマークします
    think_buf = ""      # 未処理のコンテンツを保存するバッファ

    for chunk in stream:
        if in_thinking:
            think_buf += chunk
            m = pattern.search(think_buf)  # バッファに完全な思考ブロックが含まれているかどうかを確認します
            if m:
                in_thinking = False
                result_part = m.groups()[0]
                if result_part:
                    yield result_part  # 結果のテキストが存在する場合は、すぐに出力します
        else:
            yield chunk  # 思考ブロックを離れた後、後続のすべてのチャンクを直接出力します

条件分岐 (Condition)

このノードは、主にフロー制御に使用されます。if-else ロジックを実装します。設定された条件が満たされると、対応するブランチのみが実行されます。どの条件も満たされない場合は、else ブランチが実行されます。このノードは、変数アグリゲートノードと併用する必要があります。

• 構成インターフェイス

  

• 入力

  ブランチ条件を構成する際は、次の点に注意してください。

  • 各ブランチは実行パスを表します。最後のブランチは else ブランチで、他のブランチ条件が満たされない場合に実行されます。このブランチは編集できません。

  • 各ブランチには複数の条件を含めることができ、and または or 演算子を使用して組み合わせることができます。

  • 条件が正確かつ効果的であることを確認するために、上流ノードの出力、一致演算子 (例: =、≠、空である、含まない)、および一致する値に注意してください。

• 出力

  出力なし。

• ユースケース

  Condition コンポーネントを子孫ノードに接続すると、各ブランチに対応する接続ポートができます。ブランチ条件がトリガーされると、そのブランチは接続された子孫ノードを実行し、他のブランチはスキップされます。その後、変数アグリゲートコンポーネントを使用して、各条件分岐からの実行結果を収集し、それが子孫ノードの出力として機能します。

  

変数アグリゲート

このノードは、異なるブランチからの出力結果を統合する役割を担います。どのブランチが実行されても、その結果を統一された変数を介して参照およびアクセスできるようにします。これは、異なるブランチからの同じ目的の変数を単一の出力変数にマッピングできるため、下流ノードでの冗長な定義を回避できるため、マルチブランチシナリオで非常に役立ちます。

• 構成インターフェイス

  

• 入力

  変数グループを構成する際は、次の点に注意してください。

  • 上流ノードは通常、複数の実行ブランチを生成する Condition または 意図認識ノードです。

  • 同じグループ内の変数は同じタイプである必要があります。最初の空でない出力値がそのグループの出力になります。

  • Condition または意図認識ノードは 1 つのブランチしかトリガーしないため、各グループには空でない値が 1 つしかありません。変数アグリゲートノードは、この値を抽出して下流で使用できます。

  • Condition または意図認識ノードの各ブランチに複数の必須出力がある場合は、複数のグループを追加して、対応する各出力値を抽出できます。

• 出力

  出力変数は、追加されたグループに基づいて動的に調整されます。複数のグループがある場合、ノードは複数のキーと値のペアを出力します。キーはグループ名で、値はそのグループの最初の空でない変数値です。

• ユースケース

  詳細については、「Condition」コンポーネントのユースケースをご参照ください。

意図認識

このノードは、主にフロー制御に使用されます。LLM を使用してユーザーの入力意図を分析し、認識結果に基づいて対応するブランチを実行します。マルチ意図構成と会話履歴をサポートします。

• 構成インターフェイス

  

• 入力

  • ユーザー入力: 意図認識に使用するユーザー入力を選択します。

  • マルチ意図構成: 必要に応じて意図を設定します。各意図の説明が明確で、異なる意図間に意味的な重複がないことを確認してください。最後の意図はデフォルトで「その他の意図」になり、他の意図が一致しない場合に実行されます。この意図は編集できません。

  • モデル設定: 意図認識用の LLM を構成します。パフォーマンスを向上させるには、qwen-max などのより高性能なモデルを選択することをお勧めします。

  • History: 有効にすると、モデルの推論中にアプリケーションフローのチャット履歴がプロンプトに自動的に挿入されます。

  • 追加のプロンプト: ここに入力されたコンテンツは、モデルが意図認識をより適切に実行できるように、システムプロンプトに追加されます。

• 出力

  このノードには出力がありません。

• ユースケース

  意図認識コンポーネントを下流ノードに接続すると、各意図ブランチにはコンポーネントに対応する接続ポートがあります。意図が認識されると、そのブランチに接続された下流ノードが実行され、他のブランチのノードはスキップされます。その後、変数アグリゲートコンポーネントを使用して、さまざまな条件分岐 (つまり、下流ノードの出力) からの実行結果を収集できます。

  

インデックスルックアップ

このノードは、ナレッジベースからユーザーの質問に関連するテキストコンテンツを取得し、下流の LLM ノードのコンテキストとして使用します。

• 構成インターフェイス

  

• 入力

  • ナレッジベースインデックス名: LangStudio に登録され、利用可能なナレッジベースを選択します。詳細については、「ナレッジベース管理」をご参照ください。

  • 検索キーワード: ナレッジベースから取得したいキー情報を選択します。これは、上流ノードの出力パラメーターを参照し、文字列形式である必要があります。

  • Top K: システムがナレッジベースから返す、検索キーワードに最も関連性の高い上位 K 件の結果の数。

• 出力

  ノードは、result という名前の List[Dict] 型の変数を出力します。ディクショナリのキーには、次のフィールドが含まれます。

  キー	説明
  content	取得したドキュメントチャンクのコンテンツ。これはナレッジベースから抽出されたテキストの断片で、通常は入力クエリに関連しています。
  score	ドキュメントチャンクと入力クエリの間の類似度スコアで、チャンクがクエリにどれだけ一致するかを示します。スコアが高いほど、関連性が高いことを示します。

  以下は出力の例で、スコアが最も高い top_k レコードが含まれています。

  [
    {
      "score": 0.8057173490524292,
      "content": "COVID-19 パンデミックによってもたらされた不確実性の影響を受け、XX 銀行は、中国または中国本土の経済動向と環境予測に基づいて、ローン、前払金、および非信用資産の減損損失引当金を積極的に増加させました。また、銀行は不良資産の償却と処分を増やし、引当金カバー率を引き上げました。2020 年には、純利益は 289 億 2800 万元に達し、前年比 2.6% 増加し、収益性は徐々に改善しました。(百万元) 2020 2019 変化率 (%) 営業成績と収益性 営業収益 153,542 137,958 11.3 減損損失前営業利益 107,327 95,816 12.0 純利益 28,928 28,195 2.6 経費率(1)(%) 29.11 29.61 0.50 パーセントポイント低下 平均総資産利益率 (%) 0.69 0.77 0.08 パーセントポイント低下 加重平均自己資本利益率 (%) 9.58 11.30 1.72 パーセントポイント低下 純金利マージン(2)(%) 2.53 2.62 0.09 パーセントポイント低下 注: (1) 経費率 = 営業および管理費用 / 営業収益。",
      "id": "49f04c4cb1d48cbad130647bd0d75f***1cf07c4aeb7a5d9a1f3bda950a6b86e",
      "metadata": {
        "page_label": "40",
        "file_name": "2021-02-04_XX_China_Insurance_Group_Co_Ltd_XX_China_XX_2020_Annual_Report.pdf",
        "file_path": "oss://my-bucket-name/datasets/chatglm-fintech/2021-02-04__XX_China_Insurance_Group_Co_Ltd__601318__XX_China__2020__Annual_Report.pdf",
        "file_type": "application/pdf",
        "file_size": 7982999,
        "creation_date": "2024-10-10",
        "last_modified_date": "2024-10-10"
      }
    },
    {
      "score": 0.7708036303520203,
      "content": "72 億元、前年比 5.2% 増。\n2020 \n(百万元) 生命保険および健康保険事業 損害保険事業 銀行事業 信託事業 証券事業 その他の資産管理事業 テクノロジー事業 その他の事業および連結消去 グループ連結 \n親会社の株主に帰属する純利益 95,018 16,083 16,766 2,476 2,959 5,737 7,936 (3,876) 143,099 \n少数株主持分 1,054 76 12,162 3 143 974 1,567 281 16,260 \n純利益 (A) 96,072 16,159 28,928 2,479 3,102 6,711 9,503 (3,595) 159,359 \n除外項目: \n 短期投資の変動(1)(B) 10,308 – – – – – – – 10,308 \n 割引率の変更の影響 (C) (7,902) – – – – – – – (7,902) \n 経営陣が日常の営業収益および支出に属さないとして除外した一時的な重要項目およびその他 (D) – – – – – – 1,282 – 1,282 \n営業利益 (E=A-B-C-D) 93,666 16,159 28,928 2,479 3,102 6,711 8,221 (3,595) 155,670 \n親会社の株主に帰属する営業利益 92,672 16,",
      "id": "8066c16048bd722d030a85ee8b1***36d5f31624b28f1c0c15943855c5ae5c9f",
      "metadata": {
        "page_label": "19",
        "file_name": "2021-02-04_XX_China_Insurance_Group_Co_Ltd_XXX_China_XX_2020_Annual_Report.pdf",
        "file_path": "oss://my-bucket-name/datasets/chatglm-fintech/2021-02-04__XX_China_Insurance_Group_Co_Ltd__601318__XX_China__2020__Annual_Report.pdf",
        "file_type": "application/pdf",
        "file_size": 7982999,
        "creation_date": "2024-10-10",
        "last_modified_date": "2024-10-10"
      }
    }
  ]

• ユースケース

  • LangStudio に基づいて金融およびヘルスケアセクター向けの DeepSeek+RAG ベースの Q&A アプリケーションフローを構築する

  • LangStudio と DeepSeek に基づく RAG と Web 検索チャットボットソリューション

Agent

Agent ノードは、LangStudio ワークフローの自律的なインテリジェントエージェントコンポーネントです。このノードは、推論戦略とツールの使用をサポートします。さまざまな推論戦略 (現在、FunctionCalling と ReAct ポリシーがサポートされています) を統合することで、Model Context Protocol (MCP) ツールを自律的に呼び出すことができ、LLM がツールを動的に選択して実行し、自律的なマルチステップ推論を実現できます。

• 構成インターフェイス

  

• 入力

  • Agent ポリシー: 目的の Agent 推論戦略を選択します。現在、FunctionCalling と ReAct ポリシーがサポートされています。

    FunctionCalling

    OpenAI Chat API の構造化された tool call 定義 (JSON 形式) に基づいて、FunctionCalling は LLM と外部ツール間の相互作用を可能にします。LLM は、ユーザーの自然言語の指示に基づいて、意図を自動的に識別し、適切なツールを選択し、パラメーターを抽出します。その後、システムは対応するツールを呼び出し、結果をモデルに返して、最終的な回答を生成するためのさらなる推論を行います。

    ユースケースと利点:

    • 構造化された呼び出し、強力な互換性: 構造化データを使用してツール名と呼び出しパラメーターを明確に定義し、ツール呼び出しをサポートするすべてのモデルとの互換性を確保します。

    • 安定したパフォーマンス: 天気の確認、情報の検索、データのクエリなど、明確な目的と手順を持つタスクに適しています。

    ReAct

    ReAct (Reasoning + Acting) 戦略は、より柔軟な推論アプローチです。プロンプトを通じてモデルが思考と行動を明示的に生成するように誘導し、マルチステップの推論とツール呼び出しの閉ループを作成します。この戦略は通常、自然言語を使用して呼び出しプロセスを記述し、「Action=xxx, Action Input=xxx」のようなテキストを出力することでバックエンドのツール実行をトリガーし、その結果をモデルの推論チェーンにフィードバックします。API レベルの tool_calls を必要としないため、より一般的なモデルやフレームワークに適しています。

    ユースケースと利点:

    • より強力な推論能力: モデルが段階的に考えるように誘導し、各ステップのロジックを明示的に表現します。

    • 透明なポリシー: デバッグや説明可能な Agent アプリケーションの作成に適しています。

    • ツール呼び出しのサポートは不要: 構造化出力をサポートしないモデルでも使用できます。

  • モデル設定: FunctionCalling 戦略は、OpenAI API の Tool Call メソッドを使用してツール情報を渡すため、モデルはツール呼び出し機能をネイティブにサポートする必要があります。ReAct 戦略にはこの制限はありませんが、推論能力の高いモデルを選択することをお勧めします。

  • History: 会話履歴を有効にすると、Agent にコンテキストメモリが提供されます。システムは、履歴の会話メッセージをプロンプトに自動的に入力し、Agent が以前のコンテンツを理解して参照し、一貫性のあるコンテキストを意識した応答をできるようにします。たとえば、ユーザーが新しいメッセージで代名詞 (「彼」、「そこ」、「あの日」など) を使用した場合、会話履歴が有効になっている Agent は、ユーザーが完全な情報を繰り返す必要なく、これらの代名詞が参照するエンティティを理解できます。

  • MCP サービス構成: MCP 接続の選択またはカスタムフォームの入力の 2 つの構成方法がサポートされています。現在、SSE および Streamable HTTP 通信方式を使用する MCP サーバーがサポートされています。

  • 入力変数: プロンプトで上流ノードの変数を参照するには、このノードに対応する入力変数を定義し、その値を上流ノード変数の参照に設定します。次に、以下の [プロンプト] セクションで、Jinja2 テンプレート構文 (二重中括弧 {{}}) を使用して、これらの定義された入力変数を参照し、データを動的に渡すことができます。

  • Prompt: SYSTEM、USER、および ASSISTANT プロンプトのコンテンツをカスタマイズします。プロンプトは入力変数を参照できます。

  • ループ数: Agent が実行する最大ループ数を 1 から 30 の範囲で設定します。Agent は、次のいずれかの条件が満たされるまで、ループ数に従ってタスクを繰り返します。

    • LLM は、ツールを呼び出して完全な結果を生成するのに十分な情報を収集したと判断します。

    • 設定された最大ループ数に達します。

    注: 適切なループ数を設定すると、応答の完全性と実行効率のバランスが取れます。

• 出力

  ノードは文字列型のデータを出力します。

• トレース/ログの表示

  アプリケーションフローページの右上隅にある [実行] をクリックした後に表示されるダイアログボックスで、実行結果の下にあるトレースまたはログを表示できます。

  • 中間出力の表示: ワークフローの Agent ノードの右上隅にある実行ステータスアイコンをクリックします。下に表示されるドロワーで、Output の下にある intermediate_steps を見つけて、Agent の推論プロセスを表示します。

  • トレースの表示: 現在の実行のトレース情報を表示して、各モデルリクエストの入力、モデルの出力 (ツール呼び出しとリクエストパラメーターを含む)、トークン消費量、および時間コストを理解します。

  • ログの表示: アプリケーションフローの実行中にエラーが発生した場合、現在の実行ログを表示して、ノードの実行プロセスの詳細を取得できます。

  さらに、アプリケーションフローページの右上隅にある [その他] > [実行履歴] をクリックし、特定の実行レコードを選択して、そのトレースまたはログを表示できます。

Loop

Loop ノードは、前の反復の結果に依存する反復タスクを実行するために使用され、終了条件が満たされるか、事前に設定された最大ループ数に達するまで継続します。Loop ノード内で、サブフローを構成できます。システムは、終了条件がトリガーされるか、最大実行回数に達するまで、ループ変数に基づいてサブフローのロジックを繰り返し実行します。

• 構成インターフェイス

  

• 入力

  • ループ変数: ループの反復間でデータを渡し、ループが終了した後に下流ノードで使用するために使用されます。複数のループ変数を構成でき、その値は手動で入力するか、上流ノードの出力から選択できます。

  • ループ終了条件: ループ変数に基づいて構成できます。指定されたループ変数が事前設定された条件を満たすと、ループは終了します。

  • 最大ループ数: 無限ループを防ぐために、最大ループ実行回数を制限するために使用されます。

• 出力

  ノードの出力は、現在のループ実行後のループ変数の値です。ループ変数は、変数代入ノードによってのみ更新できます。このノードがないと、Loop ノードの出力は N 回の反復後も初期入力と同じままになります。

• 関連ノード

  ループ関連のノードは、ループ内でのみ使用できます。ループ内の特定のノードの右側にある「+」アイコンをクリックして、次の関連ノードを追加できます。

  • ループの中断

    ループを終了します。先祖ノードは通常、Condition ノードです。

  • 変数代入

    ループ内のサブノードの出力結果をループ変数に割り当てます。

  

SerpAPI-GenericSearch

このノードは、Web 検索に SerpApi を使用します。複数の検索エンジン (Bing、Google、Baidu、Yahoo など、およびカスタムエンジン) をサポートし、検索場所と結果数を構成できます。

• 構成インターフェイス

  

• 入力

  • SerpApi 接続: LangStudio で作成された SerpApi 接続を選択します。詳細については、「SerpApi 接続の作成」をご参照ください。

  • 検索キーワード: Web 検索のキー情報を選択します。これは、上流ノードの出力パラメーターを参照し、文字列形式である必要があります。

  • 検索エンジン: bing、google、baidu、yahoo、およびカスタム入力をサポートします。

  • 場所: 検索の場所。使用する場合は、Shanghai, China のように都市に特定することをお勧めします。

  • 検索結果の数: 返すクエリ結果の数。

• 出力

  Web 検索は、output という名前の List[Dict] 型の変数を出力します。ディクショナリのキーには、次のフィールドが含まれます。

  キー	説明
  title	検索結果のタイトル。通常は Web ページまたはドキュメントのタイトルで、コンテンツのトピックを簡潔に要約します。
  link	検索結果のリンク (URL)。ユーザーはこのリンクから完全なコンテンツにアクセスできます。
  summary	検索結果の概要。コンテンツの簡単な紹介または概要を提供し、ユーザーがそのコア情報をすばやく理解するのに役立ちます。

• ユースケース

  LangStudio と DeepSeek に基づく RAG と Web 検索チャットボットソリューション

Alibaba Cloud IQS-GenericSearch

このノードは、標準検索に Alibaba Cloud Information Query Service を使用し、時間範囲によるフィルタリングをサポートします。

• 構成インターフェイス

  

• 入力

  • 検索キーワード: Web 検索のキー情報を選択します。長さは 2 文字から 100 文字の間である必要があります。100 文字を超えると切り捨てられます。2 文字未満の場合はエラーが発生します。

  • 時間範囲: 検索データの時間範囲を選択します。サポートされているオプションは、NoLimit、OneDay、OneWeek、OneMonth、および OneYear です。

  • IQS 接続: 起動時に必要な権限を持つロールが構成されていない場合は、事前構成された IQS 接続を選択できます。IQS 接続の構成方法については、「サービス接続構成 - カスタム接続」をご参照ください。キーと値をそれぞれ api_key と対応する値として構成します。対応する値は、Information Query Service - 認証情報管理で入手できます。IQS 接続の使用方法の詳細については、「LangStudio と Alibaba Cloud Information Query Service に基づく DeepSeek Web 検索アプリケーションフローの構築」をご参照ください。

• 出力

  • output: Web 検索は、output という名前の List[Dict] 型の変数を出力します。ディクショナリのキーには、次のフィールドが含まれます。

    キー	説明
    title	検索結果のタイトル。通常は Web ページまたはドキュメントのタイトルで、コンテンツのトピックを簡潔に要約します。
    link	検索結果のリンク (URL)。ユーザーはこのリンクから完全なコンテンツにアクセスできます。
    summary	検索結果の概要。コンテンツの簡単な紹介または概要を提供し、ユーザーがそのコア情報をすばやく理解するのに役立ちます。
    content	検索結果の完全なコンテンツまたは本文。詳細情報が含まれています。サイズが大きくなる可能性があるため、通常は概要には表示されません。
    markdown_text	Markdown 形式の検索コンテンツ。空を返す場合があります。
    score	検索結果のスコア。通常は、結果の関連性または品質を示す数値です。スコアが高いほど、通常、結果が検索意図により関連していることを意味します。
    publish_time	コンテンツの公開時間。通常はタイムスタンプまたは日付で、ユーザーが情報の適時性を理解するのに役立ちます。
    host_logo	ソース Web サイトのロゴまたはアイコン。通常は画像 URL で、ユーザーが情報のソースを識別するのに役立ちます。
    hostname	ソース Web サイトのホスト名またはドメイン名。情報のソースを示します。
    site_label	ソース Web サイトのラベルまたはカテゴリ。サイトのトピックまたはカテゴリを示し、ユーザーが情報のコンテキストを理解するのに役立ちます。

  • scene_items: 検索結果を強化するために使用される補助情報。ほとんどの一般的な検索では、scene_items は通常空です。ただし、一般的な検索がユーザーのニーズを正確に満たせない場合、特に特定のシナリオ (時間、天気、カレンダーなど) では、システムは補足として scene_items を返そうとします。これにより、ユーザーはより正確で有用な情報を受け取ることができます。

• ユースケース

  LangStudio と Alibaba Cloud Information Query Service に基づく DeepSeek Web 検索アプリケーションフローの構築

直接出力

直接出力ノードを使用すると、出力テンプレートを使用して直接返信メッセージを構成できます。{{node.variable}} 構文を使用して上流ノードの出力を参照でき、ストリーミング出力をサポートします。

例: LLM ノードの前に直接出力ノードを追加して、最初にユーザーに返信を送信します。

ドキュメント解析

このノードは、システムの組み込みインテリジェントドキュメント解析ツールと AI Search Open Platform のドキュメント解析サービスの両方の使用をサポートします。

• 組み込み解析ツール: ドキュメントから構造化されたコンテンツとメタデータを抽出します。PDF、DOCX、PPTX、TXT、HTML、CSV、XLSX、XLS、JSONL、MD など、さまざまな一般的なドキュメント形式をサポートします。

• AI Search Open Platform: 高精度の構造化ドキュメント解析を提供します。タイトルや段落などの論理階層情報、テキスト、表、画像などのコンテンツの抽出をサポートします。これにより、ドキュメント抽出の効果と精度が向上します。まず、AI Search Open Platform モデルサービス接続を構成する必要があります。サポートされているファイル形式には、PDF、DOCX、PPTX、TXT、HTML があります。

このツールは、RAG、要約、質疑応答などの下流のシナリオで使用できます。構成インターフェイスは次のとおりです。

• ドキュメントファイル: インテリジェント解析のために単一のドキュメントファイルを入力して、構造化されたコンテンツを抽出します。上流ノードからファイルタイプのフィールドを選択します。

• モデル設定: (オプション) LangStudio で作成された AI Search Open Platform モデルサービス接続を選択します。構成されていない場合、システムは組み込みの基本解析メソッドを使用してアップロードされたファイルを処理します。

• 出力結果:

  • file_id: 入力ファイルの一意の識別子。

  • content: タイトルや段落などの階層情報を含む、解析された構造化テキストコンテンツ。

  • status: 解析ステータス。SUCCESS または FAIL のいずれかになります。

  • metadata: ドキュメントのメタデータと解析の詳細。

    • file_name: ファイル名。

    • file_type: ファイルタイプ。

    • source_uri: ファイルの元の URI。

    • download_url: ファイルのダウンロード可能な URL。

    • analysis_method: 使用された解析メソッド。「opensearch」は AI Search Open Platform の構造化解析が使用されたことを示し、「builtin」は組み込みの基本解析メソッドが使用されたことを示します。

下流の使用例: 下流ノードで、必要に応じてドキュメント解析ノードの結果フィールドを参照します。LLM ノードでドキュメント解析結果を使用するには、以下に示すように、ユーザープロンプトで解析されたコンテンツを参照します。

End

End ノードは、アプリケーションフローの実行の終了を示し、その出力パラメーターを定義します。アプリケーションフローには End ノードを 1 つしか含めることができません。

• 出力パラメーターの構成

  アプリケーションフローの出力は、フローの実行の最終結果として、任意の上流ノードの出力を参照できます。たとえば、次の図では、アプリケーションフローの answer 出力は LLM ノードからの出力を使用し、search_results は検索ノードからの出力を使用します。

  

  説明

  • 会話型アプリケーションフローには、デフォルトの Chat 出力フィールドがあり、フローの会話型出力として機能します。

  • アプリケーションフローには、Start ノードと End ノードを含める必要があります。これら 2 つのノード間に接続されているノードのみが実行されます。スタンドアロンノードは実行されません。