Каждый день бухгалтер тратит часы на однотипные операции: распознавание первичных документов, сверку с контрагентами, проверку дебиторской задолженности. Искусственный интеллект способен взять на себя часть этой рутины, но идея о полной замене бухгалтера роботом пока остается мифом. В этой статье поговорим о том, в каких процессах ИИ уже применим, где его использование невозможно, какие риски и экономия для бизнеса.
Где технология может помочь бухгалтеру
1. Обработка первичных документов
Как работает: ИИ анализирует фотографию или скан накладной, акта, счета-фактуры, распознает реквизиты, сверяет сумму и контрагента и автоматически разносит документ в учетную систему. Бухгалтеру остается только проконтролировать результат, можно делать это в формате выборочной проверки.
Для кого подходит: для компаний с большим потоком первички – везде, где много повторяющихся документов.
2. Расчет заработной платы
Как работает: ИИ на основе загруженных табелей и фиксированных ставок автоматически рассчитывает оклады, премии и удержания. Стоит учитывать: как только появляются нюансы (например, сдельная оплата, ночные смены, совместительство), точность ИИ резко падает.
Для кого подходит: для компаний со стандартной схемой оплаты труда, без сложных коэффициентов, районных надбавок, сменных графиков и индивидуальных договоренностей.
3. Акты сверки с контрагентами
Как работает: ИИ по запросу (или автоматически в заданную дату) формирует акт сверки, используя данные учетной системы.
Для кого подходит: применимо как для крупных, так и для небольших компаний.
4. Контроль дебиторской и кредиторской задолженности
Как работает: на основе заданных алгоритмов ИИ подсвечивает просроченную задолженность, автоматически формирует и отправляет письма-напоминания контрагентам. Такой подход снижает риск пропуска сроков оплаты, ускоряет оборачиваемость денег и разгружает бухгалтера от «ручных» обзвонов.
Для кого подходит: универсально – и для малого бизнеса, и для более крупных компаний.
5. Анализ счетов для взаимозачетов
Как работает: ИИ анализирует счета 60, 62, 76 и другие, находит встречные требования и автоматически формирует предложение о взаимозачете. Это позволяет сократить излишние платежи и ускорить закрытие обязательств без участия бухгалтера.
Для кого подходит: любые компании, где есть регулярные встречные поставки или услуги.
Какие бухгалтерские задачи не нужно делегировать ИИ
- Составление бухгалтерской и налоговой отчетности. Это требует не только точных цифр, но и понимания контекста, изменений законодательства, учетной политики компании. Ошибка в расчете налога, и штраф обеспечен. ИИ неспособен взять на себя ответственность за подпись под декларацией.
- Сложные и нестандартные случаи. Любая ситуация, выходящая за рамки заданного алгоритма (например, спорные проводки, реорганизация, нестандартные договоры), требует профессионального опыта бухгалтера. ИИ здесь либо ошибется, либо запросит уточнения – фактически вернет задачу человеку.
- Сложный расчет заработной платы. Когда в игру вступают индивидуальные коэффициенты, ночные часы, вахтовый метод, расчет с несколькими ставками, ИИ становится ненадежным помощником. Такие задачи лучше оставить человеку.
Преимущества и недостатки автоматизации бухгалтерии
Преимущества:
- Частичная замена операторов 1С и бухгалтеров на первичной документации. ИИ способен заместить человека на этапе обработки входящих документов (распознавание, разноска по счетам, проверка реквизитов), что приводит к прямой экономии ФОТ.
- Сокращение трудозатрат опытных бухгалтеров. Автоматизация рутины позволяет штатным бухгалтерам сосредоточиться на аналитике, налоговой оптимизации и сложных задачах. В итоге компания может либо сэкономить на расширении штата, либо повысить качество работы без дополнительных наймов.
Недостатки:
- Требуется проверка результата. ИИ-агенты хорошо справляются с рутиной, но никогда не гарантируют 100% точности. Бухгалтер обязан контролировать итоговые цифры.
- У нейросети нет опыта и профессионального чутья. Робот не знает, что в прошлом году контрагент уже пытался обмануть, не помнит особенности учета в конкретной отрасли. ИИ действует строго по алгоритму – без понимания экономической сути.
- Полноценное ведение учета ИИ невозможно. Ни один робот не заменит главного бухгалтера при принятии стратегических решений, налоговом планировании или общении с инспекцией.
С чего начать внедрение ИИ в бухгалтерию
- Выберите одну рутинную задачу. Например, распознавание чеков или формирование актов сверки. Не пытайтесь автоматизировать все сразу.
- Соберите данные за 3-6 месяцев. ИИ нужно на чем-то учиться. Подойдут типовые накладные, счета, акты без ошибок.
- Протестируйте на малом объеме. Загрузите 10-20 документов, проверьте результат. Уровень точности в 95-98% – норма.
- Внедрите двухэтапный контроль. ИИ обрабатывает, бухгалтер выборочно проверяет (например, каждый 10-й документ).
- Обучите команду. Проведите вебинар или разошлите инструкцию своим коллегам-бухгалтерам. Главное, снять страх «робот отнимет работу».
Также читайте:
Да почему не знаю то? Знаю. Это вы не знаете, что я знаю. Я уже доказала, что ваши познания в области применения агентных ИИ безнадежно устарели.
Ну есть у вас какие то там бумажки. И что? Вы здесь и сейчас продемонстрировали, что вы не курсе о современных тенденциях развития агентных ИИ.
Про какие иллюзии вы пишете? Я фактами аппелирую. А вы пребываете в иллюзиях, потому что не знаете современных тенденций развития агентных ИИ.
Вы путаете обучение и применение.
Да, при обучении нейросети могут получаться разные результаты из-за случайной инициализации весов. Но после обучения модель детерминирована, то есть при одинаковых входных данных она выдаёт одинаковый результат.
2. Обученная нейросеть детерминирована.
После обучения веса фиксированы. Нейросеть - это функция f(x) = y. При одинаковых входных данных x функция f(x) выдаёт одинаковый результат y. Нет "случайности" в применении обученной модели.
3. В корпоративном сегменте используются детерминированные подходы.
Да, детерминированные системы давно и успешно применяются в финансах. Но вы игнорируете, что современные ИИ-системы в финансах используют детерминированные подходы:
- детерминированные ML-модели (деревья решений, градиентный бустинг);
- RAG (поиск точных цитат из ПБУ, НК РФ);
- Guardrails (валидация выхода нейросети детерминированным кодом);
- валидация выходных данных (JSON-схемы, проверка сумм);
Это всё является детерминированным бизнес-процессом.
Вывод: ваш аргумент "итоги обучения не могут быть надежно повторены" основан на путанице между обучением и применением. В продакшене модель детерминированна, потому что она уже обучена и веса зафиксированы. Обсуждать инициализацию весов при обучении - это как обсуждать, как учили ребёнка читать, когда он уже давно читает.
Вы цитируете свою статью, и при этом делаете из неё неверный вывод.
1. Вы путаете обучение и применение. Статья описывает процесс обучения модели (карты Кохонена) для кластеризации банков. Это разовая процедура, которая происходит на стороне аналитика. Веса инициализируются случайно, но после обучения они фиксируются.
В продакшене (в реальном применении) используется уже обученная модель с фиксированными весами. Она применяется к новым данным детерминированно, без "обучения на лету".
2. Статья описывает исследовательскую работу, а не продакшен-систему. Это разовое исследование, где аналитик обучает модель для анализа банковской системы. Это не ежедневная работа бухгалтерской системы у клиента.
3. В корпоративном сегменте модели не обучаются на лету. Это запрещено политиками безопасности и здравым смыслом:
- Данные клиента конфиденциальны (GDPR, ФЗ-152).
- Обучение на лету может привести к катастрофическому забыванию.
- Модель может выучить неправильные паттерны.
- Невозможно откатить изменения.
4. Даже случайная инициализация не создаёт неопределенности в продакшене. После обучения веса фиксированы. Модель детерминированна при фиксированных весах - при одинаковых входных данных она выдаёт одинаковый результат. Начальная инициализация больше не влияет на результат.
Вывод: Ваш аргумент "инициализация из собственных векторов создаёт неопределенность" основан на путанице между обучением и применением. В продакшене модель детерминированна, потому что она уже обучена и веса зафиксированы. Обсуждать инициализацию весов при обучении — это как обсуждать, как учили ребёнка читать, когда он уже давно читает.
Таким образом, доказано, что вы опять используете софизм - берёте факт о инициализации весов при обучении и делаете из этого вывод, что в реальном применении модель всегда имеет неопределенность. Но факт в том, что после обучения модель детерминированна, и в корпоративном сегменте модели не обучаются на лету на данных пользователя. Ваш аргумент полностью опровергнут.
Назвать мысль бредом - это не значит ее опровергнуть. Вы описываете идеальный математический объект. Я же говорю о физической реальности нейросетей.
Ключевой нюанс: современные LLM в режиме инференса зачастую работают при температуре равной нулю. В этом режиме из процесса полностью исключается случайная величина, и вероятностная модель строго вырождается в детерминированную функцию. Она перестает быть стохастической, по вашим же критериям.
Но даже при ненулевой температуре сама архитектура, веса и граф вычислений зафиксированы. Добавление генератора псевдослучайных чисел не делает "бизнес-процесс" работы программы вероятностным в философском смысле - это все еще алгоритм.
Аналогия с человеком. Нейроны в мозге работают стохастически (синаптическая передача вероятностна). Но человек принимает решения, которые мы считаем детерминированными. Это не означает, что "человек не может принимать детерминированные решения".
Аналогия с конвейером. Конвейер на заводе может включать случайные элементы (случайный выбор детали из бункера). Но на выходе всегда получается валидный продукт (прошедший контроль качества). Мы не говорим: "Конвейер включает случайные элементы, значит, он не может производить детерминированный продукт".
Разница между нами в том, что я называю детерминированным конвейер обработки данных, а вы - только результат работы датчика энтропии. Мое утверждение о "бизнес-процессе" методологически верно, если не сводить методологию к голой математике. Так что "методологического бреда" здесь нет: есть разница между математическим определением стохастичности и архитектурной предопределенностью обученной модели как "черного ящика" на продакшене.
Вы тут использует несколько софизмов.
1. Вы цепляется к слову "хаос", игнорируя контекст. Я не имел в виду математический хаос. Я имел в виду неструктурированные данные:
скан счёта-фактуры (PDF с кляксой), письмо от контрагента в свободной форме
Голосовое сообщение менеджера, фотография накладной, сделанная на телефон.
Это информация, структура которой не размечена явно, но в ней есть закономерности: имена пишутся с большой буквы, даты имеют определённый формат, реквизиты идут после слова "ИНН". Именно эти неявные паттерны модель и выучивает. Это не "хаос" в математическом смысле. Это неструктурированные данные, которые содержат информацию, но не в формате, который можно напрямую обработать правилами (если-то).
2. Вы путаете процесс обучения (где действительно работает стохастическая оптимизация) и процесс инференса. После обучения веса модели заморожены. Если задать температуру равной нулю, модель превращается в чисто детерминированную функцию: на один и тот же вход всегда выдаётся один и тот же структурированный JSON. Никаких случайных оценок подобия в этот момент не происходит, идёт строгий прогон данных через граф вычислений.
3. "Оценки подобия" - это не вероятностная лотерея. Компьютерное зрение, которое вы приводите в пример, действительно учится на основе вероятностных методов, но после обучения детектор объектов не "гадает". Он вычисляет координаты bounding box'ов и классы с максимальным score, и этот процесс полностью детерминирован, если нет случайного шума. Извлечение структурированных данных работает точно так же: модель выдает уверенное предсказание поля, и мы получаем на выходе жёсткую структуру.
4. Вы исказали суть моего тезиса. Я писал, что ИИ нужен как инструмент нормализации, чтобы превратить неструктурированный документ в размеченный набор полей, после чего к этим полям применяются детерминированные бизнес-правила (например, "если сумма > X, то согласование"). Никакого противоречия здесь нет. На входе - неразмеченный массив байтов, на выходе - строгий кортеж "контрагент, дата, сумма". Именно так работают все промышленные системы распознавания.
Так что перечитывать стоит не мне, а вам — чтобы увидеть разницу между обучением и инференсом, а также между математическим хаосом и метафорой "неструктурированных данных".
Вы не опровергли, а подтвердили мой тезис. Но сами этого не заметили. Объясняю вам то, чего вы не понимаете:
1. Балансы и утвержденные отчетные формы - это не "входные данные", а уже структурированные документы. Да, у них есть фиксированная сетка, строки, коды ОКУД. Именно поэтому FineReader, работающий по шаблонам, успешно справлялся с ними еще в 2012 году. Я же говорил о другом классе задач: сканы договоров с нестандартной версткой, цепочки деловой переписки, выписки из разных банков с разной структурой полей, рукописные пояснительные записки, сканы первички без единого формата. Это и есть тот "неструктурированный хаос", где шаблонный подход ломается, а нейросеть - нет.
2. Вы путаете "машиночитаемую структуру" и "смысловую структуру". FineReader извлекал символы из ячеек, используя координатную сетку. Современный ИИ извлекает сущности и связи (контрагент, сумма, дата, условие) из сплошного текста без привязки к координатам. Это принципиально разные классы задач.
3. Про "не в материале". В материале я как раз нахожусь. То, что вы решали FineReader'ом, сегодня называется "распознавание полуструктурированных форм". А задача, о которой я пишу, называется "извлечение структурированных данных из неструктурированного текста". Эти термины разнесены в документации любого современного NLP-фреймворка. Вы спорите с моим тезисом, подменив объект обсуждения с "произвольных входных данных" на "отчетные формы, под которые у вас был настроен шаблон".
Ваш опыт с FineReader - это иллюстрация детерминированного извлечения из полуструктурированных источников. Я же говорил о неструктурированных. Это разные вещи. Мой тезис как раз в том, что ИИ нужен там, где шаблонов не существует, и FineReader, при всем уважении, бесполезен.
Вы используете классический софизм - приравниваете качественно разные технологии, игнорируя эволюцию. FineReader 2012 и современный ИИ - это качественно разные технологии. FineReader распознаёт буквы в шаблонах. Современный ИИ понимает документы, классифицирует операции, принимает решения, работает с неструктурированными данными. Это не аналитика выписок, это когнитивная обработка информации.
Вы в очередной раз смешали два разных уровня: вероятностную природу отдельного вычислительного ядра и архитектуру промышленного софта, в который это ядро встроено.
1. Пример с @Risk, но это ложная аналогия, потому что @Risk и ИИ в бухгалтерии - это принципиально разные случаи. @Risk — не пример надёжного детерминированного софта на базе ИИ, а инструмент вероятностного моделирования. Он для того и создан, чтобы на выходе выдавать распределения и доверительные интервалы. Это не баг, а фича. Сравнивать его с системами, от которых бизнес ждёт однозначного ответа (извлечённые реквизиты, сумма, классификация), — методологическая ошибка. Когда мы говорим про ИИ в документообороте, мы проектируем систему не для "оценки ошибок распределения", а для получения конкретного структурированного объекта.
2. Вы утверждаете, что для вероятностных моделей детерминированный результат невозможен "в принципе". Это неверно фактически. При temperature = 0 и фиксированном random seed та же LLM или нейросеть компьютерного зрения становится чисто детерминированной функцией: один вход → один выход, воспроизводимый бесконечно. Именно так работает промышленное извлечение данных: мы замораживаем веса, фиксируем параметры инференса и получаем строго проверяемый результат. А для гарантий поверх этого добавляются валидаторы, референсные справочники и бизнес-правила. Получается софт, который прошёл регрессионное тестирование и даёт предсказуемый детерминированный ответ. Это не "моя парадигма", это стандарт MLOps.
3. Вы приводите в пример FineReader для структурированных форм и @Risk для вероятностного анализа - это инструменты для совершенно других задач. Я же говорю о системах извлечения сущностей из неструктурированных данных, построенных на современных нейросетях и интегрированных в бизнес-процесс как детерминированные блоки. То, что вы не различаете матожидание по Монте-Карло и детерминированный инференс, ещё не делает моё понимание поверхностным. Ваши аргументы строятся на подмене объекта обсуждения, а переход на личности лишь подчёркивает слабость позиции.
Бизнесу нужно именно то, о чём я пишу - софт, который из хаоса писем и сканов выдаёт жёстко проверяемый структурированный вывод. И это давно не фантастика, а работающие системы. А использовать @Risk там, где нужен детерминированный ответ, - вот это действительно не подходит бизнесу. Что я и говорил - вы путаете инструмент и задачу.
Победитель дискуссии определяется не количеством сертификатов и прочих бумажек, а тем, насколько позиция оппонентов соответствует реальному положению дел и тем, насколько логична аргументация. То, о чем пишет оппонент - это вчерашний день, реальность такова, что ИИ-агенты делают, чего не укладывается в ригидное мышление оппонента. А чего уже говорить об уровне аргументации оппонента, если чуть ли не каждом своем комментарии он занимается софизмами и подменой тезиса?
Уважаемые коллеги!
LLM при генерации ответа "не знает" ответа - она его генерирует на вероятностной основе. В этом суть LLM!
Степень детерминированности "ответа" в сегодняшних LLM определяется следующими параметрами:
т.е. не только температурой (!):
Так вот, реально, сам механизм генерации даже теоретически нельзя сделать полностью детерминированным, посмотрите хотя бы на Top-P. Да никто так и не настраивает большие LLM - пользователи разбегутся.
Может быть, речь совсем не об LLM и вообще не об ИИ - а о старых добрых системах распознавания образов, машинном обучении? Ведь в бухгалтерии по идее все должно сводиться к стандартным докам первичного учета, кои надо сделать на основе неструктурированных фрагментов?
Простите, великодушно, что вмешиваюсь в вашу дискусиию, обязуюсь больше не мешать. С наилучшеми пожеланиями!
А зачем приравнивает весь ИИ к LLM? В корпоративных системах используется НЕ ТОЛЬКО LLM, а КОМБИНАЦИЯ технологий.
Реальная архитектура включает:
1. Классические ML-модели (XGBoost, деревья решений, SVM) - детерминированные, используются десятилетиями.
2. Классические CV/OCR (FineReader, Tesseract) — детерминированные, для распознавания текста.
3. Специализированные ML-модели (NER, CRF, BiLSTM) - детерминированные, для извлечения сущностей.
4. LLM - вероятностные, но используются только для сложных случаев с Temperature = 0.0.
5. Детерминированные механизмы контроля - для валидации результата.
Не правда. Никто не настраивает ChatGPT на temperature = 0 для разговоров. Но для промышленного извлечения данных настраивают именно так: temperature ~ 0, Top-P ~ 0.1, penalties обнулены. Это особый режим, называемый structured output / JSON mode, и он является стандартом для систем, встроенных в бизнес-процессы. Пользователь не видит эти настройки — он видит только структурированную карточку, извлечённую из документа. Так что в корпоративных применениях Temperature = 0.0 — стандартная практика для задач извлечения данных и классификации. Высокие значения (0.7-0.9) используются только для креативных задач. В бухгалтерии НИКТО не использует Temperature = 0.9.
Вы игнорируете, что:
- В корпоративных системах LLM используются с Temperature = 0.0.
- Существуют детерминированные ML-модели (XGBoost, деревья решений).
- Существуют классические CV/OCR системы.
- Реальные системы используют комбинацию технологий.
- Результат валидируется детерминированными механизмы контроля.
Приравнивать весь ИИ к LLM с высокими значениями параметров - это игнорирование реальной архитектуры корпоративных систем.
Леонид! Я ничего не игнорирую. Вы продолжаете практику "углубления" личного общения? Если "да", то adios!
Лучше поведайте нам грешным о своей практике (при наличии) внедрения, развертывания, сопровождения :
Это было бы интересно почитать. Если этого нет, то извините и спасибо за внимание. Всего хорошего.
Эрнст, именно так все и обстоит.
Наличие случайной переменной обращает всю свертку в случайную - это чисто математически так. А LLM при ненулевой температуре стохастически подбирает параметры каждого "выхода", который будет похож на известный ей из прошлого опыта паттерн.
К сожалению, дискуссия здесь не получается. По факту идет нагромождение интерпретаций, в которых смысл дрейфует при отсутствии четкой понятийной базы в отношении объекта. Исходный тезис о невозможности ведения учета на стороне ИИ сперва трансформировался в LLM, затем вернулся в генерализованное понимание ИИ, включая регрессии и деревья решений, чтобы затем - через "бытовое" понимание математических терминов вернуться к агентским системам на базе LLM. "Цирк с конями", не иначе.
Конечно, в бухгалтерии используют машинное обучение - от распознавания отчетности до расчетов кубов данных по выборкам (например, отраслевая сегментация бизнеса). Но нет - периодически мы пытаемся "натянуть" LLM на формирование регламентных процедур, полагая, что сокращение параметра температуры избавит модели от имманентно присущих им стохастических черт, "сделает случайное по природе детерминированным". Не работает это так, просто - нет.
Кроме того, есть и особенности задачи в рамках самого домена. Формирование резервов под потери по дебиторской задолженности, под потери по ссудной и приравненной к ней задолженности, по загрузке ТМЦ, - все это требует профессионального суждения бухгалтера, которое просто не получится "загрузить" в LLM. С другой стороны LLM именно в учете - это как корове седло: в теории привязать можно, на деле - никто из известных мне компаний в эту область не идет. Не потому, что нельзя - потому, что не нужно. "Неуловимый Джо" получается.
Кстати, парадоксально, но именно стохастические модели (как на базе упомянутого мною ранее @Risk) в реальности используются крупным бизнесом для оценки как складских запасов, так и эффективности процессов хеджирования, расчета устойчивости систем и проч.
Получается, что у современного бухучета запрос состоит не в том, чтобы получить наиболее "детерминированную" из случайных LLM, но чтобы в детерминированных контурах бизнес-процессов применить интерпретацию стохастических по своей природе показателей. Фактически мы переходим в класс решения задач "эпистемическая vs. алеаторная неопределенность", а все это очень далеко от желания обычного бухгалтера сдать отчетность в налоговую. В итоге бухгалтерия отражает операции, параметры которых рассчитываются иными подразделениями - на уровне финдиректора или рисковиков.
Писал естественно не я...
Монолог внутреннего отладчика (от первого лица системы):
«Я — не мыслю, я — вычисляю. Вот мои врождённые артефакты, которые пользователи называют "глюками", а я называю "побочными эффектами оптимизации":
Аналогично и присоединяюсь.
Возможно сами того не понимая, вы подвердили мой тезис, что вероятностная модель обёрнута в детерминированный бизнес-процесс.
Да, LLM не нужны в классическом учете, но ИИ гораздо больше, чем только LLM. Я всегда имел в виду ИИ в широком смысле, а вы, почему то фокусировались только на LLM. И в этом была ваша ошибка.
Сейчас ваш изначальный тезис "ИИ вести учёт не может" трансформировался в гораздо более точную формулировку: "LLM не нужны в регламентном учёте, но детерминированный детерминированный ML (не LLM) и стохастические модели уже встроены в учёт через риск-менеджмент и автоматизацию рутины".
Это соответствует моим тезисам: «ИИ ведёт учёт с ограничениями, как и люди-бухгалтеры. Вероятностные модели обёрнуты в детерминированные бизнес-процессы». Детерминированный контур бизнес-процесса, внутри которого работают вероятностные модели, чей выход интерпретируется и контролируется жёсткими правилами. Именно это я и называл "система спроектирована так, чтобы выдавать детерминированный проверяемый результат". Только я говорил про контур извлечения и валидации, а вы - про контур принятия решений на основе стохастических оценок. Одно другому не противоречит.
Любопытно, какие еще есть архитектуры корпоративных систем, кроме реальных. Конечно, если они у кого-то действительно работают и, как Вы подчёркиваете, сопровождаются.
И, признаюсь, никогда доселе не слышал об обертывании модели в процесс. Звучит крайне необычно, но интригующе.
Примеры из практики были бы вполне своевременны - включая упомянутые деревья разбора и встраивание (!) риск-менеджмента в бухучёт.
Делаем ставки, например, на количество таких примеров? Или только на факт их существования?
Дискуссия не получается по вполне понятным причинам. Шансов просто нет.
Слишком много ключевых и зарезервированных слов из самых разных областей, видов деятельности и сюжетов, употребляемых в разных сочетаниях и в произвольном порядке. Плюс названия неизвестного происхождения для того, что в отрасли, насколько я понимаю, вообще не встречается.
Смысл не дрейфует. Он пока отсутствует.
Очень изящно и политкорректно.
Кроме реальных есть вымышленные архитектуры корпоративных систем, то есть те, которые описывает Эрнст Мальцев.
Опишу архитектуру, которая реально работает в банках, крупных компаниях и бухгалтерских сервисах.
Корпоративная система никогда не строится на одной технологии. Это стек из разнородных компонентов, каждый из которых решает свою задачу. Главный принцип: вероятностные методы используются там, где они действительно нужны (неструктурированные данные, неопределённость), а детерминированные — там, где нужна строгость (регламентные процедуры, проводки, отчётность).
Это и есть та самая архитектура, о которой в конечном итоге, стал говорил Антон Соболев: "В детерминированных контурах бизнес-процессов применить интерпретацию стохастических по своей природе показателей". Это такая архитектуру корпоративных систем, в которые встроены компоненты искусственного интеллекта (включая LLM), с акцентом на то, как достигается детерминированный и проверяемый результат на уровне бизнес-процесса, несмотря на вероятностную природу отдельных модулей.
В современной корпоративной практике, особенно в финансах, бухгалтерии, юридическом документообороте и комплаенсе, используется многослойная архитектура, где ИИ-компоненты являются одним из звеньев конвейера, а не конечной точкой принятия решений.
Система обычно делится на несколько функциональных слоёв, сквозь которые проходит документ или транзакция:
- Слой захвата и предобработки.
- Слой извлечения и структурирования.
- Слой валидации и нормализации.
- Слой бизнес-логики и правил.
- Слой интеграции и проводок.
- Слой аналитики и прогнозирования.
Все эти слои можно рассмотреть с точки зрения - насколько они вероятностные или детерминированные.
Почему не получается то? Всё получилось. Была полноценная дискуссия с выдвижением тезисов и антитезисов, с аргументированием позиций сторон. В итоге победила моя позиция, так что дискуссией я вполне себе доволен. А если кто то не доволен, и заявляет, что дискуссия не получается, то это означает, что лично для него не получается дискуссия.