Как разработать систему автоматического разпознования бланков ответов тестирования?

Question

[elen milk]

Всем привет! начну с того, что я абсолютный новичок в IT. мельком слышала, что существуют алгоритмы распознавания текста и нейронные сети.
на работе у нас почти каждый месяц проводятся различные конкурсы для школ, в которых участвует ОГРОМНОЕ количество школьников. Ориентировочно: Минимум - 8 тыс., максимум - 30 тыс участников. И так каждый месяц. Ответы заполняются на стандартный бланк. И потом мы дружно всем офисом вручную проверяем эти тесты.
Вопросы:
1) Как можно автоматизировать процесс проверки тестов? можно ли для этого использовать обычный сканер и какой-нибудь алгоритм на основе тех же нейронных сетей?
2) и как можно это реализовать в виде программного продукта? какой язык/инструмент программирования использовать? (посоветуйте любой, так как все равно учить буду с нуля)
3) как связать сканер с кодом программы и оптимально ли это для такого потока тестов?
Подскажите в каком направлении копать и двигаться. буду благодарна за ссылки на полезный материал.

Answer 1

[Astrohas]

Работаю в центре тестирования, около 8тысячь бланок в неделю проверяем.
Для печати используем Bar Tender,
для сканирования используем - Abbyy Flexy Capture в связке с автоматическим сканером Kodak i222.
мой вам совет если бланки будут бумажные то не пытайтесь самому написать / форкунуть или что-то еще. Лучше и проще купить готовый софт который будет надежно работать, да и вам будет проще его обслуживать.

Comments

[elen milk]

спасибо большое! возможно предложу этот вариант.

Answer 2

[xmoonlight]

мельком слышала, что существуют алгоритмы распознавания текста и нейронные сети.
на работе у нас почти каждый месяц проводятся различные конкурсы для школ, в которых участвует ОГРОМНОЕ количество школьников.

Звучит как-то так: Вы знаете, мы тут в пещере, разводим костры и делаем орудия труда и наконечники для стрел из камня. Нам бы сделать мобильную связь и пару дронов с автоматическим обнаружением крупной добычи с помощью инфракрасного сканирования местности, т.к. действия племени во время охоты на мамонта координировать не очень удобно: много затрачивается сил.

Сейчас 2018 год! У всех мобильные телефоны и планшеты. В чем проблема создать приложение и выдвинуть требования установить его для полноценного проведения тестирования и сбора ответов школьников?

Вот что-то вменяемое: www.eyegrade.org
Github (исходники на Python'е): https://github.com/jfisteus/eyegrade/

Comments

[Артемий]

Нельзя использовать устройства тестируемых, так как они могут спокойненько свернуть тест и развернуть Google.
(не ну как-бы и так, и так можно, но по Вашему уж совсем не палевно списать получится)

[elen milk]

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

[xmoonlight]

Yumi Etsu, если про распознавание - начинайте с нуля.

[elen milk]

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

[xmoonlight]

Yumi Etsu, а про списать - можно сделать тайм-аут на ответ для каждого вопроса, а время на сервере контролировать. никто не успеет посмотреть и списать, даже если рядом будет полноценный компьютер с клавиатурой.

[xmoonlight]

elen milk, камеру такую где-то нужно, чтобы было быстрее: линк

[Alex Wells]

elen milk, помимо технической части, с чего вы взяли, что если начальство против интернет-тестирования, то оно разрешит автоматическую проверку? Оно же в 100% случаев выйдет в разы дороже, сложнее и менее точно, чем интернет тестирование..

[elen milk]

спасибо за ссылки. не надеялась уже на внятный совет.

[xmoonlight]

elen milk, не за что... если выберите решением ответ - будет вообще круто!)

Answer 3

[Alexander Litvinenko]

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

Начнем немного с термина "нейронная сеть". Нейронная сеть если совсем упростить, это что-то вроде каталога связей, к тестам никакого отношения не имеет, если читали о теории графов то графы самый класический пример работы нейронной сети, но в основном это просто словечко маркетологов, потому что термин нейронная сеть может подразумевать тысячи разных алгоритмов и про какой конкретно идет речь - совершенно непонятно.

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

Что до самих тестов, это достаточно несложно, тут трудности будут с количеством одновременных участников, но и это решаемо, скорее всего помогут высокопроизводительные технологии вроде Node.js и WebSocket, могу предложить услуги своей команды для этого.

Что до самостоятельного изучения материала по этой теме, очень много учить чтобы за раз охватить всю подноготную, самостоятельно - максимум простой сайт с тестом, о более продвинутых вариантах и думать нечего.

