LLM コードをより安定して記述する方法は、最初に DSL を記述することです

しばらく前、私は同じ状況を繰り返し見ました。要件をモデルに直接スローすると、生成速度が非常に速く、リワークも高速です。まず要件を DSL の層に入れ、次にモデルにセマンティック モデルのこの層の実装を記述させると、出力は明らかに安定しています。変化は非常に直接的です。重要なのは、モデルを記述できるかどうかではなく、オプションのスペースが最初に閉じられているかどうかです。

自然言語は方向を伝えるのには適していますが、暗黙の決定をあまりにも多く伝えるのには適していません。一見単純な要件は、実装されると多くの小さな判断に分割されます。状態に名前を付ける方法、失敗を完了と見なすかどうか、再試行回数、タイム ウィンドウが誰のタイム ゾーンに基づくか、ログがどのレイヤーに書き込まれるかなどです。これらの判断が生成プロセスにまだ隠されている限り、モデルは詳細を埋めると同時に境界を変更します。最終的に書いたものは実行できますが、レビューするのは困難です。

自然言語は問題について話す場合にのみ適しています

LLM は、曖昧な説明を完全なテキストに発展させることに非常に優れており、意図を読みやすい草稿に完成させることにも非常に優れています。苦手なのは、長期にわたって安定した名前付けと一連のビジネス ルールの制約です。要件にステート フロー、異常な分岐、時間境界、およびパーミッション境界が含まれると、これらの言葉は頭の中では明確に見えますが、実際にコードに組み込むときには最終的に決定されないことがよくあります。モデルは多数の未解決の問題に直面しており、それに応じて出力も当然変動します。

長いプロンプトワードは、書けば書くほど疲れてしまうことが多いのはこのためです。プロンプト単語が長くなり続けた後も、モデルはフリー テキストを取得しますが、フリー テキストはさらに長くなります。境界をさらに取得することなく、より多くのコンテキストを記憶します。境界が閉じていない場合、モデルは推測を続けることしかできません。

DSL は暗黙的な判断を明示的な入力に変換します

入力を DSL に変更すると、状況が変わります。このモデルは、カジュアルな文に基づいてビジネスを推測するのではなく、明確な意味モデルに基づいて空白を埋めます。テスト シナリオ、リリース プロセス、およびグラフィカルな説明の場合、最初にノードと関係が DSL によって定義され、次にテキスト、コード、およびチャートがモデルによって補足されます。結果は、同じシステムから成長したものに似たものになります。

scenario: payment_timeout
steps:
  - send: order.created
  - wait: 3s
  - if: payment_missing
    then: cancel_order
    audit: required

このタイプの定義の最大の価値は、作成時に見栄えが良いということではなく、バージョン管理、比較、およびレビューができることです。コード生成、ドキュメント、テスト、図はすべて同じセマンティック モデルから拡張できます。ここでのモデルは発明者というよりもアクチュエーターに似ています。確立された境界を強制する責任はありますが、その場で境界を書き換える責任はありません。

この境界線が確立されると、長い間騒がしかったはずの多くのものが静かになります。テストでは何をカバーする必要があるのか​​、失敗が予想されるのか、ロールバック条件の最終決定権は誰にあるのか?これらはもはや自然言語でその場で説明されるのではなく、実行可能な構造に書き込まれます。人間が注目するのはセマンティクスであり、マシンが実行するのはセマンティクスであり、トラブルシューティングのときに立ち戻るのは同じセマンティクスです。

LLM は DSL の成長に参加するのに適しています

LLM は、DSL の外部で実行する必要があるだけではありません。より適切な使用法は、最初に DSL の成長に参加させることです。いくつかの実際のシナリオをそれにフィードし、境界単語、列挙値、異常な分岐、反例を完成させてから、人々がそれを停止できるようにします。 DSL が完成すると、その後モデルに引き渡されるのは、無制限の自然言語ではなく、制約された入力になります。

この段階では、LLM が非常に役立ちます。これは、散在するステートメントを一連の用語に整理するのに役立ち、また、ドラフト段階で名前の不一致、ステータスのギャップ、異常なパスの欠落などの問題を特定することもできます。セマンティック モデルが安定すると、モデルは実装、概略図、およびテスト サンプルを生成します。出力はトラック上を走るようなものになり、毎回他の場所に向かうわけではありません。

DSL の背後に LLM を置くことを希望します。最初に境界を明確にし、後で境界を埋めるのに役立ちます。これにより、システムが何度も即興で演奏することで簡単に気を散らすことがなくなります。

セマンティック層も扱いにくくなる

DSL を増やすことが必ずしも良いとは限りません。現場が依然として劇的に変化している場合、時期尚早に固まってしまうと間違った仮定が固定されてしまいます。セマンティック層が汎用的に設計されすぎると、別の重いフレームワークになってしまいます。真に費用対効果の高いシナリオは、通常、同じ種類のアクションが繰り返し発生し、レビューのコストが高く、動作が追跡可能である必要がある場合です。現時点では、DSL はもはや追加の負担ではなく、むしろ安定した入り口への分散した判断の集合体です。

したがって、より現実的な判断は、「LLM に DSL を搭載できるか」ということではありません。しかし、「まずこの問題のセマンティクスを修正する必要がありますか?」答えが「はい」になると、キューワードには全責任が負わなくなります。プロンプトは意図を説明する責任を負い、DSL は制約を伝達する責任を負い、モデルは制約を実行可能な結果に変換する責任を負います。このように書かれたものは、即興演奏の連続というよりもむしろエンジニアリング システムに似ています。