Метод не обещает универсального рецепта. Он даёт критерии, по которым видно, где ещё работают жёсткие правила, а где процесс уже упирается в исключения и требует модели распознавания, классификации или извлечения смысла.
Сначала описывают текущий сценарий: какие операции идут по правилам, какие данные поступают на вход, какие форматы встречаются. Так становится видно, где автоматизация уже справляется, а где появляются неоднородные документы и письма свободного формата.
Отдельно фиксируют места, в которых жёсткая логика перестаёт срабатывать: решения зависят от контекста, формулировки не совпадают, структура документа каждый раз своя. Именно эти точки определяют, нужна ли модель и какая именно.
Заранее описывают, как измеряется точность, полнота и стабильность результата. Без этого невозможно понять, стало ли лучше после изменений, и с чем сравнивать работу модели на реальных примерах.
Отдельный шаг — что происходит, когда модель не уверена. Кто принимает решение, как фиксируется результат, куда попадает спорный случай. Исключения не прячут, а описывают как часть процесса.
Метод помогает сформулировать задачу так, чтобы её можно было оценить: что подаём на вход, что считаем корректным ответом, по каким признакам поймём, что решение работает. Это снижает риск переделок на середине.
Правила, журналирование и понятные формулировки для пользователей делают автоматические решения объяснимыми. Люди видят, где заканчивается система и подключается человек, и меньше сопротивляются изменениям.
Если хотите сверить метод со своим процессом — посмотрите решения или напишите нам через страницу контактов.
Если после разбора этапов остались неясные места — например, непонятно, где именно в вашем сценарии правила перестают работать или как фиксировать решения при неуверенности модели, — напишите нам. Опишите процесс своими словами: какие операции идут по правилам, какие документы или письма приходят на вход, где чаще всего возникают исключения. Этого достаточно, чтобы обсудить предметно.
Прежде чем писать, полезно заглянуть в раздел с частыми вопросами — там собраны уточнения по границам между классическими сценариями и моделями, по метрикам качества и по работе с исключениями. Многие формулировки уже разобраны, и это экономит первый круг переписки.
Метод строится на разборе конкретного процесса, а не на выборе инструмента заранее. Сначала смотрим, что уже работает по правилам, потом ищем места, где правила ломаются, и только затем решаем, нужна ли модель распознавания, классификации или извлечения смысла.
Фиксируем, какие операции выполняются по жёстким правилам, какие данные поступают на вход и какие форматы встречаются на практике. Это даёт опорную точку: понятно, что уже автоматизировано, а что держится на ручной работе.
Отмечаем неоднородные документы, письма свободного формата и решения, зависящие от контекста. Именно здесь классический сценарий упирается в исключения, и именно на них уходит основное время специалистов.
Для каждой такой точки отдельно определяем, что требуется: распознавание, классификация или извлечение смысла. Не бывает одной модели на весь процесс — задачи различаются по входу и по тому, какой результат считается корректным.
До запуска описываем, как измеряется точность, полнота и стабильность результата. Без этого нельзя понять, стало ли лучше, и нельзя сравнивать варианты между собой на одних и тех же данных.
Отдельно разбираем, кто принимает решение, когда модель не уверена, и как фиксируется результат. Исключения не исчезают с ростом автоматизации — меняется только то, кто и на каком основании их разбирает.
Метод не обещает универсального решения. Он даёт набор критериев для постановки задач и оценки качества, чтобы команда могла сама решить, где достаточно сценария, а где нужна модель.
Метод опирается на последовательность шагов. Сначала описывают текущий сценарий: какие операции выполняются по правилам, какие данные поступают на вход, какие форматы встречаются. Затем фиксируют точки, где правила перестают срабатывать, и решают, нужна ли модель распознавания, классификации или извлечения смысла. Ниже — те же шаги в том порядке, в котором они обычно идут.
Разбираем, какие операции уже выполняются по правилам, какие данные приходят на вход и какие форматы встречаются на практике. На этом шаге важно не улучшать процесс, а честно зафиксировать, как он устроен сейчас: где заканчивается предсказуемая часть и начинается ручная работа с неоднородными документами и письмами свободного формата.
Отдельно выписываем случаи, в которых жёсткая логика даёт сбой: разные шаблоны одного и того же документа, свободные формулировки, решения, зависящие от контекста. Именно эти точки определяют, где классического сценария уже недостаточно и стоит рассматривать модели.
Для каждой проблемной точки решаем, что именно требуется: распознавание, классификация или извлечение смысла. Формулировка задачи на этом шаге важнее выбора инструмента — от неё зависит, как потом измерять результат и где расставлять проверки.
Описываем, как измеряется точность, полнота и стабильность результата, и на каких примерах эти метрики считаются. Без зафиксированных метрик невозможно понять, стало ли лучше после изменений, поэтому этот шаг идёт до, а не после запуска.
Отдельно проговариваем, кто принимает решение, когда модель не уверена, как фиксируется результат и что видит пользователь в спорной ситуации. Исключения — не сбой, а часть процесса, и их стоит описать заранее, а не по факту.
После первых прогонов возвращаемся к описанию сценария и метрикам: что подтвердилось, что пришлось переформулировать, какие точки оказались сложнее, чем казалось. Метод не обещает универсального рецепта — он даёт критерии, по которым задачу можно поставить и оценить.