Comments

[Alex Wells]

node.js - высокопроизводительный?
websocket для проверки тестов?

Вы об интернет тестировании надеюсь, а не о проверке анкет..

[Alexander Litvinenko]

Alex Wells, я опущу реплику про "node.js - высокопроизводительный", если есть желание, про нее поговорим отдельно. Поскольку я так понимаю вы пхпешник и особо с ней не работали, разговор будет сложным и холиварным.

давайте подумаем логично, что до websocket:
Технология нативна? - да
Технология требует каких-то особых ухишрений для использования - нет
Есть какието предпосылки почему она не может быть использована наравне\вместо например с аякс? - нет
Удобнее аякс? - да
А аякс вы используете вплоть до простейщих лендингов? - да

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

[Alex Wells]

Alexander Litvinenko, я работал с ней "особо", даже прямо сейчас на ней пишу. Она производительней php, если тот зафигачен как есть и не настроен, да. Но я про пхп ни слова не говорил. Я говорил о картине в общем.

Держать сервера, обслуживающие десятки (а может и сотни) тысяч клиентов одновременно на ноде - бред.

"Удобнее аякс? - да" - не верно. При обычных http запросах, которые ничем не медленней вебсокетов, у нас есть фичи фреймворков, типа мидлвейров, валидации, форматирования респонса и тд. При этом такое приложение в любом случае нужно, а значит в сокет сервере у вас либо вообще не будет валидации входящих запросов, либо будет сделана "на коленке".

HTTP запросы, которые обычные, намного удобней для вещей, не связанных с риал-таймом. Более того, даже при разработке риал тайм вещей, я по максимуму делаю все запросы на http бекенд, а если надо - шарю инфу клиентам через сокет сервер в риал тайме.

Но в нашем случае нам риал тайм не нужен, нативный ws - ужасен, надстройки на ws - некоторые хороши, но это даже и близко не фреймворки. Итого получаем кучу велосипедов в ws.

Так что не "нельзя", а "неудобно".

[Alexander Litvinenko]

Alex Wells, стойте, я о пхп ничего не говорил.

обслуживающие десятки

Я держу десятки на игровом сервере и все нормально, но да, это не всегда возможно, в ряде случаев надо идти на более сложные решения, но это верно для любой технологии. Более того на нагрузочном тестировании, при обработке статики мы доходили до милиона запросов на 15 минут, полет нормальный.

"Удобнее аякс? - да" - не верно? При обычных http запросах, которые ничем не медленней вебсокетов, у нас есть фичи фреймворков, типа мидлвейров, валидации, форматирования респонса и тд. При этом такое приложение в любом случае нужно, а значит в сокет сервере у вас либо вообще не будет валидации входящих запросов, либо будет сделана "на коленке".

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

HTTP запросы, которые обычные, намного удобней для вещей, не связанных с риал-таймом...

- формат запрос - ответ также работает на ws, в чем проблема?

Но в нашем случае нам риал тайм не нужен, нативный ws - ужасен

ну окей, если ненравиться нативный, возьмите socket.io, чем он плох?

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

[Alex Wells]

Alexander Litvinenko,

стойте, я о пхп ничего не говорил.

Вы назвали меня "пхппешником" и продолжили в том же духе)

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

Мы не в 2010, уже как три года юзают HTTP/2, которому не нужны реконекты)

вы же не хотите сказать что на веб сокетах этого нету?

Хочу. Найдите socket фреймворк, совмещающий все вышеуказанное.

- формат запрос - ответ также работает на ws, в чем проблема?

Я вообще ничего об этом не говорил)

ну окей, если ненравиться нативный, возьмите socket.io, чем он плох?

Да ничем не плох. И SocketCluster не плох. Но для своих целей - раздачи данных клиентам. Запросы же УДОБНЕЙ обрабатывать с помощью обычных http серверов, которые часто совмещены с фреймворками. Именно их и нужно использовать в разработке.

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

Опять же, это не удобно. Не вижу смысла вообще использовать веб сокеты если не нужен риал тайм (а он не нужен), опять же, потому что не удобно по вышеуказанным причинам.

[Alexander Litvinenko]

Alex Wells, Верно, назвал, хорошо принимаеться, однако я всеже возждержусь от коментариев про пхп.
Поверьте, у вас всеже затрачиваеться время на установку соеденения, это легко проверить любым dev tools.
Вот Socket.io, имеет миделвейры, а с них вытекает как следствие и все остальное, и с express он совместим, и без него норм работает. И как вы сказали есть и аналоги, впрочем не скажу насколько хорош каждый из них.
У веб сокетов больше возможностей по сравнения с аякс, это касаеться не только реал тайм. Зачем же мне использовать ограниченную технологию, если можно ее не использовать?

