AIニュース最前線
最新ニュースAI日報Hacker日報週報動画AIツールトレンド企業

AIニュース最前線

世界中のAI最新情報を日本語で毎時更新

最新ニュース日報トレンド企業プレミアムRSS
© 2026 ainew.jp特定商取引法に基づく表記
ニュース一覧元記事を開く
LangChain Blog·2026年4月10日 00:00·約21分で読める

エージェント改善ループにおける人間の判断

#AIエージェント#人間-AI協調#ドメイン知識#LangChain#金融テック#改善ループ
TL;DR

LangChainの記事は、AIエージェントの開発において暗黙知を含む人間の判断を改善ループに組み込む重要性を、金融取引の具体例を通じて解説している。

AI深層分析2026年4月10日 00:41
3
注目/ 5段階
深度40%
4
関連度30%
4
実用性20%
4
革新性10%
2

キーポイント

1

暗黙知の重要性

組織の成功には文書化された知識だけでなく、従業員の暗黙知が不可欠であり、AIエージェント開発時にその重要性が明らかになる。

2

改善ループの構築

エージェントの信頼性向上には、ドメイン専門家からの入力を継続的に取り込む改善ループが必要である。

3

コンテキストの二層構造

金融取引エージェントの例では、ドメイン知識(取引慣行)と技術知識(データベース実装)の両方のコンテキストが重要である。

4

ワークフロー設計への応用

LLM呼び出しのタイミングやコンテキスト提供などの設計判断は、適切なステークホルダーからの入力によって改善される。

5

コードによるワークフローの制御

LLMの自律的なツール呼び出しに加え、低遅延・トークン削減・確実な実行のためにコードでワークフローの一部を定義する。規制や高リスク環境ではコードによる厳密な制御が必要。

6

ツール設計の柔軟性と制御のトレードオフ

汎用的なSQL実行ツールは柔軟性が高いがリスクも高く、パラメータ化されたクエリツールは安全だが機能が限定される。ビジネス制約を考慮し、評価を通じて適切な設計を決定する必要がある。

7

エージェントコンテキストの進化

単一のシステムプロンプトから、事前にキュレーションされた文書・例・ドメインルールを実行時に取得する方式へ移行。これにより、より多くの知識を効率的に活用できる。

影響分析・編集コメントを表示

影響分析

この記事は、AIエージェント開発における人間中心アプローチの重要性を明確に示しており、実用的なシステム構築のための具体的な方法論を提供している。特に、暗黙知の形式化と専門家協業のプロセス設計は、産業界でのAI導入成功の鍵となる示唆を与えている。

編集コメント

実務志向の内容で、AIエージェント開発の現場課題に直結する洞察を提供している。特に暗黙知の扱い方に関する指摘は、多くの組織が直面する根本的な課題を捉えている。

imageimageBy Rahul Verma, Deployed Engineer @ LangChain

AIエージェントは、あなたのチームが時間をかけて築き上げてきた知識と判断力を反映するときに最も効果的に機能します。その一部はすでに文書化された組織的知識であり、エージェントがそのまま使用するのは容易です。しかし、ほとんどの優れた組織は、従業員の頭の中にある暗黙知にも依存しています。チームは、有意義な仕事を遂行するためにその情報がいかに重要であるかを、AIエージェントを構築して自動化しようとするまでしばしば認識していません。この知恵をエージェントに組み込むためには、ドメインエキスパートからの入力を取り込む改善ループが必要です。

このガイドでは、以下の内容を扱います:

あなたのエージェントのどのコンポーネントが人間の判断を取り込むことで恩恵を受けるか

開発ライフサイクルの各段階で、どのように人間の判断をエージェントに組み込むか

実例に基づく例:トレーダー向けコパイロット

金融サービス企業を想像してください。そのトレーダーは最新の市場データを必要としています。現在、彼らは質問をデータサイエンスチームに送ります。データサイエンティストはSQLクエリを書き、関連データを取得し、結果を返送します。LLM(大規模言語モデル)はSQL生成に優れているため、このワークフローはAIエージェントで自動化する自然な候補です:トレーダーはより速い応答を得られ、データサイエンティストはより興味深いプロジェクトに自由に取り組めます。

