Мы построили мультиагентную RAG-систему на open-source моделях, прошли путь от наивного RAG до ReAct-агента с собственным бенчмарком — и готовы рассказать, где набили шишки. Внутри: две итерации архитектуры, честное сравнение через RAGAS-метрики и ответ на вопрос, почему «просто взять фреймворк» не работает. Будет полезно всем, кто строит RAG для корпоративных знаний или только собирается.

Каждый день через системы «Честного знака» проходят тысячи страниц: контракты, акты, техдокументация, анкеты. Всё это нужно не просто перевести в текст — а сразу пустить в работу: поиск, анализ, генерация выжимок, передача в другие сервисы. Одна ошибка OCR — и вместо «субподрядчика» система получает «cy6пoдpялчика», а дальше никакие регулярки не спасут.

Меня зовут Искандер, я - AI-инженер в Лаборатории искусственного интеллекта «Честного знака». Мы протестировали лучшие open-source OCR-движки на реальных русскоязычных документах — от простых текстов до многостраничных PDF со сложными таблицами и изображениями. Специфика задачи: кириллица, широкий разброс форматов, нулевая терпимость к ошибкам на продакшне.

Чтобы получить честные результаты, мы собрали собственный модуль тестирования и сформировали репрезентативный датасет из 6 наборов реальных документов. В статье — методология, метрики и то, кто из движков реально справился, а кто только обещал «максимальную точность даже на луне».

"Скоро сказка сказывается, да не скоро дело делается" - говорится в народной пословице. Вот и мы решили не спешить со второй частью статьи по Junit 5 Extensions, а подойти к ней более основательно! Статья будет полезна QA-автоматизаторам, которые хотят глубже понимать работу с расширениями и выжать чуть больше из связки Kotlin + Junit5. Мы пройдем путь от простой реализации condition-выполнения тестов и источников данных для параметризованных тестов до реализации расширения Микро-DI с рекурсивной инъекцией зависимостей.

Как и в прошлой статье, сделаем акцент на практической части реализации расширений для JUnit 5. В качестве языка - Kotlin. Поэтому, достаем бутерброды, наливаем пиво кофе и приступаем!

Привет. В Рунете материала по JUnit 5 Extensions сегодня немного, и довольно часто он ограничивается переводом документации (в редких случаях - постов с зарубежный ресурсов). Поэтому было решено исправить сей недостаток.

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

В качестве языка программирования я выберу Kotlin...

Наша команда занимается технической поддержкой вычислительного комплекса государственной системы маркировки «Честный знак».

Пройдя свой путь от одной стойки до нескольких сотен, хотим поделиться своим опытом и наблюдениями.

Центр Развития Перспективных Технологий - компания разработчик системы мониторинга товаров. Как IT компания с большим количеством данных мы используем множество NoSQL решений в своей повседневной работе. Одним из таких решений является Apache Cassandra.

Суммарно, во всех кластерах Cassandra мы храним 0.4PB данных при общей емкости 0.9PB, стабильно производим 0.7млн операций записи и доступа к данным и 1.1млн когда необходимо разогнаться в трудные времена, при этом продолжаем непрерывно расширяться.

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

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

В 1930-х годах в Москве начался масштабный проект по переносу домов. Да-да, именно переносу – вызвано это было тем, что архитекторы претворяли в жизнь масштабные проекты, которым требовалось место, но его не было. Иногда на пути нового проекта стоял какой-нибудь дом. Любопытно, что во время его перемещения, жильцов не переселяли, а дом даже не отключали от инженерной инфраструктуры: в квартирах продолжал функционировать телефон, водопровод, электричество и канализация.

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

Статья для начинающих аналитиков-стажеров

Когда вводишь в поисковой запрос "Курсы для аналитика данных", то сразу в глаза бросается SQL, Phytnon, R и другие инструменты. Но в первую очередь аналитику данных помогли бы не только инструменты, а еще и определенные способы мышления цифрового детектива. На наглядном примере мы вместе протестируем витрину данных, выстроим логику развития событий, а далее применим SQL. Статья предназначена для junior аналитиков данных или тех, кто только знакомится с будущей профессией Data Analyst.

Одним из трендов при проектировании сервисов в последнее время выступает использование в качестве баз данных NoSQL-систем. Мы также стараемся идти в ногу со временем и, конечно же, имеем в своем IT-ландшафте несколько таких решений. Одно из них — шардированный кластер MongoDB. Эксплуатация этой СУБД сопряжена с проблемами производительности, архитектуры, взаимодействия и т.д. Удивительно, но факт - зачастую, все мы сталкиваемся с тем, что ошибаются разработчики самой СУБД. Кто бы мог подумать.., что после штатной перезагрузки узла конфигурационного сервера MongoDB в процессе обновления может произойти аварийное завершение работы сервиса базы данных и наш стенд превратится в «тыкву»!

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

Дисклеймер: нижеописанные события произошли после того, как была опубликована рекомендация производителя не использовать версию 4.4.4.