Добрый день! При использовании промта на английском для извлечения данных из судебных документов наши замеры показали небольшое улучшение качества. В целом, результаты зависят от модели: в одних случаях лучше обрабатывается русский язык, в других — английский.
Спасибо большое за видео, посмотрели его. Интересно, что у ребят в новой схеме нет чистых ПМов / 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/
К сожалению, пока технология работает только внутри нашего продукта ContentCapture, который предназначен для потоковой обработки документов в масштабах организации. Распознавать произвольные рукописные тексты наша нейросеть умеет, но пока в массовые продукты такая фича не вошла.
Такой подход к корпоративному блогу действительно считается классическим стартом на Хабре. Однако наша ситуация (как и у многих коллег) нестандартная, и нам было крайне важно объяснить сообществу, кто мы такие и почему наш пост размещен в блоге другой компании (и вообще куда он делся).
Также в посте мы не просто объявили о старте блога, но и рассказали, чем занимались весь прошлый год, что сейчас представляет из себя компания и какой пул вопросов освещает. Технические подробности обязательно будут :)
К сожалению, с этим вопросом помочь не сможем, т.к. не публикуем декомпиляторы DSL :(
Можем посоветовать заглянуть на один из наших прошлых сайтов "Ассоциация лексикографов Lingvo". Для этого в архиве интернета https://web.archive.org открыть сайт http://www.lingvoda.ru где-то за 2017 год.
К сожалению, мы не сможем поделиться этим словарем, но можем подарить вам промокод на английский толковый словарь, в статьях которого указывается этимология слова. Все подробности -- в директе.
Спасибо, нам очень приятно, особенно про нашу техподдержку :)
Не скроем, после вашего поста тоже словили эту нотку ламповой ностальгии :)
К сожалению, тот этимологический словарь предложить не сможем, но можем подарить промокод на английский толковый словарь, в статьях которого указывается этимология слова. Все подробности -- в директе.
Добрый день! При использовании промта на английском для извлечения данных из судебных документов наши замеры показали небольшое улучшение качества. В целом, результаты зависят от модели: в одних случаях лучше обрабатывается русский язык, в других — английский.
Добрый день! Все данные на картинках фейковые, мы не использовали настоящие судебные документы
Спасибо большое за видео, посмотрели его. Интересно, что у ребят в новой схеме нет чистых ПМов / 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/
К сожалению, пока технология работает только внутри нашего продукта ContentCapture, который предназначен для потоковой обработки документов в масштабах организации. Распознавать произвольные рукописные тексты наша нейросеть умеет, но пока в массовые продукты такая фича не вошла.
Спасибо, мы очень старались :)
Пост действительно без деталей, т. к. он вводный. Спасибо, что интересуетесь нашей работой! Записали ваши вопросы в бэклог.
Про Lingvo у нас уже выходил подробный материал. Его можно почитать тут: https://www.it-world.ru/tech/practice/187497.html
Такой подход к корпоративному блогу действительно считается классическим стартом на Хабре. Однако наша ситуация (как и у многих коллег) нестандартная, и нам было крайне важно объяснить сообществу, кто мы такие и почему наш пост размещен в блоге другой компании (и вообще куда он делся).
Также в посте мы не просто объявили о старте блога, но и рассказали, чем занимались весь прошлый год, что сейчас представляет из себя компания и какой пул вопросов освещает. Технические подробности обязательно будут :)
поправили, спасибо за внимательность!
К сожалению, с этим вопросом помочь не сможем, т.к. не публикуем декомпиляторы DSL :(
Можем посоветовать заглянуть на один из наших прошлых сайтов "Ассоциация лексикографов Lingvo". Для этого в архиве интернета https://web.archive.org открыть сайт http://www.lingvoda.ru где-то за 2017 год.
К сожалению, мы не сможем поделиться этим словарем, но можем подарить вам промокод на английский толковый словарь, в статьях которого указывается этимология слова. Все подробности -- в директе.
Спасибо, нам очень приятно, особенно про нашу техподдержку :)
Не скроем, после вашего поста тоже словили эту нотку ламповой ностальгии :)
К сожалению, тот этимологический словарь предложить не сможем, но можем подарить промокод на английский толковый словарь, в статьях которого указывается этимология слова. Все подробности -- в директе.