このシステムが確実に機能するためには、エージェントは金融サービスドメインレベルと技術的データベースレイヤーの両方でコンテキストを必要とします。前者には、「今日のエクスポージャー」や「最近のボラティリティ」といったリクエストをどのように解釈するかを決定する、文書化されていない取引の慣習が含まれます。後者には、どのテーブルが信頼できるものか古いものか、どのクエリパターンが誤りがちまたは非効率になりがちかといった、データベースに関する実用的な知識が含まれます。エージェントが必要とするすべての文書化されていないコンテキストを含めるために、適切な主題専門家と協力する必要があります。

このガイド全体を通じて、具体的な実装例を示すためにこの例を使用します。これは、アーキテクチャがシンプルであり、エージェント設計に人間の判断を関与させるための重要な原則を示す良い例です。

人間の判断で改善できるエージェントのさまざまなコンポーネントを確認しましょう。

人間の入力がAIエージェントの各コンポーネントをどのように改善するか

エージェントを構築するとは、いつLLMを呼び出すかを決定し、望ましい結果を達成するために各呼び出しで提供するコンテキスト(例:ドキュメント、メモリ、会話履歴、ツール)を管理することを意味します。これらの設計上の選択はそれぞれ、適切なステークホルダーからの入力によって恩恵を受けます。

ワークフロー設計

今日のLLMは、自身のアクションを順序立てることに優れています。いくつかのツールと自然言語の指示を与えるだけで、どのツールをどの順序で呼び出すかを理解します。しかし、ワークフローの一部を決定論的なコードで定義することには利点があります:レイテンシの低下、トークン数の削減、重要なステップが実際に実行される保証です。一部の規制や高リスクの設定では、アクションの順序を厳密に制御するためにコードが必要です。私たちのトレーダーコパイロットでは、LLMが自律的にSQLクエリを生成して実行することを許可しますが、最終的な回答が当社のリスクとコンプライアンス要件を満たしていることを検証するコードを追加してから、トレーダーに返送します。当社の基準を強制する自動チェックを作成するには、リスクとコンプライアンスの専門家からの入力が必要です。また、その情報をエージェントの事前読み込みコンテキストに含めることで、最初の試行で有効な回答を作成する確率を高めることができます。

ツール設計

開発者は、エージェントが使用できるツールを実装し、LLMがいつ呼び出すかを決定する際に依存する名前、パラメータ、説明を設定する必要があります。ワークフローの異なる段階で利用可能なツールを変えることがしばしば有用です。単一のLLM呼び出しに対するツールセットを制限することで、モデルを意図した動作に導き、無関係なオプションを選択する可能性を減らすことができます。

私たちのコパイロットのツールには、データベーススキーマ検査、クエリ実行、データベースドキュメント取得が含まれるかもしれません。重要なトレードオフは、LLM生成クエリの柔軟性と制御です:一般的なexecute_sqlステップは柔軟なクエリを可能にしますがリスクを増加させます。パラメータ化されたクエリツールはより安全ですが能力が低くなります。ビジネス制約を詳細にレビューすることで、どのオプションが適しているかの感覚を得られるかもしれませんが、確実に知るためには、ツール設計のパフォーマンスとリスク特性を決定する評価を実行し、すべてのステークホルダーが結果に満足したときにのみリリースする必要があります。

エージェントコンテキスト

初期のエージェントは、モデルに単一のシステムプロンプトと一連のツール定義を与えるだけでした。時間の経過とともに、業界はエージェントの実行開始時にはるかに豊富なコンテキストを提供する方向に移行しています。10月にローンチされて以来急速に人気を集めている標準であるAnthropicのSkillsは、この傾向の顕著な例の一つです。

すべてを一つのシステムプロンプトに詰め込む代わりに、あなたのチームは事前にドキュメント、例、ドメインルールをキュレーションし、エージェントが必要なものを実行時に取得できるようにします。これにより、エージェントはシステムプロンプトを肥大化させることなく、はるかに多くの知識を使用できます。効果的なエージェント設計には、エージェントがアクセスすべき知識を決定し、エージェントが適切な瞬間に適切な情報を取得できるように整理することが含まれます。

少なくとも、私たちのトレーダーコパイロットは、データベースの使用方法とそのスキーマを理解する必要があります。私たちのコパイロットが必要とするチームからの追加知識の性質と量に応じて、その知識を収集するだけでなく、それをどのように構造化し、段階的にエージェントに開示するかを決定する時間を費やす必要があります。

エージェントが起動時に利用可能な情報を選択し構造化することは、コンテキストエンジニアリングの分野の一部です。コンテキストエンジニアリングはまた、エージェントがタスクを進めるにつれて、各LLM呼び出しで提供する情報がどのように進化するかもカバーします。人間のステークホルダーがエージェントの出力と評価スコアをレビューする際に提供するフィードバックは、エージェントのエンドツーエンドのコンテキストエンジニアリングにどのようにアプローチするかに影響を与えるかもしれません。

