Вы абсолютно правы в отношении 15-й версии. ContentReader PDF 15 действительно был модифицированной версией FineReader. Мы этого никогда не скрывали и открыто писали об этом на сайте и в блоге на Хабре.
Но данная новость — про ContentReader PDF 16, и это уже совершенно другая история. Новая версия проектировалась с нуля: в материале есть скриншоты обновленного интерфейса и описание новой функциональности, где различия видны невооруженным глазом.
Что касается совпадения базового набора инструментов, то это вполне естественно для продуктов одного класса, между любыми двумя PDF-редакторами на рынке найдется немало общего.
ContentReader PDF 16 — это разработка компании Content AI. Он не имеет никакого отношения к FineReader. Это разные решения, созданные разными компаниями независимо друг от друга. Продукты отличаются архитектурой, интерфейсом, набором и логикой функциональности. ContentReader PDF изначально создавался с ориентацией на российский рынок и его специфику. Это не переименование и не локализация чего-либо существующего.
Да, это именно собственная разработка. Когда мы сопоставили прошлые версии с современными требованиями, стало очевидно, что точечными доработками далеко не уйти. Нужно было полностью переосмыслить логику и пользовательский опыт. Старая архитектура порождала зависимости, в которые мы неизбежно упирались бы при масштабировании новой функциональности. Поэтому ContentReader PDF 16 проектировался с нуля под требования современного пользователя.
Михаил, благодарим за развернутый рассказ о проделанной работе! Для нас сотрудничество с РСХБ – это действительно ценный опыт. Рады, что наш продукт помогает закрывать задачи обработки документов во всех филиалах банка, и признательны вашей команде за высокий профессионализм при развертывании решения.
Добрый день! При использовании промта на английском для извлечения данных из судебных документов наши замеры показали небольшое улучшение качества. В целом, результаты зависят от модели: в одних случаях лучше обрабатывается русский язык, в других — английский.
Спасибо большое за видео, посмотрели его. Интересно, что у ребят в новой схеме нет чистых ПМов / scrum-мастеров, если мы правильно поняли их схему, а просто линейка engineering manager / tech lead.
У нас команда разработки существенно меньше, чем в Dodo, и мы пока тестируем разные управленческие гипотезы. Сейчас как раз думаем, надо ли добавлять в команду новые роли и какие именно, и Ваш вопрос на самом деле ложится в наши размышления. Так что благодарим Вас за то, что поделились опытом и мыслями.
Commitment – сколько задач взяли в спринт и сколько завершили (лучше брать меньше, но доделывать).
Velocity (на длинных отрезках времени) – сколько сделали за квартал и попало в релиз.
Эти метрики считаем полезными. Они показывают важные тенденции, но на них влияет множество факторов: экстренные задачи у клиентов, пачка новых задач, отпуска, праздники. В целом показатели растут, но выделить влияние отдельного элемента/управленческого решения – сложно.
Насчет передачи управления мидл-менеджерам: считаем, что у такого подхода есть минусы. Мидл-менеджеры часто задают много вопросов для восстановления контекста. По нашему опыту, многие PM и Agile-коучи засыпали команды банальными вопросами, но не помогали продвигать дискуссию. Поэтому в опытных командах, скорее, нужен technical manager с хард скиллами и опытом разработки. Учитывая размер наших команд, мы решили, что эффективнее, чтобы лиды взяли эту роль на себя.
А какой у Вас опыт распределения ролей в командах?
Мы считаем PassThroughRate (PTR) как долю документов, которые не требуют верификации:
Было: 310 документов (по технологии "нейропаспорт")
Стало: 428 документов (по новому механизму)
Прирост: +118 документов (рост на ~38% относительно исходного PTR)
Такой расчет удобен, потому что PTR показывает, насколько реже теперь нужно проверять документы вручную. Именно это важно для пользователей: система стала чаще пропускать документы без дополнительных действий.
Расчет от общего числа документов (1017шт) тоже корректен, но он отражает общий охват, а не эффективность самого механизма пропуска.
Наши нейросети — это часть технологии. Они небольшие и специализированные. Для их использования не нужны видеокарты, достаточно обычного среднего процессора, поэтому они работают на любом компьютере средней мощности.
При разработке мы всегда придерживаемся продуктового подхода: прежде чем начать что-то делать, обязательно собираем обратную связь от рынка.
Вы правы: тема валидации печатей действительно кажется узкоспециальной. Но, как ни странно, спрос на такую фичу есть — и вот почему. Крупный бизнес даже при наличии ЭДО до сих пор массово требует, чтобы документы были оформлены по форме и на них стояла печать организации, которая их выпустила. Да, юридически это не обязательно, но на практике — требуется. И если клиенту (пусть и не каждому, но нашему) это нужно — мы делаем.
Мы наблюдаем, что даже с развитием ЭДО количество бумажных документов не уменьшается. Хотя прогнозы о стопроцентном переходе бизнеса на электронный документооборот и о том, что «бумага умрет», слышим уже последние десять лет.
На самом деле, экспериментируя с WSJF, мы пришли к выводу, что для нас такой подход не подходит из-за недостаточной гибкости. А именно — из-за ситуаций, когда клиенты «трясут перед носом продакта кошельком», и в верхнюю часть бэклога попадают фичи, которые, хоть и несут ценность для пользователей и прибыль для компании, не всегда соответствуют стратегии развития продукта.
Чтобы решить эту проблему, мы попытались добавить в числитель формулы набор поправочных коэффициентов, оценивающих соответствие фичи продуктовой стратегии. Например, если в стратегии развития продукта есть вектор «высокая скорость обработки документов пользователями», мы вводим коэффициент:
1 — если фича не соответствует стратегии,
2 — если соответствует.
Другой пример — вектор «расширение использования ИИ-технологий при обработке документов». Если он важнее предыдущего, то коэффициенты могут быть выше:
1 — не соответствует стратегии,
3 — соответствует (используем 3, так как его важность в стратегии выше, чем скорость обработки).
Затем сумму всех критериев соответствия мы умножаем на Cost of Delay (в числителе).
Важно отметить, что калибровка весовых коэффициентов сильно зависит от специфики компании, продукта и количества пользователей.
Спасибо за пояснительный комментарий! Со своей стороны можем лишь подтвердить ваши слова и добавить несколько слов о продукте.
ContentReader PDF – многофункциональный редактор, который включает широкий набор инструментов для работы с файлами PDF и предоставляет возможность решать различные задачи редактирования текста внутри одного приложения.
Продукт имеет подтвержденную совместимость с ОС Astra Linux, Альт ОС, РЕД ОС, и потому может быть интегрирован в ИТ-ландшафт, построенный на российском софте.
ContentReader PDF входит в реестр отечественного ПО и рекомендован для замещения иностранного софта для просмотра и редактирования PDF-документов.
Мы не ставили перед собой такой цели, поэтому можем предположить, что сейчас с такими текстами работать будет плохо, хотя бы потому что это специфические документы, и сеть их никогда не видела. При этом техническая возможность доучить сеть конечно есть. Напишите нам в личку, если перед вами стоит такая задача, обсудим вопрос более предметно :)
ContentReader — одно из лучших решений для редактирования PDF и OCR на рынке, как по набору возможностей, так и по качеству их реализации. Конечно, всегда есть к чему стремиться, и ошибки по ходу разработки в том числе и мы, конечно, совершали.
Что касается рукописного текста: замеры качества распознавания, на которые мы полагаемся, проведены на выборке из разнообразных рукописных документов, которые написаны разными людьми, разным почерком. Решение ContentCapture, в которое встроено распознавание рукописного, служит для автоматизации ввода данных из потока документов, и результаты, про которые мы говорим, это то, что можно ожидать на таком потоке.
А 30 лет назад, когда только пошли первые ПК, появились первые OCR для печатного текста :) Здесь главный вопрос в качестве (эта оговорка есть дальше по тексту), которое даже для печатного текста до сих пор улучшается. А про американскую почту есть любопытная статья, где в том числе рассказывается про качество распознавания: https://habr.com/ru/companies/timeweb/articles/709240/
Все верно, это следующий этап в развитии данной продуктовой линейки.
Вы абсолютно правы в отношении 15-й версии. ContentReader PDF 15 действительно был модифицированной версией FineReader. Мы этого никогда не скрывали и открыто писали об этом на сайте и в блоге на Хабре.
Но данная новость — про ContentReader PDF 16, и это уже совершенно другая история. Новая версия проектировалась с нуля: в материале есть скриншоты обновленного интерфейса и описание новой функциональности, где различия видны невооруженным глазом.
Что касается совпадения базового набора инструментов, то это вполне естественно для продуктов одного класса, между любыми двумя PDF-редакторами на рынке найдется немало общего.
ContentReader PDF 16 — это разработка компании Content AI. Он не имеет никакого отношения к FineReader. Это разные решения, созданные разными компаниями независимо друг от друга. Продукты отличаются архитектурой, интерфейсом, набором и логикой функциональности. ContentReader PDF изначально создавался с ориентацией на российский рынок и его специфику. Это не переименование и не локализация чего-либо существующего.
Да, это именно собственная разработка. Когда мы сопоставили прошлые версии с современными требованиями, стало очевидно, что точечными доработками далеко не уйти. Нужно было полностью переосмыслить логику и пользовательский опыт. Старая архитектура порождала зависимости, в которые мы неизбежно упирались бы при масштабировании новой функциональности. Поэтому ContentReader PDF 16 проектировался с нуля под требования современного пользователя.
Все верно, и это не секрет. Мы лицензировали технологии на некоторый период, а также полностью выкупили права на отдельные продукты.
Вы правы, ABBYY разработала FineReader. А CuneiForm - продукт основного конкурента ABBYY на тот момент (Cognitive Technologies).
Михаил, благодарим за развернутый рассказ о проделанной работе! Для нас сотрудничество с РСХБ – это действительно ценный опыт. Рады, что наш продукт помогает закрывать задачи обработки документов во всех филиалах банка, и признательны вашей команде за высокий профессионализм при развертывании решения.
Добрый день! При использовании промта на английском для извлечения данных из судебных документов наши замеры показали небольшое улучшение качества. В целом, результаты зависят от модели: в одних случаях лучше обрабатывается русский язык, в других — английский.
Добрый день! Все данные на картинках фейковые, мы не использовали настоящие судебные документы
Спасибо большое за видео, посмотрели его. Интересно, что у ребят в новой схеме нет чистых ПМов / scrum-мастеров, если мы правильно поняли их схему, а просто линейка engineering manager / tech lead.
У нас команда разработки существенно меньше, чем в Dodo, и мы пока тестируем разные управленческие гипотезы. Сейчас как раз думаем, надо ли добавлять в команду новые роли и какие именно, и Ваш вопрос на самом деле ложится в наши размышления. Так что благодарим Вас за то, что поделились опытом и мыслями.
Добрый день. Мы измеряем две метрики:
Commitment – сколько задач взяли в спринт и сколько завершили (лучше брать меньше, но доделывать).
Velocity (на длинных отрезках времени) – сколько сделали за квартал и попало в релиз.
Эти метрики считаем полезными. Они показывают важные тенденции, но на них влияет множество факторов: экстренные задачи у клиентов, пачка новых задач, отпуска, праздники. В целом показатели растут, но выделить влияние отдельного элемента/управленческого решения – сложно.
Насчет передачи управления мидл-менеджерам: считаем, что у такого подхода есть минусы. Мидл-менеджеры часто задают много вопросов для восстановления контекста. По нашему опыту, многие PM и Agile-коучи засыпали команды банальными вопросами, но не помогали продвигать дискуссию. Поэтому в опытных командах, скорее, нужен technical manager с хард скиллами и опытом разработки. Учитывая размер наших команд, мы решили, что эффективнее, чтобы лиды взяли эту роль на себя.
А какой у Вас опыт распределения ролей в командах?
Здравствуйте!
Мы считаем PassThroughRate (PTR) как долю документов, которые не требуют верификации:
Было: 310 документов (по технологии "нейропаспорт")
Стало: 428 документов (по новому механизму)
Прирост: +118 документов (рост на ~38% относительно исходного PTR)
Такой расчет удобен, потому что PTR показывает, насколько реже теперь нужно проверять документы вручную. Именно это важно для пользователей: система стала чаще пропускать документы без дополнительных действий.
Расчет от общего числа документов (1017шт) тоже корректен, но он отражает общий охват, а не эффективность самого механизма пропуска.
Здравствуйте.!
Наши нейросети — это часть технологии. Они небольшие и специализированные. Для их использования не нужны видеокарты, достаточно обычного среднего процессора, поэтому они работают на любом компьютере средней мощности.
Здравствуйте!
При разработке мы всегда придерживаемся продуктового подхода: прежде чем начать что-то делать, обязательно собираем обратную связь от рынка.
Вы правы: тема валидации печатей действительно кажется узкоспециальной. Но, как ни странно, спрос на такую фичу есть — и вот почему. Крупный бизнес даже при наличии ЭДО до сих пор массово требует, чтобы документы были оформлены по форме и на них стояла печать организации, которая их выпустила. Да, юридически это не обязательно, но на практике — требуется. И если клиенту (пусть и не каждому, но нашему) это нужно — мы делаем.
Мы наблюдаем, что даже с развитием ЭДО количество бумажных документов не уменьшается. Хотя прогнозы о стопроцентном переходе бизнеса на электронный документооборот и о том, что «бумага умрет», слышим уже последние десять лет.
Здравствуйте, спасибо за вопрос!
На самом деле, экспериментируя с WSJF, мы пришли к выводу, что для нас такой подход не подходит из-за недостаточной гибкости. А именно — из-за ситуаций, когда клиенты «трясут перед носом продакта кошельком», и в верхнюю часть бэклога попадают фичи, которые, хоть и несут ценность для пользователей и прибыль для компании, не всегда соответствуют стратегии развития продукта.
Чтобы решить эту проблему, мы попытались добавить в числитель формулы набор поправочных коэффициентов, оценивающих соответствие фичи продуктовой стратегии. Например, если в стратегии развития продукта есть вектор «высокая скорость обработки документов пользователями», мы вводим коэффициент:
1 — если фича не соответствует стратегии,
2 — если соответствует.
Другой пример — вектор «расширение использования ИИ-технологий при обработке документов». Если он важнее предыдущего, то коэффициенты могут быть выше:
1 — не соответствует стратегии,
3 — соответствует (используем 3, так как его важность в стратегии выше, чем скорость обработки).
Затем сумму всех критериев соответствия мы умножаем на Cost of Delay (в числителе).
Важно отметить, что калибровка весовых коэффициентов сильно зависит от специфики компании, продукта и количества пользователей.
Спасибо за пояснительный комментарий! Со своей стороны можем лишь подтвердить ваши слова и добавить несколько слов о продукте.
ContentReader PDF – многофункциональный редактор, который включает широкий набор инструментов для работы с файлами PDF и предоставляет возможность решать различные задачи редактирования текста внутри одного приложения.
Продукт имеет подтвержденную совместимость с ОС Astra Linux, Альт ОС, РЕД ОС, и потому может быть интегрирован в ИТ-ландшафт, построенный на российском софте.
ContentReader PDF входит в реестр отечественного ПО и рекомендован для замещения иностранного софта для просмотра и редактирования PDF-документов.
Мы не ставили перед собой такой цели, поэтому можем предположить, что сейчас с такими текстами работать будет плохо, хотя бы потому что это специфические документы, и сеть их никогда не видела. При этом техническая возможность доучить сеть конечно есть.
Напишите нам в личку, если перед вами стоит такая задача, обсудим вопрос более предметно :)
ContentReader — одно из лучших решений для редактирования PDF и OCR на рынке, как по набору возможностей, так и по качеству их реализации. Конечно, всегда есть к чему стремиться, и ошибки по ходу разработки в том числе и мы, конечно, совершали.
Что касается рукописного текста: замеры качества распознавания, на которые мы полагаемся, проведены на выборке из разнообразных рукописных документов, которые написаны разными людьми, разным почерком. Решение ContentCapture, в которое встроено распознавание рукописного, служит для автоматизации ввода данных из потока документов, и результаты, про которые мы говорим, это то, что можно ожидать на таком потоке.
Решили поэкспериментировать с именем вашей одноклассницы. Вот что вышло:
А 30 лет назад, когда только пошли первые ПК, появились первые OCR для печатного текста :)
Здесь главный вопрос в качестве (эта оговорка есть дальше по тексту), которое даже для печатного текста до сих пор улучшается.
А про американскую почту есть любопытная статья, где в том числе рассказывается про качество распознавания: https://habr.com/ru/companies/timeweb/articles/709240/