24 марта 2026 года компания Smart Engines сообщила о получении американского патента на технологию ИИ, которая исключает «галлюцинации» — случаи, когда система распознавания документов додумывает символы, которых нет в исходном изображении. Технически это означает переход от «доверяй выходу модели» к «проверяй выход модели по формальным признакам». Причина проста: при плохом качестве скана или фотографии нейросеть уверенно выдаёт правдоподобный, но неверный результат — и в банковском, страховом, кадровом документообороте это стоит реальных денег.
Для выпускника ИТ-направления это не новость из мира стартапов, а готовая рамка для дипломного проекта. Защищаемость ВКР сегодня определяется не тем, какая модель у вас внутри, а тем, умеете ли вы доказать её надёжность: воспроизводимые метрики, контроль ошибок, деградация вместо отказа. Ниже — как встроить этот сюжет в структуру работы и не утонуть в терминах.
| Тема | Цель | Задачи (сокращённо) | Структура |
|---|---|---|---|
| Модуль постобработки и валидации результатов OCR для систем электронного документооборота | Снизить долю недостоверных распознаваний за счёт проверки выходных данных по формальным правилам и справочникам | 1) Обзор методов распознавания и типов ошибок; 2) формализация правил валидации (контрольные суммы, словари, регулярные структуры); 3) реализация валидатора и порогов уверенности; 4) оценка снижения доли ошибок | Гл. 1 — анализ OCR-стеков и проблемы галлюцинаций; Гл. 2 — архитектура конвейера «распознавание → валидация → маршрутизация»; Гл. 3 — эксперимент на корпусе документов и расчёт эффекта |
| Оценка надёжности нейросетевых компонентов по ISO/IEC 25010 в прикладной системе | Построить методику измерения надёжности и отказоустойчивости ИИ-компонента | 1) Выбор характеристик качества по ISO/IEC 25010; 2) метрики: точность, полнота, калибровка уверенности, доля отказов; 3) нагрузочное тестирование через OpenTelemetry и Prometheus; 4) расчёт RTO/RPO для сервиса | Гл. 1 — теория надёжности ПО и стандарты; Гл. 2 — стенд, архитектура сбора метрик; Гл. 3 — результаты замеров и выводы по эксплуатации |
| Сервис приёма и обработки документов с контролем качества входных данных (Kubernetes + CI/CD) | Спроектировать отказоустойчивый сервис, который отбраковывает непригодные изображения до этапа распознавания | 1) Анализ причин низкого качества входных данных; 2) проектирование API (REST/gRPC) и препроцессинга; 3) развёртывание в Kubernetes, автоскейлинг; 4) тестирование и оценка стоимости владения | Гл. 1 — анализ предметной области и аналогов (в т.ч. решения Smart Engines); Гл. 2 — проектирование: диаграммы компонентов, последовательностей, схемы данных; Гл. 3 — нагрузочные тесты, экономика внедрения |
Все три темы объединяет одно: вы защищаете не «модель», а инженерное решение вокруг неё. Именно это ценят комиссии, и именно здесь проще всего показать измеримый результат.
В первой главе не нужно писать реферат про нейросети. Постройте сравнительную таблицу методов и покажите, почему выбранный вами сочетается с условиями задачи (объём потока, требования к задержке, стоимость инфраструктуры).
| Подход | Что даёт | Ограничение | Когда выбирать |
|---|---|---|---|
| Постобработка по формальным правилам (справочники, контрольные суммы, шаблоны полей) | Ловит структурно невозможные значения дешево | Не помогает при ошибке в свободном тексте | Документы со строгой структурой: счета, бланки, паспортные данные |
| Порог уверенности модели (confidence threshold) + ручная верификация | Простая деградация: сомнительное — оператору | Растёт нагрузка на операторов | Когда цена ошибки выше цены проверки |
| Ансамбль / повторное распознавание с другим препроцессингом | Снижает случайные ошибки | Кратно увеличивает время и стоимость вычислений | Небольшой поток, критичные документы |
| Языковая модель-верификатор поверх распознанного текста | Находит смысловые несоответствия | Сама может галлюцинировать; нужен отдельный контроль | Когда документы содержат связный текст и терминологию |
Обязательная часть аналитической главы — обзор исходного решения из новости: патент Smart Engines описывает отказ от «додумывания» на уровне самого движка распознавания. Сравнив его с вашим подходом (внешняя валидация), вы получаете честное обоснование: либо вы повторяете идею на другом уровне, либо дополняете её.
Вторая глава — это схемы. Комиссия читает их быстрее, чем текст, поэтому каждая диаграмма должна отвечать на конкретный вопрос: где данные, где логика, где отказ.
Поток обработки документа:
[Загрузка] → [Препроцессинг: кроп, бинаризация, оценка резкости]
→ [OCR-движок] → {confidence < порога?}
├── да → [Валидатор: справочники + контрольные суммы]
│ ├── проверка пройдена → [Маршрут: оператор]
│ └── не пройдена → [Отказ с кодом причины]
└── нет → [Сохранение результата + аудит]
Обратите внимание на ключевую деталь: у системы должен быть явный отказ. Именно явный отказ, а не «примерно верный ответ», отличает инженерное решение от демонстрации модели. Зафиксируйте в проектной части коды ошибок, формат журнала аудита и политику повторных попыток — это те детали, за которые ставят «отлично».
Опишите контракты: какие поля обязательны, что происходит при таймауте внешнего сервиса, как версионируется API. Полезно привести фрагмент спецификации OpenAPI и показать, что отказ валидации — это штатный сценарий, а не исключение.
Здесь недостаточно одной accuracy. Соберите набор метрик под вашу задачу и обязательно приведите формулу и способ замера.
| Метрика | Инструмент замера | Что доказывает на защите |
|---|---|---|
| Доля недостоверных извлечений | Размеченный корпус, скрипт сравнения | Снижение ошибок относительно базового OCR |
| p95 времени обработки | OpenTelemetry-трейсы | Пригодность к промышленной нагрузке |
| RTO/RPO | Сценарий с принудительным падением пода | Управляемость отказов, а не только «работает» |
| Экономия трудозатрат | Замеры времени оператора до/после | Практическая ценность внедрения |
Типичные ошибки, которые режут оценку
Нет. Сильная работа может быть построена на готовом движке распознавания: ваша новизна — в слое валидации, метриках надёжности и архитектуре сервиса. Комиссия оценивает вклад автора, а не количество обученных слоёв.
Используйте синтетические генераторы бланков, открытые датасеты документов и публичные примеры форм. Обязательно опишите процедуру обезличивания и то, как корпус отражает реальное распределение: типы документов, доли дефектов съёмки (блики, перекос, низкое разрешение).
Достаточно трёх-четырёх: компонентов, последовательностей, развёртывания и, при необходимости, деятельности для алгоритма валидации. Каждая диаграмма — с легендой и ссылкой на текст, где она обсуждается. Диаграммы без пояснений в тексте считаются иллюстративным шумом.
На уровне сути: какую проблему решает, какой подход предлагает, чем ограничен. Если работы по теме много, а времени мало, разумно делегировать часть рутины — помощь с дипломом часто начинается именно с разбора таких первоисточников и выстраивания логики работы.
Если разбор архитектуры, метрик и оформления занимает больше времени, чем сама разработка, — это сигнал. Мы берём на себя трудоёмкие части: от анализа источников и проектирования до финального оформления по стандартам. Первая консультация бесплатная, поможем с любой темой — от OCR-конвейеров до оценки надёжности ИИ-сервисов.
Источник: Российские ученые получили американский патент на ИИ для исключения галлюцинаций (опубликовано 2026-03-24)