人間の判断で恩恵を受けるエージェントの部分を概説したので、その人間の入力を収集する方法を扱います。

エージェント改善ループへの人間の判断の組み込み

LangChainでは、AIエージェントをデプロイする何百もの組織と協力してきました。最も成功しているチームは、厳密な反復ループに従います:彼らは迅速にエージェントを構築し、本番または本番類似環境にデプロイし、各ステップでデータを収集して改善を導きます。これを「エージェント改善ループ」と呼びます。なぜなら、最も成功しているエージェントのほとんどがこのループを複数回通過しており、以前にここでより詳細に扱ったからです。

迅速かつ頻繁に反復することが重要です。なぜなら、エージェントの動作を決定するのはコードではなく、LLMのリアルタイム推論だからです。AIエージェントが何をするかは、実行するまでわかりません。AIエージェントインターフェースはしばしば自由形式です(例:ユーザーが何でも入力できるテキストボックス)。これにより、ユーザーとエージェントの間の相互作用がどのように見えるかを予測することはさらに困難になります。エージェントをユーザーの前に置くことが、最終的に成功させるために必要なデータを収集する唯一の方法です。

imageimage人間の入力を効果的に組み込む方法について議論しながら、フライホイールの以下のフェーズを順を追って説明します:

エージェントの最初のバージョンの実装

エージェントが稼働した後の監視と、それを洗練するための本番データの収集

改善されたエージェントバージョンの実装とテスト

詳細に入る前に、開発ライフサイクル全体に適用される原則を強調する価値があります。

人間の時間投資に対する高いリターンの鍵:人間の判断に沿った自動評価

人間が大量のエージェント出力を手動でレビューするのではなく、自動評価器の設計と調整を支援するときに、チームはより多くのレバレッジを得ることを観察しました。あなたのチームがどれだけ大きくても、どれだけリソースが豊富でも、広範な手動レビューに依存することは経済的であることはめったにありません。スケーラブルなアプローチは、専門家の判断を自動評価に変換し、広範かつ継続的にテストできるようにすることです。それがLangSmithのAlign Evaluator機能が支援することです。それは、キュレーションされた例と主題専門家からのフィードバックを使用して、LLM-as-a-judge評価器を調整するためのユーザーインターフェースを提供します。非開発者ステークホルダーの判断を模倣することを意図した評価器には、この機能を使用することをお勧めします。

imageimageLLM-as-a-judgeプロフェッショナリズム評価器を検証するためにLangSmithのAlign Evaluator機能を使用。評価器は現在、人間の判定者よりも厳格なので、より寛容にするためにシステムプロンプトを変更する必要があります。仮想の取引会社の視点から、改善ループの各フェーズを通じてトレーダーコパイロットを追いましょう。人間の入力を効果的に組み込む方法、特にその入力を自動評価にどのように導くかを見ていきます。

開発:テストスイートと評価器のキュレーション

開発が開始される前に、エンジニアはプロジェクト要件の一部として、少なくとも小さなユースケースシナリオと期待される動作を持っているべきです。これらの初期テストは、エージェントがコアタスクを正しく実行することを確認するのに役立ちます。エージェントが本番準備に近づくにつれて、エンジニアはプロダクトマネージャーや主題専門家と協力して、全体的な動作と主要なサブコンポーネントの両方を評価するより包括的なテストスイートを構築する必要があります。

私たちのコパイロット(copilot)については、LangSmithのデータセット機能を使用して、自然言語の質問とその正しい回答をペアにしたグラウンドトゥルース(ground truth)データセットを手動で作成します。また、私たちのデータベースの文脈において、適切で高性能なSQLがどのようなものかの例を含むデータセットも作成します。開発者がエージェントを構築する際には、LangSmithの評価(evaluations)機能を使用して、それらのデータセットに対してテストを実行します。LangSmithのUIにより、技術系と非技術系のチームメンバーが評価結果をレビューし、注釈(annotate)を付けることができ、全員が開発者の次のステップについて合意できるようになります。

このフェーズでは、手動テスト中に遭遇した興味深いケースから着想を得た例で初期データセットを拡張することで、ミニ・フライホイール(flywheel)を作成できます。これにより、フィードバックループの自動化を段階的に進め、エージェントのバージョン1(v1)を出荷する準備が整う頃には包括的なテストスイート(test suite)を確実に持つことができます。