я извиняюсь перед elen milk за то что мы тут развели, у пхп очень давняя нелюбовь вебсокетов, в то время как у ноды с ними любовь во всем проявлении, в то время я немогу сказать что пхп плохая технология, или что Alex Wells совсем не прав, но покаместь этот разгновор еще не перешел в конструктивное русло и это мы еще про саму ноду не вспомнили.

[xmoonlight]

Alexander Litvinenko, про мягкий знак в словах - ну это жесть! Подучи правила... Вот простое детектирование (это не правило!)
Alexander Litvinenko, Alex Wells, про ноду и PHP: в данном случае вообще без разницы что юзать и как реализовать.
Главное о чём нужно помнить: если один сервер и туча народа не держать соединения открытыми тогда, когда это не требуется.

Поэтому, если сделать SPA (однократная загрузка и кеширование кода приложения на клиенте) и накопление результатов, а лишь в конце теста - POST-отправку данных - это будет самым оптимальным вариантом.

И напоследок: https://www.swoole.co.uk/

Node.js v4.2.6
wrk -t4 -c400 -d10s 127.0.0.1:1337
Running 10s test @ 127.0.0.1:1337
4 threads and 400 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 16.08ms 2.70ms 237.82ms 90.94%
Req/Sec 6.05k 510.34 7.10k 91.00%
240668 requests in 10.02s, 46.36MB read
Requests/sec: 24026.00
Transfer/sec: 4.63MB

PHP7.1+Swoole-v1.9.5
wrk -t4 -c400 -d10s 127.0.0.1:1337
Running 10s test @ 127.0.0.1:1337
4 threads and 400 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.46ms 1.42ms 27.96ms 85.66%
Req/Sec 75.29k 36.43k 183.55k 72.75%
3007806 requests in 10.06s, 605.25MB read
Requests/sec: 299103.32
Transfer/sec: 60.19MB

[Alex Wells]

xmoonlight, да, я знаю что php производительней, если правильно написать приложение, правильно настроить фреймворк, на котором оно написано, правильно настроить сервер и веб-сервер, подключить какой-нибудь opcache и запросы будут за миллисекунды обрабатыватся) Просто решил об этом не упоминать, так как разговор, все таки, не об этом)

[xmoonlight]

Alex Wells, да я в раз так и подумал! )
Кстати, вот как оптимально: можно софтину на мобилу учителю, чтобы она засканила сразу все собранные с учеников только что заполненные тесты в цифровой вид камерой и отправила на серв. А на серве уже - распознать.

[Alexander Litvinenko]

xmoonlight, увы я не учил в школе русский. что до соединений, вы сделали правильное замечание. К тесту стоилобы добавить описание как имено тестировали, тогда можно сделать и выводы.
Alex Wells, "если правильно написать..., правильно настроить... " и еще 6 правильно для того чтобы запросы "обрабатывались миллисекунды", и они всеравно не будут обрабатываться миллисекунды, точно вам говорю.

[Alex Wells]

Alexander Litvinenko, что вы мне точно говорите?) Есть сотни тестов, где проекты на laravel/symfony загружаются за миллисекунды.

И да, на продакшене, если вы не знали, ВСЕГДА нужно ИДЕАЛЬНО настраивать и оптимизировать вообще все, что можно. Вон даже выше пример.

[Alexander Litvinenko]

Alex Wells, покажите.

Answer 4

[Артемий]

Самый лучший вариант - перевести конкурсы в рамки интернет-тестирования. Для этого можно те же Google Формы использовать, либо подобные сервисы.

Если же пробить голову начальства не получится (а попробовать при таких объёмах точно стоит), то помимо работы с графикой придётся изучать СУБД. Реализацию подсказать не готов, но думаю, что тут и без нейросетей можно обойтись, если ответы всегда одинаково плотно закрашиваются.

Answer 5

[Dimonchik]

ABBY продукты тебя спасут

как гонять через них данные - второй вопрос

Answer 6

[vism]

Ох уж эти наивные инициативные сотрудники в гос/контрактных структурах

Вы понимаете, что если начальство внедрит автоматизацию, оно потеряет КУЧУ денег.
Конечно вам будут обещать и хвалить вас, но...

Бегите оттуда пока не убили вашу инициативность.