/ Модель

Характеристики

Лицензия
Apache 2.0
Архитектура
receipt-digit-reader · dense
Библиотека
onnxruntime
Опубликована
14 авг 2026

tiny-receipt-reader-digit-slots-2m

Описание изображенийИзображение → текст3 профессии

Компактная CNN в формате ONNX извлекает из изображения чека цифры телефона и номера улицы для последующего ответа на вопросы об этих полях.

13скачиваний за 30 дней0лайковвеса обновлены15 авг 2026

Бенчмарки

Как модель справилась с задачами пользователей ailist и что о ней публикуют открытые лидерборды

Публичные оценки

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

В подключённых источниках результатов для этой модели пока нет.

Что умеет модель

Описание составлено по карточке модели и метаданным Hugging Face

ivere27/tiny-receipt-reader-digit-slots-2m — компактная CNN-модель для извлечения цифр из изображений чеков, разработанная автором репозитория и опубликованная в формате ONNX. Модель принимает изображение чека фиксированного размера 672×320 и за один проход формирует запись из слотов: цифры телефона и номера улицы. Текст не распознаётся, а вопросы о прочитанных полях обрабатываются отдельным маршрутизатором на регулярных выражениях и индексированием записи.

Модель содержит 2,46 млн параметров. Вариант FP32 и вариант INT8 с квантизацией свёрточных слоёв показали на 2 000 отложенных вопросов точность ответа 98,75% и 98,45% соответственно; оценки получены на машинно сгенерированных аннотациях. Модель рассчитана на извлечение телефонных и уличных цифр из чеков, а не на общее понимание документов. Она не читает названия магазинов, строки товаров и полные адреса; вопросы о других полях дают пустой ответ. Для работы необходим отдельный question_router.py. Лицензия — Apache-2.0.

Сценарии применения

  • извлечение номера телефона из изображения чека
  • извлечение номера улицы из адреса на чеке
  • ответы на вопросы о телефоне в чеке
  • ответы на вопросы о номере улицы в чеке

Ограничения

Модель извлекает только цифры телефона и номера улицы, принимает изображения фиксированного размера 672×320 и не распознаёт произвольный текст; прочие вопросы возвращают пустой ответ. Для ответов требуется отдельный question_router.py, а оценка основана на машинно сгенерированных аннотациях.

Для каких профессий подходит3

Разделы каталога профессий, в задачах которых используется эта модель

Все профессии

Карточка модели

README от автора на Hugging Face, как он его опубликовал

Открыть на Hugging Face

tiny-receipt-reader-digit-slots-2m

A question-free receipt reader. One small CNN reads the image once and emits a fixed record; questions are answered afterwards by regular expressions and array indexing.

There is no transformer, no decoder, no autoregressive loop, no tokenizer, and no question encoder. The graph has one input: the image.

image ──▶ CNN ──▶ slots 0..11  phone digits
                  slots 12..15 street-number digits

question ──▶ regex ──▶ (family, op) ──▶ index the record ──▶ answer

Several questions about one receipt cost one forward pass, because the record does not depend on the question.

Files

model.onnx           FP32 graph
model_int8.onnx      static W8A8 (QDQ, U8S8) graph
config.json          input contract and slot layout
manifest.json        graph contract and the full export verification report
question_router.py   regex router, required to answer a question
inference.py         onnxruntime runtime
examples/            two synthetic receipts and a runnable check
eval/                held-out reports and runtime benchmarks

Usage

pip install -r requirements.txt

English question, FP32:

python inference.py --model-dir . --image examples/receipt_en.jpg \
  --question "What is the first number of the store's phone number?" \
  --question "What is the street number in the store address?"
{ "record": { "phone": "4234929", "street": "732" },
  "forward_passes": 1,
  "answers": [ { "family": "phone",   "op": "front_1",   "answer": "4" },
               { "family": "address", "op": "street_no", "answer": "732" } ] }

Korean question, INT8:

python inference.py --model-dir . --precision int8 \
  --image examples/receipt_ko.jpg \
  --question "가게 전화번호의 뒤에서 1번째 숫자는 무엇입니까?" \
  --question "영수증의 가게 주소에서 도로명 뒤 숫자는 무엇입니까?"
{ "record": { "phone": "5008936", "street": "699" },
  "forward_passes": 1,
  "answers": [ { "family": "phone",   "op": "back_1",    "answer": "6" },
               { "family": "address", "op": "street_no", "answer": "699" } ] }

Both questions are served from the one forward pass that produced record. The router understands 앞에서 N번째, 뒤에서 N번째, 앞자리, 뒷자리, 끝자리, and the English ordinals.

A question outside the two supported fields routes to other and returns an empty answer rather than guessing:

