Почти каждая компания, которая пробовала внедрить ИИ в работу с таблицами, прошла через один и тот же сценарий. Загрузили отчёт в нейросеть, задали вопрос  — и получили ответ — красивый, связный, убедительный. А потом, на всякий случай, сверили с исходником и обнаружили: цифры не бьются, часть данных придумана, выводы ложные.

Этот опыт часто становится последним. Сразу появляется вывод: «Нейросети пока не готовы» — и замораживаются проекты до лучших времён. Проблема в том, что вывод делается не о том, проблема не в нейросети, а в архитектуре её использования.

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

Когда вы отправляете в модель таблицу на десятки тысяч строк, происходит следующее: Внимание модели распределяется по контексту неравномерно. Начало и конец документа ещё как-то обрабатываются, середина проваливается. Столбцы начинают смешиваться, строки теряются, но модель не может ответить «я не знаю» или «данные потеряны при обработке». Она заполняет пробелы наиболее вероятным - с её точки зрения - содержанием, так и возникают те самые «галлюцинации».

Производители заявляют контекстное окно в 200 тысяч токенов - это примерно  150 страниц текста, но на практике деградация начинается на первой трети этого объёма. Причём внешне ответы модели остаются такими же уверенными, без построчной сверки с исходником отличить правдивый ответ от вымышленного невозможно. Если вы всё равно сверяете каждую цифру вручную - зачем тогда ИИ?

Первое, что делают команды, столкнувшись с галлюцинациями в цифрах, — улучшают промпты: «Проверяй цифры дважды», «Опирайся только на данные из таблицы», «Если не уверен — укажи на это», «Перепроверь свои расчёты». Это даёт косметическое улучшение, модель начинает ошибаться чуть реже. Но природа ошибок не меняется, потому что модель по-прежнему пытается «считать». Более того, улучшенные промпты создают ложное ощущение надёжности. Красиво сформулированный ответ, в котором ошибка спрятана глубже, опаснее откровенно абсурдного, бизнес начинает принимать решения на основе данных, которые выглядят корректными, но таковыми не являются.

Лечить галлюцинации в цифрах промптами — всё равно что красить стены в доме с треснувшим фундаментом. Проблема архитектурная, а не лингвистическая, поэтому и решение должно быть архитектурным.

Решение формулируется в одно предложение: цифры считает строгий серверный код, нейросеть работает только с готовыми результатами.

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

Что это означает на практике:

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

Команда АЙТИФОКС применила этот подход в проекте для «РЕСТФОТОАНАЛИТИКА» — компании, которая организует питание в отелях по системе «шведский стол» и управляет десятками точек. Заказчик хотел заменить ручного аналитика, часами сводившего отчёты о списаниях и остатках, на ИИ.

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

После перехода к архитектуре «сервер считает — модель формулирует» результаты не заставили себя ждать:

• Ошибки в цифрах исключены полностью — модель не имеет доступа к сырым данным.
• Стоимость одного запроса сократилась в 3–20 раз: с 30–100 тысяч токенов до 1,5–3 тысяч.
• Прототип создан за три недели силами двух разработчиков.
• Анализ данных ускорился на 95% — отчёты готовятся за минуты вместо часов.

Дополнительный вывод, который команда сделала по ходу: для задач табличной аналитики разницы между старшей и облегчённой версией нейросети нет. Протестировали — не переплатили за избыточную мощность.

Первое. Перестаньте отправлять таблицы в нейросеть напрямую. Это не вопрос оптимизации промптов. Это вопрос архитектуры. Если ваша система построена на схеме «загрузил и спросил» — вы накапливаете риски, даже если на малых данных ошибки незаметны.

Второе. Разделяйте расчёты и оформленный результат. Цифры считает код на сервере, нейросеть формулирует ответ — это единственный способ гарантировать точность данных.

Третье. Не переплачивайте за старшие версии моделей без тестов на своих задачах. Для табличной аналитики разницы между версиями может не быть, проверяйте и выбирайте минимально достаточную.

Четвёртое. Встраивайте человека в финальную проверку. Это не откат к ручному труду и не слабость системы. Это зрелый риск-менеджмент: машина убирает 95% рутины, но финальное решение остаётся за оператором.

Задача «есть множество таблиц от разных источников, нужно получать точные ответы» встречается не только в общепите: розница и ежедневные отчёты по продажам, логистика и данные по маршрутам, финансы и выписки, производство и учёт сырья. Везде, где бизнес принимает решения на основе табличных данных, применим один и тот же архитектурный принцип: изолируйте данные от модели, считайте на сервере, используйте нейросеть как интерфейс.

Описанное решение — не теория, а то что сработало.

Если ваши нейросети всё ещё врут в цифрах при работе с отчётами — проблема не в ИИ, а в архитектуре.

Разобрать кейс полностью и обсудить, как применить этот подход к вашим задачам