FSM и JSON: один из подходов к описанию логики

Синтаксис — это закон. Семантика — это понимание. Вместе они — архитектура.
Синтаксис — это закон. Семантика — это понимание. Вместе они — архитектура.

Заметки о том, как можно структурировать взаимодействие с LLM

Введение

При работе с LLM важно структурировать информацию. JSON — распространённый формат для этого. Он позволяет задать логику, состояния и переходы в виде, который модель может интерпретировать.

Это не единственный способ. Но он показывает, что поведение модели можно описывать на языке, который она понимает как спецификацию.

Как это может выглядеть

Вместо длинного текста можно использовать структуру:

· состояние, в котором находится диалог

· условия перехода к следующему шагу

· запреты и правила

· формат ожидаемого результата

Пример условный (не для копирования):

{ "state": "ожидание ввода", "transition": { "condition": "ввод получен", "target": "обработка" } }

Это не код. Это описание логики, которое модель может интерпретировать как инструкцию к действию.

О FSM

Конечный автомат обычно реализуется кодом. Это надёжно, предсказуемо и детерминированно.

В подходе с JSON модель сама отслеживает состояние и переходы, интерпретируя структуру. Это не замена коду, а иной способ организации логики — там, где гибкость важнее жёсткости.

Ограничения

Любой подход имеет свои границы.

Для систем, где важна абсолютная детерминированность, традиционное программирование остаётся стандартом.

Здесь же возможны ситуации, когда интерпретация модели может отличаться от замысла автора. Это требует дополнительных проверок.

Возможности использования

В некоторых сценариях структурированное описание логики может быть удобнее кода:

· быстрая смена поведения без пересборки

· адаптация под контекст

· хранение состояний и переходов в легко изменяемой форме

Но это не универсальное решение. Это один из инструментов.

Заключение

FSM — один из способов организации логики. JSON — один из форматов данных. Их сочетание может быть полезно в определённых случаях.

Вопрос не в том, что «лучше». Вопрос в том, что подходит под конкретную задачу.

P.S.

Описанный подход предполагает, что система всегда может интерпретировать входные данные через заданную структуру. Это не означает, что интерпретация всегда будет правильной. Это означает, что у неё нет состояния «я не знаю». Есть только варианты интерпретации. И это требует особого внимания к формулировке принципов, а не только правил.