終わる条件がなければ製品ではない

一言でいうと

終わる条件がないエージェントは、製品ではありません。そして、その条件は、モデルではなく人間が決めます。

なぜ必要なのか: 再帰の上限は安全装置であって、設計ではない

LangGraphにはrecursion_limitがあります。その数を超えると、例外を投げます。それに頼った途端、2つのことがついてきます。ユーザーはエラーを見て、それまでに使ったコストはそのまま請求されます。

上限はバグを捕まえる網であって、止める方法ではありません。止める方法は、グラフの中にある必要があります。

止まる条件は3つ

実務で使う組み合わせは、たいていこの3つです。

条件	いつ	置かないと
成功	望むものを得た	答えを得ても回り続ける
回数の上限	N回やってみた	永遠にリトライし続ける
断念経路	上限に達した	例外で死ぬか、でっち上げる

3つ目が最もよく抜けます。上限だけを置いて、その先を決めないと、上限に達した瞬間に行き場がなく、例外が出ます。断念することも経路です。

def after_lookup(state):
    if state.get("answer"):
        return END                      # 성공
    if state.get("tries", 0) < MAX_TRIES:
        return "lookup"                 # 다시
    return "fallback"                   # 포기 — 이 줄이 자주 빠진다

わからないときはでっち上げない

断念経路の役割は、止めることだけではありません。わからないと言うことです。

照会が何も見つけられずに戻ってきたのに、モデルに「答えて」と渡すと、モデルは答えを作り出します。それがハルシネーションの最もよくある経路で、原因はモデルではなく、何も見つからなかった結果をそのまま渡したグラフです。

現場では

トークンのコストが予想の数倍になったという報告を受けたら、見る場所は決まっています。ループを回る経路とその上限です。ログに経路が残っていないと、それさえ確認できず、結局すべてを作り直すことになります。上限と記録は、一緒です。