探索エンジンの操作はコラボレーションです。 方向を設定し、成功の外観を定義します。 Cognition は実行を処理します。 このコラボレーションの品質は、期待をどの程度明確に表現するか、および提供する構造によって異なります。
この記事では、検証要件によって認識の動作がどのように形成されるか、タスクの詳細レベルを調整する方法、および作業を開始するための基本的な共有セッション パターンについて説明します。
検証要件の役割
検証要件は、認知の動作を導くための最も重要な 1 つのレバーです。 彼らは、タスクの結果が十分に良いかどうかを判断する方法を認知に伝えます。 彼らがいなければ、認知には客観的な基準はありません。 適切に記述された要件により、認知は品質を評価し、不十分な結果を拒否し、作業が条件を満たすまで再試行できます。
検証要件が緩すぎる場合の動作
検証要件があいまいまたは存在しない場合、認知はエージェントが生成する最初の結果を受け入れる傾向があります。 タスクはすぐに [完了] に移動しますが、結果が実際の期待を満たしていない可能性があります。
緩い要件の例:
"適切な回答を提供してください。"
認知には、コンテキストにおける "良い" 意味を評価する方法はありません。 失敗する具象が何もないため、エージェントの応答は検証に合格します。 結果を手動で確認して品質を判断し、自動化の目的が失われてしまいます。
検証要件が厳しすぎる場合の動作
検証要件が過度に特定されている場合、またはエージェントが確実に提供できない精度が要求される場合は、認識によってタスクが繰り返し再試行されます。 試行のたびに結果が生成され、まったく成功せず、複数の実行サイクルが発生します。 最終的には、すべての要件を満たす結果を生成できないため、認識はタスクにユーザーの注意が必要であるとフラグを設定します。
過度に厳しい要件の例:
"結果には、0.01 kcal/mol に正確な結合アフィニティ値と、各予測の実験検証参照を含める必要があります。"
使用可能なツールまたはモデルがそのレベルの精度を生成できない場合、すべての試行は検証に失敗します。 コグニションは、さまざまなアプローチを試みて時間とコンピューティングリソースを消費するものの、進展はありません。
適切なバランスを見つける
有効な検証要件は、適切な作業と悪い作業を区別するのに十分な特定の要件ですが、対応するエージェントがそれらを満たすのに十分な柔軟性があります。
検証要件を記述するためのガイドライン:
- エージェントが生成する方法ではなく、結果に含める必要がある内容を指定します。 「結果には、5 つの候補分子すべてに対する溶解度予測が含まれます」は、「Graphormer ツールを使用して溶解度を予測する」よりも優れています。
- 検証可能な条件に焦点を当てます。 「分析は少なくとも3つの分子特性をカバーする」が検証可能である。 "分析は徹底しています" ではありません。
- 精度を達成可能なものに一致させます。 予測モデルを使用している場合は、検証基準で試験段階の精度を必要としません。
- 複雑なタスクには複数の要件を使用します。 品質基準を個別の要件に分割して、どの要件に合格し、どれが失敗したかを認識で報告できるようにします。 これは、何が機能し、調整が必要かを理解するのに役立ちます。
- 結果に基づいて反復処理します。 完了したタスクを確認した後、同様の将来のタスクの検証要件を調整します。 共有セッションが進行するにつれて、"十分に良い" とは何を意味するかについての理解が進化します。
例: 適切に調整された検証要件
課題:「Graphormerを用いて3つの候補分子の溶解性と還元性を予測する」
検証の要件:
- "結果には、3 つの候補分子すべてに対する予測が含まれます。"
- "各予測には、溶解度 (logS) と還元の潜在的な値の両方が含まれます。"
- "結果は分子識別子を持つ構造化形式で表示されます。"
これらの要件は特定の要件 (3 つの分子すべて、両方のプロパティ、構造化形式) ですが、達成可能です (モデルがサポートしていない特定の精度しきい値は必要ありません)。
構造のレベル
タスクにどの程度の構造を入れるかによって、単独で把握する必要がある認知の量が決まります。 これは、高い自律性 (広範な目標を提供し、認知がすべてを処理する) から高い構造 (各ステップを定義し、認識を実行して検証する) までの範囲と考えてください。
信頼レベルまたは自律モードを選択するための明示的な設定はありません。 共有セッションを設定する方法を使用して、選択を表現します。 1 つの広範なタスクを作成すると、認知は計画と分解の所有権を取得します。 複数のタスクと依存関係を作成する場合、認識は構造に従います。 また、信頼を得るにつれて構造化された制御を開始して緩めたり、認知が正しい方向に向いていない場合は制御を強化したりすることもできます。
最小限の構造で広範な目標
一般的な検証要件を持つ 1 つの大まかなタスクを提供します。 Cognition はそれをサブタスクに分解し、エージェントを選択し、共有セッション全体を管理します。
この方法を使用する場合:
- 新しい問題領域を調査していて、適切な手順がまだわかっていない
- あなたは認知が発見するアプローチを見たいと思う
- この問題は、複数の有効なパスが存在する程度に広い
想定される内容:
- Cognition では、明示的に定義しなかったサブタスクが作成されます
- 作業を分解する方法と一致しない可能性があります
- 初期タスクの結果によって、次に何を認知しようとするかが決まります。
- 認識が役に立たない方向に進むかどうかを定期的に確認し、リダイレクトする
Example:
タスク: 「標的タンパク質Yを有する化合物Xの結合機構を調べ、結合アフィニティーを向上させる可能性のある構造修飾を同定する」。
検証: "分析は結合メカニズムで少なくとも 3 つの主要な相互作用を識別する" と "少なくとも 2 つの構造変更が論理的に提案されています。"
依存関係を持つ構造化タスク
タスク階層は、主要なフェーズの親タスク、特定のステップの子タスク、実行順序を制御するための依存関係、および各タスクの詳細な検証要件を自分で作成します。
この方法を使用する場合:
- 必要な手順がわかっており、それらが確実に従っていることを確認する必要がある
- 共有セッションには、相互に依存する明確なフェーズがあります
- 特定のタスクに特定のエージェントを割り当てる
- 各ステップの品質が重要であり、検証チェックポイントが必要です
想定される内容:
- 認知は、定義した構造に従います
- タスクは、依存関係を使用して指定した順序で実行されます
- 検証は、最後だけでなく、各ステップで行われます
- Cognition は、設定した構造内でエージェントの実行、エラーの回復、再試行を引き続き処理します
- タスクが検証に失敗した場合、依存タスクに移動する前に認識によって再試行されます
Example:
Parent: "Characterize target molecule and identify improved analogs"
Task 1: "Retrieve molecular structure from PubChem" (no dependencies)
Task 2: "Compute molecular properties using RDKit" (depends on Task 1)
Task 3: "Predict solubility using Graphormer" (depends on Task 1)
Task 4: "Rank candidates by combined criteria" (depends on Tasks 2 and 3)
各タスクには、独自の検証要件があります。 タスク 2 とタスク 3 は、タスク 1 の完了後に並列で実行されます。 タスク 4 は両方を待機します。
ハイブリッド アプローチ
実際には、ほとんどの共有セッションではミックスが使用されます。 主要なフェーズは自分で構成できますが、認識によって特定のフェーズがサブタスクに分解されます。 または、広範な作業を開始し、認識によって作成されるサブタスクを確認し、必要に応じて構造を追加することもできます。
多くの場合、この方法が最も効果的です。 あなたは、適切な全体的な構造に関するドメイン知識を持ち込み、認知は各フェーズ内で戦術的な実行を処理します。
作業の開始: 最初の共有セッション
探索エンジンを初めて使用する場合は、シンプルで構造化された共有セッションから始めて、より広範な目的に移行する前に、認知のしくみに関する知識を深めます。
手順 1: 小さな共有セッションを作成する
2 ~ 4 の明確な手順を備えた重点的な目標から始めます。 この方法では、結果を数時間待たずに、タスクのライフサイクル全体 (新規、実行中、検証、完了) を確認できます。
手順 2: 特定の検証要件を記述する
最初の共有セッションでは、広範なものではなく、具体的なものを選ぶようにしてください。 検証のしくみを理解できるように、認知によって抽出条件に対して結果が評価されるのを確認する必要があります。
手順 3: ディスカバリー エンジンを起動して観察します
Cognition がエージェントを選択し、タスクをシーケンスし、検証を処理する方法を確認します。 何かが明らかに間違っていない限り介入しないでください。 このアプローチは、認知に必要なガイダンスの量に対する直感を構築します。
手順 4: 確認して調整する
共有セッションが完了したら、次の内容を確認します。
- 認知は、設定したタスク構造に従いましたか?
- 検証要件は有効でしたか、それとも不要な再試行を引き起こしましたか?
- 適切なエージェントは各タスクに割り当てられましたか?
学習した内容を使用して、次の共有セッションを調整します。
時間の経過に伴う信頼の調整
探索エンジンの経験を積むにつれて、さまざまな種類の作業に必要な構造に対する感覚を身に付けることができます。 留意すべきいくつかのパターン:
- 既知の手順で十分に理解された共有セッションは、より多くの構造からメリットを得られます。 パスはわかっているので、それを定義します。 認識が実行と検証を処理できるようにします。
- オープンエンドの目標を持つ探索的研究は、構造が少ない利点があります。 定期的に探索してチェックインするための認知スペースを与えます。
- 一部のフェーズがよく理解され、他のフェーズがハイブリッド アプローチの探索的な利点を持つ混合共有セッション。 知っていることを構造化し、自分が知らないものを委任します。
- 検証の要件 は、エージェントとツールが提供できる内容を学習すると、より正確になります。 [全般] を開始し、結果に基づいて絞り込みます。