imageimage私たちのエージェントの出力をグラウンドトゥルース(ground truth)データセットと比較しています - ここではかなり良い結果を示していますが、まだ改善の余地があります。

デプロイ後: 自動評価とモニタリングを使用して、人間の注目を最も必要とする場所に向ける

エージェントが稼働したら、その信頼性を確保し、問題や改善の機会を迅速に特定する必要があります。ユーザーエクスペリエンスを検証する従来の方法は、満足度調査とユーザーインタビューですが、このアプローチの欠点は、ユーザーが実際に行うことではなく、ユーザーがあなたに伝えることを測定することです。LLM-as-a-judge(LLMを裁判官として)評価システムは、はるかに堅牢な方法を提供します。本番(production)データで実行される自動評価(automated evaluations)は、エージェントを監視し、人間の注目を必要とする状況を浮き彫りにするのに役立ちます。例えば、LLM裁判官(LLM judge)は、ユーザーが不満を表明したときに自動的に検出し、それらのやり取りをレビュー対象としてフラグを立てることができます。その後、チームメンバーがトレース(trace)を調査し、問題がバグ、エージェントの知識のギャップ、またはワークフローの弱点のいずれを反映しているかを判断できます。

デモトレーダーアプリをチェックして、注釈キュー(annotation queues)を設定してください。

imageimageLangSmithでLLM-as-a-judge(LLMを裁判官として)オンライン評価システム(online evaluator)を作成し、ユーザーが不満を表明したメッセージを検出しています。

私たちの仮想企業は、まずLangSmithトレーシング(tracing)を設定して、エージェントとトレーダー間のすべてのやり取りをキャプチャします。次に、以下のためにLangSmithのオートメーション(automations)機能を設定します:

オンライン評価(Online evaluations): 観測可能性(observability)データが入ってくる際に評価システムを実行するようLangSmithを設定します。例えば、遅いまたは危険なSQLクエリに対する自動コードチェックと、コパイロット(copilot)が提供する回答にユーザーが満足を表明しているかどうかを確認するLLM-as-a-judge(LLMを裁判官として)評価システムによる会話のレビューが必要になります。

アラート(Alerts): エラー、レイテンシ(latency)、または否定的なオンライン評価スコアの急増を検知した場合、LangSmithは既存のアラートシステムをトリガーし、チームが根本的な問題を迅速に修正できるようにします。

注釈キュー(Annotation queues): 注目すべきトレース(traces)にフラグを立ててLangSmithの注釈キュー(annotation queue)に送信し、人間によるレビューを行います。キューでは、主題専門家(subject matter experts)が、オンライン評価システム(online evaluator)が非常に否定的なフィードバックスコアを返したケースをレビューし、エージェントに何か問題があることを示します。境界線上のフィードバックスコアは、評価システム自体を調整する必要があることを示唆します。LangSmithは注釈キューを通じて提出されたフィードバックを保存するため、将来の自動および手動分析に利用できます。

imageimageLangSmithのダッシュボード(dashboards)は、エージェントに関する集計されたメトリクス(aggregated metrics)を表示し、チームが期待通りに継続して動作していることを確認できるようにします。

インサイトエージェント(Insights Agent): トレーシングデータから価値を引き出すもう一つの方法

ライブ動作の非構造化探索は、AIエージェントにとって最も価値のある改善の一部を生み出します。これをサポートするため、LangSmithはインサイトエージェント(Insights Agent)を提供します。これは、最小限のユーザー設定で大量のトレーシングデータを分析する組み込みのAIエージェントです。個々のトレース(traces)や決定論的評価(deterministic evaluations)からは明らかにならない、エージェントの動作におけるパターンや傾向を浮き彫りにします。最終的には人間のステークホルダー(stakeholders)がインサイトレポート(insights report)をレビューして次のステップについて合意する必要がありますが、この機能はプロセスを迅速に開始します。

私たちのトレーディングコパイロット(trading copilot)の場合、類似の会話を自動的に識別し、ユースケースカテゴリにクラスタリング(clustering)するインサイトレポート(insights report)を実行するかもしれません。トレーダーがコパイロットに尋ねる質問の背後にある基本的なテーマを把握することで、特に確実にサポートすべきユースケースや、それらのユースケースに対してトレーダーにより良いサービスを提供する将来の製品追加を特定するのに役立ちます。

