Технічний контекст
Я люблю такі кейси більше, ніж красиві демо. В обговоренні якраз спливло те, що я регулярно бачу в реальній AI implementation: маленька VLM-модель на кшталт E4B здається «сильною», але на автомобільних номерах стабільно плутає схожі символи. M та N, 6 та 9, плюс місцями не тримає структуру відповіді.
І це не виглядає дивно. Якщо картинка на вході сильно скейлиться, модель фізично втрачає дрібні деталі. Для номера це смертельно: один штрих зник, і літера вже інша.
Мені тут сподобалася не скарга, а інженерна думка з треду. Не намагатися вибити з моделі ідеальний OCR одним промптом, а зібрати пайплайн: спочатку знайти зону номера, потім кропнути, потім визначити країну та формат, а вже після цього читати символи не цілком, а по шматках.
Я б робив це саме так. Спочатку bounding box або хоча б груба локалізація. Потім окремий прохід на шаблон виду AA 1234 або AB 12 CD. Потім послідовне читання груп, де модель не розмазує увагу по всій картинці.
Ще один важливий момент: якщо модель погано дотримується формату відповіді, не треба сперечатися з нею в одному запиті. Я зазвичай ріжу завдання на кроки і змушую кожен крок віддавати дуже вузький JSON. Це не магія, це просто нормальна AI integration замість надії на «ну зараз точно зрозуміє».
Дешевий файнтюнінг тут теж звучить логічно, якщо у вас багато однотипних номерів, камер та країн. Але я б не починав з нього. Поки не зібрано чіткий багатокроковий контур, файнтюнінг часто лише маскує архітектурну проблему.
Вплив на бізнес та автоматизацію
Для продакшену висновок простий: один VLM-виклик на весь кадр не дорівнює надійному OCR. Якщо помилка б'є по шлагбауму, штрафу, парковці чи логістиці, потрібен pipeline-first підхід, а не «універсальна мультимодальна модель все сама зробить».
Виграють команди, які вміють розкласти завдання на етапи та міряти confidence по кожному кроку. Програють ті, хто будує критичний процес на одній сирій відповіді моделі.
Я в себе дивлюся на це як на AI solutions architecture, а не як на вибір чергової модної моделі. У Nahornyi AI Lab ми якраз такі речі й збираємо для клієнтів: де потрібен кроп, де валідація формату, де fallback на другий прохід, а де вже дійсно варто будувати AI automation навколо VLM, щоб вона економила час, а не створювала ручну перевірку поверх ручної перевірки.
Якщо у вас схожа історія з документами, номерами або дрібним текстом на фото, можна швидко пройтися по вашому пайплайну та знайти, де модель втрачає сигнал. Зазвичай проблема не в «поганому AI», а в тому, що йому дали завдання занадто широким шматком. Це якраз той випадок, де Nahornyi AI Lab може зібрати спокійну робочу схему замість ще однієї красивої, але крихкої демки.