ИИ-распознавание рукописных заметок должно возвращать сомнительный фрагмент автору

Для перевода почерка в текст свой распознаватель писать с нуля не требуется. Handium и Rehand описывают такую функцию на своих сайтах.

На Handium уже описаны редактор рядом с оригиналом и подсветка сомнительных слов. Rehand предлагает распознавание и API для интеграции; это заявления сервисов на 8 октября 2026.

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

Учебный пример: сотрудник написал «зазор 1,5 мм», а распознаватель выдал «15 мм». Это пример требования к модулю, не случай у нашего клиента.

Автору показывают строку на фото вместе с соседними словами и предложенное значение. Если смысл сокращения неясен, он открывает весь снимок.

Оценка уверенности помогает найти сомнение, но не разрешает использовать критичное число. Microsoft описывает ручную проверку по таким оценкам; правило подтверждения задаёт компания.

Владельцу нужно заранее назначить человека, который может подтвердить запись. Автор осмотра знает, что измерял; диспетчер видит лишь фотографию.

Автор выбирает подтверждение, правку или «не могу восстановить». При недоступном авторе диспетчер назначает уточнение или повторный осмотр, а не заполняет поле догадкой.

Ответственность за ошибку распределяют до запуска. Модуль должен записать, кто принял значение, по какому снимку и когда.

Мы проверяли выводы машины агентов сайта, а не почерк выездных сотрудников. Этот опыт объясняет, какие ошибки проверка должна остановить.

Проверка ищет опору в исходнике, а не правдоподобие ответа. Грамотная фраза и заполненная таблица ещё не доказывают, что источник удалось прочитать.

В рукописной заметке действует тот же запрет догадки. «Не прочитано» сохраняют отдельным состоянием, а исходное фото оставляют рядом с расшифровкой.

Первая задача для агента описывает весь путь заметки. Инженер ведёт машину агентов: от загрузки фото до подтверждения поля и передачи результата.

Для приёмки берут записи разных сотрудников с размытыми строками, сокращениями и исправлениями. Автор заранее фиксирует верное прочтение либо отмечает, что восстановить его нельзя.

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

Для разработки данные сотрудников и клиентов заменяют обезличенными примерами. Разработчику важны структура записи и почерк, а не контакты заказчика.

Пользу считают по всему пути до принятой записи. Учитывают время расшифровки, ответы авторов и исправления; быстрый черновик с долгой проверкой не означает экономию.

Каждое исправление пополняет набор проверочных примеров. Следующую версию модуля прогоняют по прежним ошибкам: замечание сотрудника становится проверкой, а не забытым сообщением.

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

На 8 октября 2026 разработка по подписке, тариф «Один проект», стоит 250 000 ₽ в месяц. Инженер с машиной агентов сдаёт правки в репозиторий клиента, одна задача в работе, пауза в любой месяц.

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

Если перед заказом нужно разобрать, кто ставит задачу и кто принимает результат, откройте тест для руководителя. Адрес сейчас ведёт на страницу услуг.

1. Расшифровка остаётся черновиком. Передавайте критичные поля в работу после подтверждения автора.
2. Проверяют исходную строку. Покажите фрагмент, соседние слова и возможность открыть весь снимок.
3. Отсутствие ответа сохраняет очередь. Назначьте уточнение вместо автоматического подтверждения.
4. Пилот проверяют на трудных записях. Измерьте время до принятого результата вместе с исправлениями.
5. Ошибка должна вернуться в проверку. Сохраняйте причину правки и включайте пример в следующий прогон.