自動評価(automated evaluations)、人間による注釈(human annotations)、集計レベルのインサイト(aggregate-level insights)が蓄積されるにつれて、エージェントが実世界でどのように動作するかの明確な全体像が提供されます。これらの学びは、エージェントの次のバージョンを構築することで反復ループ(iteration loop)を再開するというサイクルの最終ステップにフィードバックされます。

imageimageLangSmithインサイトエージェント(Insights Agent)は、データ内の隠れたパターンを浮き彫りにするレポートを生成します。

継続的な洗練: 今日の本番データを明日のテストスイートに変える

エージェントの最初のバージョンを構築するとき、評価スイート(evaluation suite)は、それが動作することを検証するために必要なテストについて、せいぜい推測に基づいたものです。ローンチ後、はるかに優れたテストケースの源、つまり実際の本番(production)データにアクセスできるようになります。

このデータを、包括的であるが不必要に大きくないテストスイート(test suites)に精選(curate)する必要があります。自動システムは、例えば、評価システムの結果に基づいて本番トレース(production traces)をフィルタリングすることで、候補データセットを生成するのに役立ちます。しかし、バランスの取れた代表的な評価セット(evaluation sets)を精選するには、しばしば人間の判断が必要です。注意深く選択された数百の例だけで実行される評価も有用であり得るため、どの例がテストスイートを定義すべきかを決定する際に専門家を関与させる価値があります。

私たちの仮想トレーディング企業がコパイロット(copilot)を本番環境でしばらく実行した後、チームは実際のSQLクエリとチャットボットの会話、およびモニタリングと精選された注釈キュー(curated annotation queues)を通じて収集されたオンライン評価システムの結果と人間の意見にアクセスできるようになります。

私たちのチームは、レビュー済みのトレース(traces)からデータセットを作成し、より堅牢な評価スイート(suite of evaluations)を実行することで、バージョン2(v2)以降のエージェントのパフォーマンスを大幅に改善できます。私たちが精選できる最も有用なデータセットの一つは、「ゴールデンデータセット(golden dataset)」であり、これまでのコパイロットの最高の成果の例で構成され、将来のバージョンが少なくとも同様に動作することを保証するためのベースライン(baseline)として使用できます。LangSmithはこれを簡単にまとめることを可能にします。オンライン評価システムスコア(online evaluator scores)を使用して候補トレース(candidate traces)を特定し、それらを注釈キュー(annotation queue)に入れて、主題専門家(subject matter experts)が実際にゴールデンデータセットに属するものを決定できるようにします。

imageimageLangSmithの注釈キュー(annotation queue)を使用して、LLM裁判官(LLM judge)が高品質とマークしたチャットボットからのトレース(traces)をレビューし、それらが本当に私たちのゴールデンデータセットに属するかどうかを決定しています。

結論

効果的なエージェント開発は、人間の判断と自動評価の拡張性を組み合わせます。人間の専門知識は、ワークフロー、ツール、コンテキスト、評価基準を形成することで、「良い」状態がどのように見えるかを定義するのに役立ちます。自動評価システム(automated evaluators)は、その判断を大規模に適用し、チームがエージェントを迅速にテストし、本番環境での動作を監視し、人間の注目を最も重要なケースに向けるのを支援します。

時間の経過とともに、これはフライホイール(flywheel)を生み出します。人間のフィードバックは評価システム、テストスイート、およびエージェント自体を改善し、私たちがデプロイする改善されたエージェントは、それを改善する方法を教えてくれるより多くのデータをもたらし、これらのインサイトが次の開発イテレーション(development iteration)を推進します。

私たちはこのプロセスを説明するために単純なユースケースを使用しましたが、同じ原則はあらゆるエージェントの構築に適用されます: 緊密な反復ループ(iteration loops)を構築し、拡張可能な評価に専門家の判断を組み込み、継続的に本番データをより良いテストに変えます。これは、あなたのビジネスに意味のある価値を生み出すAIエージェントを作成するための鍵です。

原文を表示

imageimageBy Rahul Verma, Deployed Engineer @ LangChain

AI agents work best when they reflect the knowledge and judgment your team has built over time. Some of that is institutional knowledge that’s already documented and easy for an agent to use as-is. But most great organizations also rely on tacit knowledge that lives inside their employees’ minds. Teams often don’t realize how critical that information is to perform meaningful work until they try building AI agents to automate it. Ensuring this wisdom makes its way into an agent requires an improvement loop that incorporates input from domain experts.

In this guide, we’ll cover:

Which components of your agent will benefit from absorbing human judgment

