Хороший вопрос. Двухслойный подход с дополнительной проверкой замечаний — интересная идея. Но пока у нас один проход ревью, и для текущего уровня нагрузки его оказалось достаточно. С шумом мы боролись в основном тремя способами: выбором качественной модели, аккуратным промптом и набором явных правил. Часть правил уже учитывает специфику нашего стека и внутренних соглашений, чтобы не получать повторяющиеся ложные замечания на известных особенностях проекта.
Текущий баланс нас устраивает: шум есть, но его немного, а полезных замечаний достаточно, чтобы инструмент приносил практическую пользу. Если при расширении использования шум начнет расти, вариант с дополнительной верификацией замечаний вполне может стать следующим шагом.
Согласны с логикой — для задач вроде код-ревью низкая температура действительно предпочтительна. В нашем случае мы не управляем этим параметром напрямую, так как агент сам выбирает настройки для конкретного режима работы.
В режиме, который мы используем для ревью, температура фактически близка к нулевой. Поэтому на практике мы уже работаем примерно в той логике, которую вы описываете.
Спасибо за рекомендацию! Идея интересная. Мы, однако, остановились на другом агенте, который на нашем опыте оказался более зрелым и стабильным.
В нем тоже есть поддержка MCP, в том числе для нашей платформы разработки, но для авторевьюера мы сознательно пока не стали ее подключать. Нам хотелось иметь полный контроль над тем, какой именно контекст уходит на анализ. Интеграционная обвязка сама забирает нужные данные и формирует четко ограниченный пакет — это безопаснее и предсказуемее, чем давать агенту право самостоятельно ходить по инфраструктуре.
По поводу фильтрации вы совершенно правы, и мы это уже учли. В режимах, где ревьюеру нужен только diff или только измененные файлы, используется частичное клонирование без скачивания содержимого всех файлов. Проблема полного клонирования актуальна только для режима полного контекста репозитория.
На первом этапе нам важнее было проверить гипотезу и встроить ревьюера в процесс, а не сразу решить все задачи масштабирования.
Речь шла не о размере кода как такового, а о размере репозиториев в целом. В зрелых проектах для репозиториев с долгой историей это вполне реальная ситуация.
Вы абсолютно правы в отношении 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 (в числителе).
Важно отметить, что калибровка весовых коэффициентов сильно зависит от специфики компании, продукта и количества пользователей.
Хороший вопрос. Двухслойный подход с дополнительной проверкой замечаний — интересная идея. Но пока у нас один проход ревью, и для текущего уровня нагрузки его оказалось достаточно. С шумом мы боролись в основном тремя способами: выбором качественной модели, аккуратным промптом и набором явных правил. Часть правил уже учитывает специфику нашего стека и внутренних соглашений, чтобы не получать повторяющиеся ложные замечания на известных особенностях проекта.
Текущий баланс нас устраивает: шум есть, но его немного, а полезных замечаний достаточно, чтобы инструмент приносил практическую пользу. Если при расширении использования шум начнет расти, вариант с дополнительной верификацией замечаний вполне может стать следующим шагом.
Согласны с логикой — для задач вроде код-ревью низкая температура действительно предпочтительна. В нашем случае мы не управляем этим параметром напрямую, так как агент сам выбирает настройки для конкретного режима работы.
В режиме, который мы используем для ревью, температура фактически близка к нулевой. Поэтому на практике мы уже работаем примерно в той логике, которую вы описываете.
Спасибо за рекомендацию! Идея интересная. Мы, однако, остановились на другом агенте, который на нашем опыте оказался более зрелым и стабильным.
В нем тоже есть поддержка MCP, в том числе для нашей платформы разработки, но для авторевьюера мы сознательно пока не стали ее подключать. Нам хотелось иметь полный контроль над тем, какой именно контекст уходит на анализ. Интеграционная обвязка сама забирает нужные данные и формирует четко ограниченный пакет — это безопаснее и предсказуемее, чем давать агенту право самостоятельно ходить по инфраструктуре.
По поводу фильтрации вы совершенно правы, и мы это уже учли. В режимах, где ревьюеру нужен только diff или только измененные файлы, используется частичное клонирование без скачивания содержимого всех файлов. Проблема полного клонирования актуальна только для режима полного контекста репозитория.
На первом этапе нам важнее было проверить гипотезу и встроить ревьюера в процесс, а не сразу решить все задачи масштабирования.
Речь шла не о размере кода как такового, а о размере репозиториев в целом. В зрелых проектах для репозиториев с долгой историей это вполне реальная ситуация.
Все верно, это следующий этап в развитии данной продуктовой линейки.
Вы абсолютно правы в отношении 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 (в числителе).
Важно отметить, что калибровка весовых коэффициентов сильно зависит от специфики компании, продукта и количества пользователей.