python inference.py --model-dir . --image examples/receipt_ko.jpg \
  --question "상호명이 무엇입니까?"
{ "family": "other", "op": "unsupported", "answer": "" }

Check the bundled examples end to end:

python examples/test_examples.py

Input contract: grayscale, resized to 672x320 (width x height) with bilinear resampling, scaled to [0,1], then normalized (x - 0.5) / 0.5. The graph takes image as float32 [batch, 1, 320, 672] and returns slot_logits as float32 [batch, 16, 11]. Classes 0..9 are digits and class 10 is blank; read each group until the first blank. Slots 0..11 are the phone number and slots 12..15 are the street number.

Evaluation

2,000 held-out receipt questions, excluded from training, from checkpoint selection, and from quantization calibration.

precisionanswer_exacttarget_exactaddressphonefull phone readstreet
FP320.98750.96900.97770.99790.99400.9750
INT8 W8A80.98450.95850.97090.99900.99000.9670

answer_exact is the regex route plus index compared with the annotation answer. target_exact is stricter still: every phone digit and every street digit correct on the same receipt, whether or not the question asked for them. 131 of the 2,000 answers are right while the rest of the record is not, which is what the gap between the two columns measures.

Note that target_exact here is not the transformer baseline's target_exact. That one also required transcribing the full address text, which this model never attempts. The comparable pair is full phone read: 0.9194 for the transformer against 0.9574 here.

Runtime

onnxruntime CPU execution provider, one thread, batch 1. Timed on a shared host, so these are per-image minima over 9 runs; see eval/runtime_benchmark_*.json for medians as well.

precisionmedian msparameters
FP3234.62.46M
INT823.72.46M

Comparison with the transformer baseline

ivere27/tiny-receipt-vqa-structured-qa-21m is the encoder-decoder VQA transformer this model replaces. Both were measured on the same 2,000-item held-out split and the same CPU protocol (onnxruntime, one thread, batch 1).

VQA transformerthis model
parameters21.8M2.46M
answer_exact FP320.97250.9875
answer_exact INT80.97100.9845
full record read (target_exact)not comparable0.9690
address0.95350.9777
phone0.99280.9979
full phone-number read0.96180.9940
CPU latency FP32288.5 ms34.6 ms
CPU latency INT8173.7 ms23.7 ms
ONNX graphs2, plus a per-token decode loop1
tokenizerbyte-fallback BPE, 1536 tokensnone
passes for N questions on one receiptN encoder runs1, record cached

Same or better on every accuracy column at 8.9x fewer parameters and 8.3x lower latency.

Two caveats belong with that table.

The comparison favours this model by construction. The transformer answers eight question families — store name, item rows, item arithmetic, item lookup, and more. This model answers two. The held-out set happens to test only those two; on anything else this model returns an empty string. It is a specialist measured on a specialist's benchmark.

In one respect the comparison is conservative. The transformer's release notes describe its checkpoint as chosen by comparing two candidates on the held-out split. This checkpoint was chosen on schedule completion, without reference to held-out accuracy.

The transformer also transcribes the full address and store name, which this model never attempts. That subtask is where it struggles: its address transcription exact-match is 0.0155. Dropping it is what makes the small model both faster and, on digits, more accurate.

Quantization

model_int8.onnx quantizes convolutions only. The readout is deliberately left in float: it is about 5% of runtime, and quantizing its MatMuls costs six points of answer_exact and fifty-six of target_exact for 0.7 ms and 1.2 MB.

quantized opsanswer_exacttarget_exactsize
none (FP32)0.98750.96909.9 MB
Conv (shipped)0.98450.95854.1 MB
Conv,MatMul,Gemm0.92600.39902.9 MB
Conv,MatMul,Gemm,Add,Mul0.84750.05902.6 MB

The readout MatMuls are the attention itself — a softmax choosing among 420 grid cells — not a residual-wrapped feature transform, so quantization noise moves a slot to a different cell instead of averaging out.

Limitations

  • Reads two fields only: phone number and street number. Store names, item rows, and item arithmetic are out of scope.
  • The output alphabet is 0-9 plus blank. No text is transcribed, so full addresses and store names cannot be produced.
  • Input geometry is fixed at 672x320; the stem's final (2,1) stride ties the graph to that size.
  • question_router.py must ship with the model. The graph alone cannot answer a question.
  • Questions the router maps to neither phone nor address return an empty answer.
  • The evaluation annotations are machine generated, not human adjudicated.

Как запустить

На своей GPU в ailist. Цена — по текущим предложениям провайдеров

GPU в ailist

Универсальный рантайм · onnxruntime

Нельзя запустить

Модель выложена только в формате ONNX.

Ревизия весов
c9fa078

0 моделей