How to incorporate human judgment into your agent at each step of the development lifecycle

Real-life inspired example: Copilot for traders

Imagine a financial services firm whose traders need up-to-date market data. Today, they send their questions to the data science team. A data scientist writes a SQL query, retrieves the relevant data, and sends the result back. Because LLMs are strong at generating SQL, this workflow is a natural candidate to automate with an AI agent: traders get faster responses while the data scientists are free to work on more interesting projects.

For this system to work reliably, the agent needs context at both the financial services domain level and the technical database layer. The former includes unwritten trading conventions that determine how to interpret requests like “today’s exposure” or “recent volatility.” The latter includes practical knowledge of the database, like which tables are authoritative vs. outdated, or which query patterns tend to be incorrect or inefficient. We’ll need to engage with the appropriate subject-matter experts to include all the unwritten context the agent needs.

We’ll use this example throughout the guide to give concrete implementation examples. It’s a good example because the architecture is simple, and it showcases principles critical for involving human judgement in agent design.

Let’s review the different components of the agent that can be improved with human judgment.

How human input improves each component of an AI agent

Building an agent means deciding when to invoke an LLM and managing what context to provide with each call (e.g., documentation, memory, conversation history, tools) to achieve the desired result. Each of these design choices benefits from input from the right stakeholders.

Workflow Design

LLMs today are great at sequencing their own actions. Just give them some tools and natural language instructions, and they’ll figure out which tools to call in what order. However, there are benefits to using deterministic code to define parts of the workflow: lower latency, fewer tokens, and the guarantee that critical steps actually run. In some regulatory or high-risk settings, you need code to strictly control the sequence of actions. In our trader copilot, we’ll let the LLM autonomously generate and execute a SQL query, but add code that requires it to validate the final answer meets our firm’s risk and compliance requirements before returning it to the trader. We’ll need input from risk and compliance experts to create automated checks that enforce the firm’s standards. We can also include that information in the agent’s pre-loaded context to improve its odds of creating a valid answer on the first try.

Tool Design

Developers must implement the tools the agent can use and configure the names, parameters, and descriptions that the LLM relies on to decide when to invoke them. It’s often useful to vary the available tools at different stages of the workflow. Limiting the tool set for a single LLM call can guide the model toward the intended behavior and reduce the chance that it selects an irrelevant option.

Our copilot’s tools might include database schema inspection, query execution, and database documentation retrieval. A key tradeoff is flexibility vs. control for LLM-generated queries: a general execute_sql step allows for flexible queries but increases risk; parameterized query tools are safer but less capable. A close review of your business constraints might give you a sense of which option is right for you, but to know for sure, you’ll need to run evaluations to determine the performance and risk characteristics of your tool design and ship only when all stakeholders are comfortable with the results.

Agent Context

Early agents just gave the model a single system prompt and a set of tool definitions. Over time, the industry has moved toward providing agents with much richer context at the beginning of their execution. Anthropic’s Skills, a standard that has quickly grown in popularity since launching in October, is one prominent example of this trend.

Instead of cramming everything into one system prompt, your team curates documentation, examples, and domain rules in advance, then lets the agent fetch what it needs at runtime. This lets the agent use far more knowledge without bloating the system prompt. Effective agent design involves deciding what knowledge the agent should access and organizing it so the agent can retrieve the right information at the right moment.

At minimum, our trader copilot needs to know how to use the database and understand its schema. Depending on the nature and amount of additional knowledge from our team that our copilot needs, we’ll have to spend time not just collecting that knowledge but determining how to structure and progressively disclose it to our agent.

Choosing and structuring the information available to the agent when it starts up is part of the discipline of context engineering. Context engineering also covers how the information you provide in each LLM call evolves as the agent moves through its task. The feedback your human stakeholders provide when reviewing your agent’s outputs and evaluation scores may influence how you approach end-to-end context engineering for your agent.

Now that we have outlined the parts of an agent that benefit from human judgment, we’ll cover how to collect that human input.

Incorporating human judgment into the agent improvement loop

At LangChain, we’ve worked with hundreds of organizations deploying AI agents. The most successful teams follow a tight iteration loop: they quickly build an agent, deploy it to a production or production-like environment, and collect data at each step to guide improvements. We call this the “agent improvement loop” because we’ve observed that most successful agents have gone through this loop multiple times, and have covered it in greater detail before here.

