Гайд · TNWS AI
Как проверить цену и количество каждой позиции счёта после AI-OCR
Проверяем quantity × unit_price против line_total после извлечения счёта нейросетью, без смешения чисел и текста.
Практическая задача
Найти ошибку распознавания количества или цены именно в строке счёта, прежде чем сравнивать общий итог. Контракт примера: quantity целое положительное, unit_price и line_total — десятичные строки, валюта общая. Реальные счета могут разрешать дробное количество или отрицательную корректировку — тогда правило нужно явно изменить. Проверка строки локализует проблему, которую общий итог может скрыть, если две ошибки взаимно компенсировались. При неоднозначном распознавании сверяйте изображение первоисточника. Этот сценарий применим, когда у команды есть контроль над входом или выходом AI-приложения и требуется конкретный сигнал о нарушении правила, а не общее впечатление от нескольких ответов. Все входы ниже вымышлены; числовые результаты относятся только к этим примерам.
Документация методов Python и синтаксиса workflow сверена 20.09.2026. Если вы используете другое окружение, проверьте совместимость до копирования команд. Статья не утверждает, что показанный код измеряет качество конкретной модели или заменяет ручную проверку.
Подготовка и проверяемый контракт
Перед запуском запишите, какие данные считаются входом, что является ожидаемым результатом, что именно означает отказ и кому предстоит разбирать расхождение. Для такой проверки храните тестовый вход, ожидаемый результат и фактический исход раздельно: если они смешаны, тест может подтверждать сам себя. Используйте стабильные синтетические ID, чтобы видеть ошибку в журнале, не раскрывая содержимое клиентских обращений.
Сначала прогоните тест на маленьком входе, где правильное поведение известно вручную. Затем внесите одну контролируемую ошибку и убедитесь, что код её замечает. После этого верните корректный набор и только тогда расширяйте проверку до реальных данных. Не переносите демонстрационные численные значения или пороги в производство без отдельного обоснования: они выбраны для наглядности, а не рассчитаны по вашей аудитории.
Вход и ожидаемый результат
Строка P-1: 3 единицы по 12.50, сумма 37.50; распознанная сумма 37.05 должна быть отклонена. Для P-1 вычисление 3 × 12.50 равно 37.50; 37.05 и True отклоняются. Перед тем как применять правило к закрытым данным, обсудите пограничные случаи, которые могут поменять интерпретацию входа. Запись в документации о границах теста не менее важна, чем зелёный check.
Пошаговые действия
- Создайте
scripts/check.pyв корне репозитория и вставьте код из блока ниже. Он использует названия функций стандартной библиотеки, указанные в официальных ссылках в конце статьи. - Выполните
python scripts/check.pyлокально. Не продолжайте, если уже демонстрационная фикстура даёт иной результат: сначала проверьте копирование кода и кодировку файла. - Согласуйте тип quantity и правило округления, прежде чем копировать тест. Запустите пример и отрицательные случаи: ошибочную распознанную сумму и логическое True вместо количества. Обратите внимание на строгую проверку type(qty) is int — в Python bool наследуется от int. В рабочем пайплайне сохраните изображение области позиции и поля, вызвавшего расхождение, с контролем доступа. Не редактируйте исходный документ под вычисленную сумму.
- Создайте
.github/workflows/ai-corpus-check.ymlиз YAML-шаблона. Событиеpull_requestполезно для проверки данных до слияния; чтение репозитория ограниченоpermissions: contents: read. Скрипт не должен получать ключ внешней модели или реальные секреты. - В разделе Actions откройте job
check, сопоставьте его код завершения с локальным прогоном и зафиксируйте ссылку на проверенный коммит в PR. Не принимайте зелёный результат на старой ревизии за проверку последнего изменения.
# scripts/check.py
from decimal import Decimal
line={'id':'P-1','quantity':3,'unit_price':'12.50','line_total':'37.50'}
def check(row):
qty=row['quantity']
if type(qty) is not int or qty<=0: raise ValueError('invalid quantity')
price=Decimal(row['unit_price']);total=Decimal(row['line_total'])
if not price.is_finite() or not total.is_finite() or price<0: raise ValueError('amount')
return price*qty==total
assert check(line)
assert not check({**line,'line_total':'37.05'})
try: check({**line,'quantity':True})
except ValueError: pass
else: raise AssertionError('bool accepted')
print(line['id'],'valid; OCR mismatch and bool rejected')
name: AI corpus checks
on:
pull_request:
permissions:
contents: read
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- uses: actions/setup-python@v7
with:
python-version: '3.13'
- run: python scripts/check.py
Ошибки интерпретации и границы
Тест не подходит без изменений для весовых товаров, скидок в строке и другой договорной политики округления. Если вы расширяете набор случаев, добавляйте не только новые примеры, но и отрицательные случаи, на которых тест обязан упасть. Проверяйте, что изменение expected прошло ревью отдельно от изменения кода: иначе можно незаметно изменить правило под текущий ответ системы. Избегайте вывода полного приватного набора в CI и не сохраняйте в артефактах ответ закрытой модели без решения о доступе и хранении.
Ошибка выполнения самого Python, нераспознанный формат входа и обнаруженный бизнес-дефект — разные ситуации. В сообщении теста указывайте тип проблемы и безопасный ID. Если тест требует внешний сервис, вынесите его из PR с недоверенным кодом и явно ограничьте доступ к токенам; этот пример намеренно работает локально. Перед публикацией каких-либо результатов опишите методику, область применения и происхождение примеров, иначе читатель воспримет демонстрационную арифметику как характеристику продукта.
Практический разбор именно этого контроля
Найти ошибку распознавания количества или цены именно в строке счёта, прежде чем сравнивать общий итог. Для самостоятельной проверки сначала выпишите три наблюдаемых состояния: допустимый вход, намеренно недопустимый вход и видимый сигнал отказа. В данной фикстуре это выглядит так: Строка P-1: 3 единицы по 12.50, сумма 37.50; распознанная сумма 37.05 должна быть отклонена. При успешном тесте ожидается: Для P-1 вычисление 3 × 12.50 равно 37.50; 37.05 и True отклоняются. Не превращайте это в числовой KPI: здесь проверяется контракт на конкретных примерах, а не поведение модели на пользовательском трафике.
Тест не подходит без изменений для весовых товаров, скидок в строке и другой договорной политики округления. Подключая проверку к продукту, расположите её до той операции, ради которой она написана: парсинга, сохранения, отображения или экспорта. Для каждого нового формата добавляйте отдельный негативный пример и письменное решение, почему он отклоняется. Отдельно просмотрите обработку ошибок: система должна отличать невалидный ответ AI от сбоя тестовой инфраструктуры, а пользователь не должен видеть сырой стек или приватное содержимое.
Чек-лист финальной проверки
- Синтетический вход и ожидаемый исход согласованы предметным владельцем.
- Команда
python scripts/check.pyработает локально и в CI на одной версии файлов. - Негативный случай обнаруживается, а не только успешный случай проходит.
- Имена ID и меток уникальны там, где этого требует контракт.
- В репозитории, логах и артефактах нет реальных секретов и приватных текстов.
- Понятно, какой дефект тест находит и каких выводов о качестве AI он не даёт.
- Ссылки на применённые функции и синтаксис workflow перепроверены при переносе.
FAQ
Почему True опасно?
В Python bool является подклассом int и в арифметике может вести себя как 1.
Можно дробное количество?
Да, если это разрешено процессом, используйте Decimal и отдельные фикстуры.
Что если ошибки взаимно компенсировались?
Построчная проверка найдёт их даже при совпавшем общем итоге.
Кто исправляет?
Оператор сверяет исходный документ, не алгоритм без подтверждения.
Что делать после обнаружения сбоя
Сохраните конкретный ID, воспроизведите его на текущей ревизии и отделите ошибку входных данных от ошибки функции. Если неверна контракт, исправьте её после предметного ревью; если неверен код, сначала оставьте проваливающийся тест, затем вносите исправление. После зелёного запуска просмотрите соседние случаи с похожими признаками, чтобы локальная правка не изменила другое согласованное поведение. Сохраните версии кода, набора и параметров запуска рядом с выводом: без них сравнивать результаты в будущем нельзя. Не приводите цифру из синтетического примера как измеренный показатель продукта.
Официальные первоисточники
Проверено 20.09.2026: 1, 2, 3, 4, 5. Описание переписано своими словами; изменяемые версии и поля нужно повторно сверять перед дальнейшим использованием.
Читайте также
Как исключить bias из weight decay через Optax
Optax 0.2.6: маска add_decayed_weights применяет decay к kernel и оставляет bias без изменения.
Как использовать Huber loss в Optax для регрессии с выбросами
Optax 0.2.6: Huber loss квадратичен около нуля и линеен после delta; проверяем ошибки 0,5 и 2.
Как использовать sigmoid focal loss в Optax
Optax 0.2.6: focal loss для logits 0 и labels 0/1 при gamma=2; проверка симметричного базового значения.
Комментарии
Пока тихо. Скажите первое слово