Привет, Хабр.

Это будет не типичная статья в стиле «10 причин, почему ИИ уже заменил копирайтеров», а история фэйла с человеческим лицом.

Не так давно я выпустил на Хабре статью и вполне заслуженно собрал минусов и комментов, которые были очень в точку. 

Случился у нас персональный диалог с одним сотрудником о том, что производительность у него кратно выросла. Выяснилось, что дело в использовании Cursor.

Его результаты были настолько хороши, что незаметно начали ему давать даже не один спринт, а сразу два. И он справлялся.

После этого стало ясно, что эта история необходима нам системно, чтобы оптимизировать производство в целом, увеличить скорость разработки и оставаться конкурентноспособными.

Как мы поступили
1. Сформировали фокус-группу
2. Дали инструмент
3. Назначали спеца, который уже разобрался ранее, ментором по софту
4. Начали отслеживать, как увеличивается производительность работы

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

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

Итеративно, неделю за неделей мы смотрели, на сколько процентов у нас сокращаются оценка и фактическое время.

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

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

Плюс, из-за внедрения появилась потребность в том, чтобы обновить формулирование задач от менеджеров проектов, но это уже совсем другая история.

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

Начали обучение мы даже без погружения в то, как работает LLM, просто научили его работать в графическом интерфейсе нашей платформы, создавать простейшие цепочки и написания промптов.

Плюс, постепенно изучаем то, из чего состоит само приложение (что можно подключить память, что там можно выбирать различные инструменты для работы), отдельные моды в LangChain для разных задач, для вопросно-ответных систем, для систем, где агент выбирает сам инструменты, где система работает с реактом.

Обучение строится так:
• сначала хоть что-то запустить;
• потом понять, как это «хоть что-то» работает;
• потом усложнить и понять разницу;
• далее переходить к практическим задачкам.

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

Тут важно прописывать задачи.
В одной задаче мы подключаем память.
В другой — используем внешние инструменты, которые могут, например, по API дёргать данные по погоде/курсу валют/сводкам новостей/etc.

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

И после выполнения, например, 5 задач, джун уже может технически разбирать их по существу и понимать, а что и как можно улучшить?

Мы используем, например, ретривал: это может быть поиск по документам, достаточно простой, семантический. А далее это может быть уже и подключение реранкеров и прочие усложнения реализованных кейсов. Например, выводить какую-то конкретную метадату, какой-то конкретный источник и разбирать эту историю.

Когда команда выбирает LLM для продакшена, «сравнение по бенчмаркам» — это лишь первый фильтр. Для CTO ключевой вопрос звучит иначе: какую комбинацию качества, стоимости, стабильности API, юридических ограничений и интеграций мы получим на реальной нагрузке. Я разобрал популярные модели через призму двух контуров: качество/бенчмарки и инфраструктурная пригодность.

В этой статье разберём, во сколько обходится LLM-сервис при нагрузке в 100 000 диалогов в день и где проходит граница окупаемости разных вариантов. Посмотрим на стоимость облачных API, аренды GPU и собственного железа, а заодно прикинем, какая инфраструктура нужна, чтобы всё это выдержало боевой трафик.