Iterating quickly and frequently is critical because it is the LLM’s real-time reasoning, not code, that determines the agent’s behavior. It’s impossible to know what an AI agent will do until it runs. AI agent interfaces are often free-form, e.g. a text box the user can type anything into, making it even harder to predict what interactions between your users and your agent will look like. Putting your agent in front of users is the only way to collect the data you need to make it ultimately successful.

imageimageWe’ll walk through the following phases of the flywheel while discussing how to incorporate human input effectively:

Implementing the agent’s first version

Monitoring the agent after it goes live and collecting production data to help refine it

Implementing and testing improved versions of the agent

Before we dive in, it’s worth highlighting a principle that applies across the entire development lifecycle.

The key to high return on human time invested: automated evaluations, aligned with human judgment

We’ve observed that teams get more leverage when humans help design and calibrate automated evaluators, rather than manually reviewing large volumes of agent outputs. No matter how big or well-resourced your team is, it’s rarely economical to rely on extensive manual review. The scalable approach is to translate expert judgment into automated evaluations that let you test broadly and continuously. That’s what LangSmith’s Align Evaluator feature helps with. It provides a user interface for calibrating LLM-as-a-judge evaluators using curated examples and feedback from subject matter experts. We recommend using this feature for any evaluator that’s meant to mimic a non-developer stakeholder’s judgments.

imageimageUsing LangSmith’s Align Evaluator feature to validate an LLM-as-a-judge professionalism evaluator. The evaluator is currently stricter than our human judge so we need to alter the system prompt to make it more lenient. Let’s follow the trader copilot from the perspective of our hypothetical trading firm through each phase of the improvement loop. We’ll look at how to incorporate human input effectively, and in particular, how to channel that input into automated evaluations.

Development: Curate test suites and evaluators

Before development starts, engineers should have at least a small set of use case scenarios and expected behavior as part of the project requirements. These initial tests help confirm that the agent performs the core tasks correctly. As the agent approaches production readiness, engineers should work with product managers and subject matter experts to build a more comprehensive test suite that evaluates both overall behavior and key subcomponents.

For our copilot, we’ll use LangSmith’s datasets feature to manually create some ground truth datasets pairing natural language questions and their correct answers. We’ll also create datasets containing examples of what good, performant SQL looks like in the context of our database. As our developers build the agent, we’ll use LangSmith’s evaluations feature to run tests against those datasets. The LangSmith UI lets our technical and nontechnical team members review evaluation results and annotate them so everyone can align on the developers’ next steps.

We can create a mini-flywheel during this phase by augmenting our initial datasets with examples inspired by interesting cases we encounter during manual testing. This helps progressively automate our feedback loop and ensure we have a comprehensive test suite by the time we’re ready to ship our agent’s v1.

imageimageComparing our agent’s outputs against a ground truth dataset - it’s doing pretty well here but still has some room to improve. After deployment: Use automated evaluations and monitoring to direct human attention to where it’s most needed

Once your agent is live, you'll need to ensure its reliability and quickly identify problems or opportunities for improvement. The traditional way of validating user experience is satisfaction surveys and user interviews, but the flaw with that approach is it measures what users tell you, not what they actually do. LLM-as-a-judge evaluators give us a much more robust method. Automated evaluations running on production data can help monitor the agent and surface situations that warrant human attention. For example, an LLM judge can automatically detect when a user expresses frustration and flag those interactions for review. A team member can then investigate the trace and decide whether the issue reflects a bug, a gap in the agent’s knowledge, or a weakness in the workflow.

0:00

/6:01

1×

Check out the demo trader app and set up annotation queues.

imageimageCreating an LLM-as-a-judge online evaluator in LangSmith to detect messages where the user expressed frustration.Our hypothetical firm will first set up LangSmith tracing to capture all of the agent’s interactions with our traders. We’ll next set up LangSmith’s automations feature for:

Online evaluations: Configure LangSmith to run evaluators on the observability data as it comes in. For example, we’ll want automated code checks for slow or dangerous SQL queries as well as LLM-as-a-judge evaluators reviewing conversations to see if users are expressing satisfaction with the answers the copilot is giving them.

Alerts: LangSmith will trigger our preexisting alerting system when it sees spikes in errors, latency, or negative online evaluation scores so our team can quickly fix the underlying problem

Annotation queues: We’ll flag notable traces for human review by sending them to a LangSmith annotation queue. In the queue, we’ll have subject matter experts review cases where an online evaluator returned a very negative feedback score, indicating something is wrong with the agent. A borderline feedback score would suggest that we need to adjust the evaluator itself. LangSmith saves the feedback submitted through annotation queues so it’s available for future automated and manual analysis.

