Хабр, привет! На связи Кравцов Кирилл и Суздалев Руслан из команды моделирования поведенческих сценариев Центра развития искусственного интеллекта СПАО «Ингосстрах» (далее — ЦРИИ). В статье поделимся решением, которое помогает нам быстрее обучать и интегрировать модели в компании.

С ростом компании и ЦРИИ, в частности, у нас появлялось все больше бизнес‑заказчиков, которым нужны были ML‑модели. Поэтому потребность росла, а ограниченность ресурсов не позволяла быстро обрабатывать задачи бизнеса и многое уходило в беклог.

В этой статье мы разберем, как ИИ выходит из стадии хайпа и начинает приносить реальные результаты. Вы узнаете о ключевых технологиях и подходах, которые стали важными в 2024 году, а также о том как компании справляются с новыми вызовами, и почему Composite AI, RAG и графы знаний набирают такую популярность.

В эпоху удаленной работы нас всех накрыло одним большим одеялом дисконекта. Так, словно мы оказались в каком-то фильме ужасов, где «команда» — это не более чем призраки в Zoom. Я тут, чтобы поделиться парочкой фишек, как мы остаёмся на связи несмотря ни на что и укрепляем командный дух.

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

Мы рассмотрим варианты решения типовых задач в страховании и не только.

Cтатья будет полезна разработчикам и инженерам по ИБ, желающим повысить уровень безопасности приложений за счет внедрения проверок, запрещающих вносить в ПО сторонние компоненты с известными уязвимостями.

В статье рассмотрим внедрение CodeScoring Johnny применительно к Azure DevOps Server в процесс анализа запросов на вытягивание (pull requests) для целей композиционного анализа.

При написании этой статьи я вновь пришел к мысли, что каждый ИТ-шник и ИБ-шник должен быть хоть чуточку разработчиком для более эффективного решения своих задач

Каждый разработчик, кто серьезно работал с типом DateTime, сталкивался с ошибкой високосного года. На этом пути не спасали ни многочисленные методы языка программирования, ни гуглопоиск - обязательно, раз в четыре года, баг високосного года напоминал о себе. В этом году насчитали 36 случаев.

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

Cтатья будет полезна разработчикам и инженерам по ИБ, желающим повысить уровень безопасности приложений за счет внедрения проверок, запрещающих вносить секреты в открытом виде в исходный код.

В случае утечки исходного кода либо ознакомления с ним неуполномоченными лицами компания понесет ущерб.

В статье рассмотрим внедрение Gitleaks применительно к Azure DevOps Server в процесс анализа запросов на вытягивание (pull requests) при слиянии ветвей. Система управления исходным кодом Azure Repos является частью Azure DevOps Server.

Про то, как посчитать ёмкость задач разного уровня сложности написано немало, например эта статья. Ответу же на практический вопрос – а сколько реально сможет взять команда – уделено меньше внимания. В рамках своей статьи поделюсь эмпирическим методом расчёта ёмкости на основании простых статистических данных.

Для тех, кто знаком с другими методами эмпирического прогнозирования (например, методом «Вчерашней погоды» из Scrum) материал также может быть интересен.

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

Такая градация помогает мне определить подход взаимодействия со специалистом. А также позволяет спрогнозировать, каких результатов от этого сотрудника можно ожидать.

Эта статья будет интересна системным аналитикам и участникам команд разработки. А если среди ваших коллег есть люди, подходящие под моё описание, то, возможно, вы будете понимать их чуточку лучше.

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

В статье покажу ряд простых и очевидных подходов разработчиков Oracle, помогающих уменьшить цену ошибки на проде. Проверено на себе :-)

В этой статье мы рассмотрим описание процесса тестирования программного обеспечения сквозь призму работы с API. Я попытался собрать полезные факты из книги “Hands on restful API design and the best practices” авторов Harihara Subramanian и Pethuru Raj. В книге подробно описываются этапы проектирования API и есть отдельная глава по тестированию RESTful сервисов в связке с API.

Можно читать в связке с моим предыдущим переводом “Стратегия тестирования REST API: что именно вам нужно тестировать?”. По ходу перевода я привожу примеры из личной практики (выделены курсивом), чтобы наглядно проиллюстрировать каждый этап из книги.

Всем привет! Меня зовут Ольга и я разработчик в Ингосстрахе. В этой статье-туториале хочу поделиться способом партиционирования оооочень большой таблицы в Oracle 12c. Итак, погнали.

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