Мы в Content AI разрабатываем платформу интеллектуальной обработки документов ContentCapture. И при этом считаем, что IDP и RPA как самостоятельные классы исчезнут в течение пяти лет. Может показаться, что это звучит как самоотрицание, но для рынка это хорошая новость. Ниже расскажем, почему мы пришли к такому выводу и что это значит для тех, кто сейчас выбирает IDP-решение или автоматизирует работу с документами.
Вокруг агентных автоматизаций разворачивается нешуточная битва. Евангелисты обещают, что ИИ-агенты вот-вот заменят все и всех, скептики интересуются реальными сценариями таких автоматизаций, ROI и прочей конкретикой (но обычно не получают ответов).
Мы сами получаем много вопросов о практическом применении агентной автоматизации в бизнесе, и в этой статье расскажем, как сейчас обстоят дела и куда все движется.
Привет! Я Александр Субботин, руководитель отдела разработки Content AI.
За четыре года в этой роли я провел больше 50 собеседований, собрал 8 команд и несколько раз разруливал ситуации, когда топ-менеджмент считал, что команда демотивирована и с этим надо что-то сделать. Спойлер: в 90% случаев проблема была не в мотивации.
В этой статье я собрал кейсы из практики по мотивации на всех этапах и один простой вопрос, который изменил мой подход к управлению командой.
Года полтора назад мы бы удивились, если бы услышали, что к лету 2026 разработчики начнут регулярно использовать ИИ-инструменты, тестировщики — автоматизировать с их помощью часть своей работы, а продакт-менеджеры — приносить на обсуждение первые (работающие!) прототипы, созданные с помощью ИИ. Но примерно так все и получилось.
Это третья статья из цикла про внедрение ИИ в процессы разработки Content AI. В первых двух мы рассказали, как собрали ИИ-ревьюер кода за три дня и как научили ИИ писать код по нашим правилам. А теперь расскажем, что изменилось в работе всей команды разработки за полгода активного использования ИИ-инструментов. В этой статье мы не рассказываем о конкретных моделях или внутренней инфраструктуре. Нас интересует другое — как меняются роли людей и процессы разработки.
С код-ревью есть такой парадокс: все согласны, что этот процесс важен, но времени на него обычно ни у кого нет. В результате ревью часто превращается в формальность. Очевидные баги при этом ловятся, а мелкие, вроде пропуска в условиях, перепутанных знаков, забытых edge cases и т.д., могут спокойно уехать в мердж и вернуться уже в виде задач в багтрекере.
В Content AI мы активно внедряем ИИ в разработку, и одна из задач, которую мы решали в этом году, — автоматизация код-ревью. В этой статье рассказываем, как одна из наших команд собрала ИИ-ревьюера, встроенного в Pull Request, и что мы поняли спустя месяц использования.
В мае 2026 складывается ощущение, что уметь писать код вручную больше не обязательно — вокруг все наперегонки хвастаются, как за выходные собрали мега-сервис, на конференциях показывают слайды про х100 к продуктивности разработчиков, а в вакансиях все чаще требуют опыт работы с ИИ-инструментами. Вайб-кодинг победил, расходимся?
Да, для личных проектов и стартапов вайб-кодинг действительно отлично работает. Проблемы начинаются, когда подход «сделай мне как у Google» пытаются занести в продукт со серьезными требованиями и крупными клиентами.
У нас в команде возник практический вопрос: можно ли использовать вайб-кодинг в разработке пользовательских этапов автоматизации ContentCapture, платформы интеллектуальной обработки документов? Причем использовать как полноценный инструмент, который реально сократит время на интеграции, бизнес-правила и RPA-сценарии (и не создаст новых проблем).
Если коротко: у нас получилось. Дальше расскажем, как мы это сделали, с какими сложностями столкнулись и что получили в итоге.
Привет, Хабр! В одной из прошлых статей мы рассказывали, какие фреймворки приоритизации бэклога фич существуют и почему в итоге запилили свой. Сегодня поговорим про вторую сторону медали: баги.
Если для оценки фич индустрия создала десятки методов (от RICE до MoSCoW и WSJF), то с багами все скромнее: общепринятых подходов сравнительно немного, и нам в итоге они не подошли.
У нас зрелые B2B-продукты, крупные корпоративные клиенты и высокие требования к качеству релизов. Поэтому пришлось эволюционировать: от стандартных матриц мы постепенно дошли до собственной короткой формулы, которая сегодня закрывает большинство кейсов на тимлидерских встречах по релизу.
Далее поделимся обзором существующих подходов, историей наших экспериментов и к чему мы пришли в итоге.
Привет, Хабр! Меня зовут Алена Ивличева, я менеджер продукта в Content AI. Мы делаем ContentReader PDF — редактор PDF, в который теперь встроен ИИ-ассистент.
Сегодня я хочу поговорить о том, куда движутся технологии, как искусственный интеллект меняет наше привычное взаимодействие с документами и что все это значит для наших продуктов.
На рынке сейчас огромное количество трендов, но я выделю те, что реально меняют правила игры.
Последние 2 года мы в Content AI активно тестируем Vision Language Models (VLM) для обработки документов. Модели вроде Qwen2.5-VL или Gemini 2.5 отлично работают с простыми формами — чеками, типовыми договорами. Но на документах со сложными фонами, многоуровневыми таблицами или нестандартной версткой VLM часто галлюцинирует, теряет строки и путается в реквизитах.
В одной из предыдущих статей мы пришли к выводу, что будущее за комбинированным подходом, когда VLM усиливает IDP-решения.
В этот раз мы проверили гипотезу: пусть VLM не распознает документ с нуля, а проверяет черновик из IDP-системы и исправляет ошибки, опираясь на исходное изображение. Базовым OCR движком выступила наша платформа ContentCapture.
Практическая цель эксперимента — автоматизировать верификацию документов. Сейчас в крупных компаниях сотни операторов вручную сверяют распознанные данные с оригиналами.
В прошлых материалах мы уже рассказывали о том, как мультимодальные модели (VLM) справляются с извлечением данных из финансовых документов, и показывали, что в ряде сценариев они могут конкурировать с оптимизированными классическими IDP-решениями. Однако мы решили не ограничиваться одним типом документов и продолжили исследование, сравнив технологии на широком спектре материалов. В пул вошли сканы высокого качества и фотографии со сложным фоном, структурированные табличные формы и документы с элементами рукописного текста, русскоязычные и англоязычные тексты.
Сегодня мы готовы поделиться сводными итогами.
Привет! Меня зовут Антон Фролов — я ведущий менеджер продукта в Content AI. В этой статье расскажу, как мы превратили корпоративный поисковый портал Intelligent Search в платформу для создания цифровых ассистентов с поддержкой LLM.
Если у вас уже есть прототип ассистента на базе open-source компонентов, платформа может помочь оперативно разработать решение production-уровня для автоматизации различных процессов с внутренними документами.
Еще десять лет назад автоматизация обработки документов опиралась на OCR и жесткие шаблоны. Сегодня в этой сфере все активнее заявляют о себе VLM — технологии, способные понимать контекст и быстро адаптироваться к новым задачам. Но меняют ли они правила игры полностью или лишь дополняют существующие?
Мы провели исследование и выяснили, что правила изменились, но говорить о полном забвении классических IDP-решений рано. Более того, будущее будет за гибридом, который сочетает эффективность IDP с новыми возможностями VLM.
Продукты класса ContentCapture работают с большими объемами документов, и для бизнеса критична скорость их обработки. Но как убедиться, что система не замедлится после выхода очередного релиза? Здесь на помощь приходит тестирование: QA-инженеры регулярно проводят замеры скорости распознавания — например, при обновлении технологии или запуском нового проекта.
Казалось бы, все просто: автоматизируешь тесты, замеряешь время — и получаешь объективные метрики для оптимизации. Но на практике даже идеальная автоматизация не спасает от неожиданных сценариев.
В этой статье — пять коварных ошибок, которые чаще всего искажают результаты тестов. Некоторые настолько распространены, что мы научились распознавать их еще до того, как клиент закончит жаловаться.
Привет, Хабр!
Использование OSS‑компонентов — стандарт современной разработки. Под OSS‑компонентами мы понимаем ПО с открытым исходным кодом. Это могут быть приложения, библиотеки, набор файлов, или даже просто фрагмент кода.
Но при использовании OSS есть нюанс — лицензии. Одни библиотеки можно брать без оглядки, другие требуют платежей, а третьи — строгого соблюдения условий. И если в бэкенде зачастую все относительно статично (версии меняются редко, компонентов немного), то веб — отдельная история. Тут компоненты множатся с космической скоростью, версии обновляются каждую неделю, и следить за всем этим вручную просто нереально.
В этой статье расскажем о том, как мы формируем реестр OSS‑компонентов и какие инструменты помогают нам быстрее проверять лицензии и формировать единый список компонентов.
Ранее мы уже делились опытом использования LLM для обработки юридических документов и доверенностей. Сегодня расскажем о другом подходе, который применил наш технологический партнер ООО «ЕСМ-Консалтинг». При реализации нескольких показательных кейсов для крупных российских энергосбытовых компаний, автоматизировав в них обработку судебных документов с помощью платформы ContentCapture и больших языковых моделей (LLM).
Изначально мы рассматривали два подхода к реализации подобных проектов. Первый – предполагал классическую работу с гибкими описаниями документов, когда правила извлечения информации задаются человеком. Второй вариант – комбинированный, с использованием больших языковых моделей (LLM). Наш опыт показал, что последний подход как минимум в три раза экономичнее, при работе с неструктурированными документами. Он обеспечивает хорошую скорость и высокое качество извлечения данных (более 95% правильно извлеченных данных), что позволяет нашим заказчикам масштабировать обработку документов без роста операционных расходов.
В системах интеллектуальной обработки документов корректность извлечения данных — это лишь половина дела. Гораздо важнее, чтобы при скачке нагрузки сервис не превратился в бутылочное горлышко.
В этой статье расскажем, как мы:
● автоматизировали нагрузочное тестирование, сократив ручную работу инженеров на 85%;
● встроили стресс-тесты в CI/CD, чтобы каждая фича доказывала свою устойчивость перед релизом;
● научились предсказывать поведение системы не на глаз, а по данным — даже при росте объемов в несколько раз.
В прошлой статье мы говорили, что нашли быстрый и простой способ, как с помощью LLM вытаскивать данные из юридических документов и доверенностей. А сегодня расскажем, какой промт мы для этого использовали.
В эпоху цифровой трансформации каждая минута работы с документами на вес золота. Юридические отделы, банки, госучреждения ежедневно обрабатывают сотни договоров, доверенностей и судебных приказов. Ручной ввод данных, поиск реквизитов и проверка сроков могут отнимать до 20 минут на документ — и это если сотрудник не отвлекся на кофе.
В нашей линейке продуктов есть универсальная IDP-платформа ContentCapture. Она хорошо понимает структурированные документы, а вот при обработке неструктурированных данных раньше могли возникать сложности. Чтобы решить эту проблему, мы в новом релизе продукта настроили интеграцию с облачными большими языковыми моделями (LLM), такими как YandexGPT и GigaChat.
Делимся подробностями и рассказываем, как оценивали качество работы LLM с разными типами документов.
Привет, Хабр!
Меня зовут Елена Понаскова, я HR-директор в Content AI.
В IT-индустрии борьба за таланты давно вышла за рамки зарплатных вилок и стандартных бонусов. Да, деньги важны, но что на самом деле удерживает людей в компании? Не просто интересные проекты или карьерные перспективы, а чувство принадлежности. Когда команда — это не просто коллеги, а единомышленники, когда ценности компании созвучны твоим, а атмосфера дарит не только мотивацию, но и ощущение надежности — именно тогда возникает искренняя вовлеченность.
Сегодня хочу рассказать о том, как мы создаем среду, где люди не просто работают, а хотят остаться.
Привет, Хабр!
Многие ИТ-компании находится в постоянном поиске баланса между автономией команд и централизацией процессов. Эта дилемма не обошла стороной и нас в Content AI. В силу нескольких причин пришлось отказаться от классической плоской структуры, которая подразумевала минимальное количество уровней управления, в пользу иерархической, где напротив, есть довольно четкое распределение ролей и зон ответственности.
Попросили руководителя нашего отдела разработки — Александра Субботина и его подчиненных, рассказать о причинах смены подхода к распределению ролей в командах и вызовах, с которыми столкнулись в процессе перехода.
Все подробности — под катом.
————