ИИ и числа: почему модель не считает и что с этим делать

С чего это начинается

Конец месяца. Из учётной системы выгружена таблица платежей: двести строк, столбцы — дата, контрагент, менеджер, регион, сумма. Нужен свод: общий итог, разбивка по менеджерам, доля каждого.

Вы прикладываете файл в чат и просите посчитать. Ответ приходит аккуратной таблицей: итог, разбивка, проценты. Порядок величин правильный, ни одно число не выглядит странно, доли складываются почти в сто.

Почти — это и есть проблема. Через день выясняется, что три платежа не попали в разбивку, итог занижен, а сумма долей даёт 100,4 %. Модель не выдала итог в десять раз больше и не написала вместо суммы слово — она выдала число, неотличимое от правильного по внешним признакам: тот же порядок, та же округлённость, тот же вид.

Это не сбой конкретного сервиса и не следствие плохо составленного запроса, а следствие того, как устроена генерация текста.

Модель не вычисляет — она продолжает текст

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

В работе «Faith and Fate: Limits of Transformers on Compositionality» это проверяли на задачах, где ответ требует строгой многошаговой процедуры, — в частности на умножении многозначных чисел. Вывод авторов: модель решает такие задачи не выполняя алгоритм, а сопоставляя задачу с похожими образцами из обучения. Пока пример близок к знакомому, ответ получается верным. Как только нужно точно провести цепочку из многих шагов, качество падает — падает не в шум, а в правдоподобные числа.

Отсюда три следствия.

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

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

Форма ответа не меняется. Число, полученное сопоставлением с образцом, оформлено так же, как число, полученное сложением. Пометки «здесь я не уверена» не будет.

Где ломается чаще всего

• Итог по длинному столбцу. Чем больше строк, тем длиннее цепочка сложений и тем выше шанс, что часть строк будет пропущена или учтена дважды.
• Проценты и доли. Каждая доля считается отдельно, их сумма не проверяется. Признак — доли, дающие 99,4 или 100,6 вместо ста.
• Разность двух близких больших чисел. Выручка 10 400 000 минус выручка 10 250 000 даёт 150 000. Промах в 50 000 на любой из двух величин — это треть от разницы, хотя на самих величинах он незаметен.
• Округление промежуточных значений. Модель округляет по дороге и складывает уже округлённое. Три равные доли по 33,333 % после округления до десятых дают 33,3 + 33,3 + 33,3 = 99,9.
• Смешанные единицы. Штуки и упаковки, рубли и тысячи рублей, суммы с НДС и без — в одном столбце. Модель приведёт их к одному виду по догадке и не сообщит об этом.
• Группировка при разном написании. Один контрагент, записанный тремя способами, станет тремя строками свода. Арифметика при этом будет безупречной.

Приём: проси формулу, а не результат

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

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

Этот приём разобран в двух работах. В «PAL: Program-aided Language Models» модель читает задачу и выражает её как программу, а само вычисление отдают интерпретатору. В «Program of Thoughts Prompting» тот же принцип измерили на восьми наборах числовых задач — пяти с текстовыми задачами по математике и трёх с вопросами по финансовой отчётности; вынос вычисления во внешний исполнитель дал, по замеру авторов, в среднем около 12 % прироста к качеству по сравнению с пошаговым рассуждением прямо в тексте. Замер сделан в 2022 году на моделях того времени.

Число одноразовое: оно верно для той выгрузки, которую вы приложили, и завтра его придётся получать заново. Формула переиспользуема и проверяема: видно, какой диапазон она берёт и по какому условию отбирает строки. У числа проверять нечего.

Готовый промпт

Пункт 1 — сам приём. Пункты 3 и 4 — две проверки, ради которых он и нужен.

Контрольная сумма

Контрольная сумма — это второе число, которое обязано совпасть с первым, если расчёт цел. Не «похожее», а ровно то же.

Минимальный набор для сводной таблицы — два счётчика.

Сколько строк попало в расчёт. Пример на синтетических данных: в выгрузке 200 строк, свод даёт четыре группы по 62, 51, 47 и 40 строк. Складываем: 62 + 51 + 47 + 40 = 200. Сходится — ни одна строка не потерялась и не удвоилась. Если бы вышло 197, вы бы знали точное число пропавших строк ещё до того, как разбираться почему.

Сумма частей равна целому. Итоги четырёх групп: 1 240 000, 860 000, 1 105 000 и 795 000. Их сумма — 4 000 000, и это же число должно стоять в строке общего итога. Если общий итог считался отдельной формулой по всему столбцу, а групповые — по отфильтрованным диапазонам, совпадение означает, что фильтры покрыли столбец целиком, без дыр и без пересечений.

Обе проверки не требуют понимания данных и дают число расхождения вместо ощущения «вроде сходится».

Сверка по двум разрезам

Контрольная сумма ловит потерю строк, но не ошибку в самой группировке. Против неё работает другой приём: собрать тот же итог второй раз, по другому признаку.

Первый разрез — по менеджерам: 1 240 000 + 860 000 + 1 105 000 + 795 000 = 4 000 000. Второй — по регионам: 1 450 000 + 1 320 000 + 1 230 000 = 4 000 000. Числа внутри разрезов разные, состав групп разный, итог один. Чтобы два таких итога совпали при ошибке, ошибка должна быть одинаковой в обеих группировках — этот случай разобран ниже. А если бы регионы дали 3 870 000, расхождение в 130 000 сразу показало бы, где искать: строки с заполненным менеджером и пустым регионом.

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

Где приём ломается

Формула может быть неверной. Модель ошибается и здесь: возьмёт диапазон D2:D150 вместо D2:D200, перепутает столбец, применит условие не к тому полю. Разница в том, что такая ошибка видна в самой формуле, а ошибка в числе — нет.

Систематический пропуск сойдётся в обоих разрезах. Если из расчёта выпали одни и те же строки и по менеджерам, и по регионам, оба итога совпадут и оба будут неверны. Ловится это только счётчиком строк, сверяемым с исходной выгрузкой: две проверки нужны вместе, а не по выбору.

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

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

Скан и распознавание. Если исходник — фотография или PDF из сканера, подмена цифры происходит на этапе распознавания. Формула будет безупречной, контрольная сумма сойдётся, разрезы совпадут — потому что все они считают уже испорченный вход. Числа со скана сверяйте с оригиналом глазами.

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

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

Что сделать сегодня

Возьмите таблицу, по которой вы уже просили ИИ что-то посчитать, и задайте тот же вопрос ещё раз — промптом из этой статьи. Вставьте полученные формулы в файл и сравните результат с числом, которое получили в прошлый раз.

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