Наверняка вы сталкивались с ситуациями, когда модель начинает вести себя в проде не так, как задумывалось: например, ведётся на провокации пользователя или даёт некорректные ответы. Зачастую такие ошибки безобидны, но случаются и не очень приятные ситуации. А если речь идёт о чат-боте, который отвечает на вопросы в юридической или медицинской сфере — практически любая ошибка может быть критичной. 

Итак, мы плавно подошли к тому, что нужно каким-то образом валидировать ответы LLM. Давайте разберёмся, как это делать.   

Привет, Хабр! На связи команда LLM-dev из Точки. Как несложно догадаться, наша основная миссия — учить и улучшать внутреннюю LLM и модели, связанные с ней. Для этого нужно очень-очень много текстовых данных, которые надо где-то хранить и как-то уметь с ними работать. А ещё нужно ставить эксперименты, которые надо как-то трекать и воспроизводить, писать и отлаживать много кода, и делать всё это в команде. 

О том, как сделать код читаемым, эксперименты — воспроизводимыми, а время на написание и рефакторинг своего и чужого кода — минимальным, и поговорим в этой статье. И всё это без привязки к готовой инфраструктуре внутри компании.

Привет! Если после заголовка вы решили, что это очередная статья в стиле «Топ-10 способов ускорить Pandas», то не торопитесь с выводами. Вместо топов и подборок предлагаю взглянуть на бенчмарки скорости и потребления памяти в зависимости от характеристик датафрейма и убедиться, что часть советов из статей по ускорению могут оказаться даже вредными. Разберём, какой из способов ускорения нужно пробовать в разных ситуациях, как это зависит от размера датафрейма и как ведёт себя в реальном проекте.