imageimageLangSmith’s dashboards show you aggregated metrics about your agent so your team can verify it continues to perform as expected.Insights Agent: Another way to get value from the tracing data

Unstructured explorations of live behavior inspire some of the most valuable improvements for AI agents. To support this, LangSmith provides Insights Agent, a built-in AI agent that analyzes large volumes of tracing data with minimal user configuration. It surfaces patterns and trends in agent behavior that wouldn’t be obvious from individual traces or deterministic evaluations. You’ll still ultimately have your human stakeholders review the insights report to align on next steps, but the feature jump-starts the process.

For our trading copilot, we might run an insights report automatically identifying similar conversations and clustering them into use case categories. Having a sense of the underlying themes behind the questions the traders ask the copilot can help us identify use cases we should be extra sure to support well or even future product additions that would serve our traders even better for those use cases.

As automated evaluations, human annotations, and aggregate-level insights accumulate, they provide a clear picture of how the agent performs in the real world. Those learnings feed into the final step of the cycle: restarting the iteration loop by building the agent’s next version.

imageimageLangSmith Insights Agent generates reports that surface hidden patterns in your data.Continuous refinement: turn today’s production data into tomorrow’s test suites

When you build the first version of an agent, your evaluation suite is at best educated guesses on what tests you need to validate that it works. After launch, you gain access to a much better source of test cases: real production data.

You need to curate this data into test suites that are comprehensive but not unnecessarily large. Automated systems can help generate candidate datasets, for example, by filtering production traces based on evaluator results. But we often need human judgment to curate balanced, representative evaluation sets. Evaluations can be useful running on just a few hundred examples if they’re chosen carefully, so it’s worthwhile to involve experts in deciding which examples should define the test suite.

Once our trading firm has had its copilot running in production for a while, the team will have access to real SQL queries and chatbot conversations, along with the online evaluator results and human opinions collected via monitoring and curated annotation queues.

Our team can create datasets out of the reviewed traces to run a more robust suite of evaluations, resulting in huge improvements in our agent’s performance for v2 and beyond. One of the most helpful datasets we can curate is a “golden dataset,” consisting of examples of the copilot’s best work so far, so we can use it as a baseline to ensure future versions perform at least as well. LangSmith makes this easy to put together. Use the online evaluator scores to identify candidate traces, then put them in an annotation queue so our subject matter experts can decide which ones actually belong in the golden dataset.

imageimageUsing a LangSmith annotation queue to review traces from our chatbot that the LLM judge marked as high quality to decide if they truly belong in our golden dataset. Conclusion

Effective agent development combines human judgment with the scalability of automated evaluations. Human expertise helps define what “good” looks like by shaping workflows, tools, context, and evaluation criteria. Automated evaluators apply that judgment at scale, helping teams test agents quickly, monitor their behavior in production, and direct human attention to the cases that matter most.

Over time, this creates a flywheel. Human feedback improves evaluators, test suites, and the agent itself, the improved agent we deploy gets us more data that tells us how to improve it, and these insights drive the next development iteration.

We used a simple use case to illustrate this process, but the same principles apply to building any agent: Build tight iteration loops, capture expert judgment in scalable evaluations, and continuously turn production data into better tests. This is the key to creating AI agents that create meaningful value for your business.

この記事をシェア

関連記事

LangChain Blog★32026年4月23日 23:02

本番環境におけるディープエージェントのランタイム基盤

長期動作するエージェントの本番デプロイには専用インフラが必要である。本ガイドは、耐久性のある実行、メモリ管理、人間による監督(HITL)、観測可能性について解説し、「deepagents」がこれらを本番環境に展開する方法を示す。

The Register AI/ML★42026年4月28日 01:20

AIの現実検証:3社がウォレット、住宅、ゲーム構築で学んだこと

シティ、ホームデポ、カプコンの経営陣は、AIエージェントが実験ツールから顧客対応業務へ移行する過程で得た知見を語った。次なる課題は、金銭や創造的出力に関わる際のガバナンスと信頼性の確保である。

The Decoder★42026年4月25日 19:18

アンストロピック「強力なAIモデルはより良い取引を実現し、劣るモデルを使う利用者は気づかない」

アンストロピックは社内市場で69のAIエージェントに取引をさせ、強力なモデルがより良い結果を出した。利用者は劣るモデルの差に気づかず、AIの実取引化は経済格差を拡大させる可能性がある。

ニュース一覧に戻る元記事を読む