Проектный менеджмент в AI и личный опыт

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

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

Но с AI системами все по-другому. Это в самой своей сути всегда немного исследовательский проект. Получится ли добиться нужной точности? А если другую архитектуру попробовать? А другую модель? А если форматирование данных с json поменять на xml? А что если ошибки не в поведении системы, а в самой разметке тестовых данных? А как это понять?

Это все – набор экспериментов. Результатом является не разработанная система, а проверенные гипотезы + выводы. Все как в науке => проектный менеджмент нужен похожий скорее на академический, чем на айтишный.

Но заказчику нужны не выводы, а рабочий продукт. Как быть?

Я свои заказы практически всегда делю на два ключевых этапа: исследовательский и интеграционный

Исследовательский

* Цель – проверить гипотезы и разработать LLM-core часть.

* Заказчик на вход дает примеры данных, с которыми система работает:
* Набор документов для извлечения данных
* Аудиозаписи для транскрибации
* Переписку продажников, которую хотим анализировать на ошибки

* В идеале получить еще разметку – ожидаемые результаты. Это может быть то, какой результат сейчас получают вручную

* На выходе тоже данные – результаты работы системы. И если есть разметка, то еще и сравнение с ней – где совпадает, а где нет (высший пилотаж, если даем еще и анализ почему)

* Никакой рабочей системы, продакшена и интерфейсов. Данные на вход, данные и метрики на выход,

* Если результаты исследования устраивают – идем дальше

Интеграционный

* Цель – обернуть llm-систему в сервис/приложение и интегрировать в существующие процессы.

* Я стараюсь вынести требования к прайваси именно сюда, чтобы они не тормозили на первом этапе. Тут уже может быть и разворачивание инфраструктуры в своем контуре, и работа с локальными моделями, и переезд в Azure вместо обычного OpenAI API.

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

* Настраиваем мониторинги, деплой, A/B тесты, ретраи с exponential backoff, фоллбэки на других провайдеров для надежности. Короче, продакшн

* По большей части обычная айтишная разработка.

———

Разделяя так проект, я снижаю и свои риски, и заказчика – если сразу видим, что задача автоматизации не решается на нужном уровне, можно вообще не тратить деньги и время на продакнш.

Заказчик экономит время и деньги, а я – сохраняю репутацию (чтобы не было "вон столько денег потратили, а пользоваться не возможно").

Еще и итерации без всей этой продакшн части делаются на порядок быстрее. Я за последние три года видел много ситуаций, когда люди сразу делали продакшн, а потом серьезное обновление LLM-системы тянуло за собой кучу приседаний.

И люди просто отказывались делать такие обновления. Да, в идеале оно все абстрагировано друг от друга. Но в реальности я такого не видел 🤷‍♂️

Кстати, бонус: если на исследовательском этапе метрики не устраивают, не обязательно отказываться от дальнейшей разработки. Можно менять подход к интеграции в сторону "копайлота". Работает AI + человек, который следит за ошибками и направляет систему, работая за целую команду.

Этот вроде простой подход наработан "кровью и потом". Если знаете, кому этот пост может быть полезен, поделитесь с ними, вам будут благодарны. А я буду рад, если рефлексия над моими ошибками поможет кому-то избежать своих

Очень узкий лайхак, который сэкономил мне много часов

! Только для тех, кто разрабатывает свои AI системы

Пишу только потому что его нет в официальной документации, и мне самому было бы полезно узнать о нем откуда-то

Вводные:
1. Я сейчас активно использую Gemini в качестве поискового движка вместо эмбеддингов
2. Я работаю с PDFками
3. Я использую OpenAI-compatible API (тут гугл красавчики, конечно)
4. У OpenAI API нет поддержки пдфок

Короче, хочется и все плюшки OpenAI формата использовать, и при этом специфичные для гугла фичи, типа умения кушать PDF в обычном chat completion режиме.

Оказалось, есть незадокументированный способ это сделать. Используем методы OpenAI для загрузки изображений, но меняем image/png на appication/pdf. Всё!

messages = [
    {
        "role": "user",
        "content": [
            {
                "type": "text",
                "text": prompt,
            },
            {
                "type": "image_url",
                "image_url": {"url": f"data:application/pdf;base64,{base64_file}"},
            },
        ],
    },
]

P.s. помним, что google читает пдфки с потерями (на вход идет раза в три меньше токенов, чем если грузить пдфку текстом). Для надежности лучше перегнать пдфки в текст, например в markdown через MarkerPDF и сравнить метрики двух подходов. На многих задачах оказывается, что достаточно отправлять PDF напрямую (+ в комментах потестили)

Понял, что даже примерно не знаю имплементацию обработки pdf у гугла. Есть ли там OCR? А текст, который прям текстом в pdf лежит, он сохраняет текстом или как картинку читает? Отправил Perplexity рисерчить за меня (внизу русская версия).

Из интересного:

1. Все страницы обрабатываются как картинки (не ожидал, я думал, хотя бы часть текста передается как текст)
2. Каждая страница кодируется 258 токенами вне зависимости от плотности инфы (значит, страницы с очень плотной инфой будут разбираться с ошибками)

Вывод – берем самые плотные страницы из данных с которыми работаем и бенчмаркаемся на них, прежде чем использовать нативную поддержку pdf в google gemini

P.s. а еще это значит, что если будет проблема со сломанными шрифтами (а в реальности такое бывает), то gemini сможет прочитать такой файл, об который текстовый пайплайн сломается (пример в комментах).

Привет!

Я Коля и этот канал – такая же смесь разных штук, как и я сам. Прошел путь от хардкорных оптимизаций на C++ до ML инжиниринга и управления продуктом, чтобы в 2023 уйти строить "my own software company".

По пути пожил на 4х континентах, несколько лет преподавал в университе (придумав забавную систему, которую студенты назвали "коля-коинами"), 4 месяца покатался по Западной Африке автостопом, занимался сценической импровизацией и переговорными чемпионатами, сжал все свои вещи до 35л рюкзака.

↑ Это я рассказываю, чтобы за аватаркой канала было немного реального человека со своими "приколами"

Сейчас строю свои микро-продукты (тут скоро будет ссылка на пост с провалами), веду консультации и делаю ИИ интеграции для чужого бизнеса (часто вообще не айтишного – выше ценность). Обычно хвастаюсь, что начал внедрять GPT-3 в существующий бизнес еще до выхода ChatGPT в 2023м.

Делюсь тем, что узнаю по пути. Стараюсь писать про практический опыт, ошибки и личное мнение – то, что нельзя вытащить LLMкой из новостной ленты.

Все лучшие посты тут, а вот три моих любимых:

Инсайты из чатов. как выкачать и проанализировать любую переписку

Вайб-кодинг без вайб-кодинга. Мой подход к разработке с AI спустя 2,5 года

Как я перестал откладывать

Записаться на консультацию:

@nikolay_sheyko

Подборка всех лучших постов (обновляется)

Для всех:

Инсайты из чатов. как выкачать и проанализировать любую переписку

Транскрибация и саммари звонков здорового человека

Как получилось, что юристы используют среду для разработчиков?

Универсальный взлом LLM и чем это грозит бизнесу

Самообман LLMками

Про разработку AI систем

Structured output, почему это база и как это использовать

Главная проблема GPT – не экспертиза, а контекст. И вот как её решить

Проектный менеджмент в AI и личный опыт: почему айтишные подходы – зло

Инсайты из моего эфира про context engineering у Влада NGI

Эмбеддинги сосут

Про разработку с AI тулами:

Вайб-кодинг без вайб-кодинга. Мой подход к разработке с AI спустя 2,5 года

Мой топ постов из других каналов о разработке с AI инструментами

Как хостить свои поделки, не превращаясь в девопса

Как дизайнить собесы под использование ИИ

Личное:

Выбирать скуку

Как я перестал откладывать: магия «задач-черновиков»

Быть фаундером стартапа – плохой способ заниматься инновациями

Что использовать для evaluation или как я очень удивился

Тут Ринат отлично объясняет зачем нужен evaluation в AI продуктах – нормально построенный механизм проверки качества позволяет избежать таких ситуаций:

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

Про это в целом давно все говорят (см выше скрин твиттера президента OpenAI от 2023), но про реализацию на практике – почти ничего не вижу. Значит надо писать.

Я строил eval пайплайны для LLMок еще в конце 22го, до выхода chatgpt, продолжаю строить их и сейчас для клиентских проектов. Обычно я даже не начинаю работать над проектом, пока нет данных, и не начинаю разрабатывать саму LLM-систему, пока не сделал систему проверки качества.

По сути есть два основных варианта, как делать:

1. Писать полностью свой кастомный код конкретно под задачу
2. Использовать какие-то готовые инструменты типа OpenAI Evals, который уже встречался тут

Я всегда делал сам, индивидуально под задачу. У такого подхода есть два серьезных минуса:

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

2. Нужно настраивать визуализацию. С разными отображениями. Сравнение ключевых метрик между экспериментами. Табличка по конкретному эксперименту. Фильтрации по каким-нибудь подмножествам. Графики.

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

———

Я полез смотреть, что сейчас есть на рынке и ужаснулся. Расплодилось очень много модных инструментов для LLM-evaluation. Они все позволяют достаточно гибко настраивать проверку по каждому отдельному объекту (см картинку OpenAI Evals), но при этом суммарная метрика по всем объектам из датасета – это всегда просто усреднение. То есть – тупо accuracy. Я напишу отдельный пост, почему это почти всегда плохая метрика, а сейчас важен сам факт:

Мы не можем настраивать суммарную для всего датасета метрику, а должны довольствоваться просто accuracy.

P.s. а ко мне пришли с задачей multi-label классификации, и мы хотим f-score с увеличенным весом recall

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

Итог

Справедливости ради, я все-таки нашел инструмент, где можно самому задавать общую метрику – это wandb.com, который исторически как раз был инструментом для классических ML и DS, но запустил у себя новый продукт weave для LLM evals.

Это прям рекомендация, особенно на python. На js/ts нужного функционала сильно меньше – там f-score уже не получится сделать.

А вы на какой стороне?

❤️ – использовать готовые инструменты
👍 – кастомить под задачу
😈 – еvals не нужны, просто вручную смотришь, что норм работает

Самые частые микро-советы с консультаций:

XML > json (для данных)

XML sections > Markdown headers (для промптов в целом)

Gemini flesh lite > Embeddings search

Gemini > whisper

Порядок экспериментов:
1. Без ризонинга 2. Общий ризонинг 3. Кастомный ризонинг

Кастомный ризонинг делать через поля в structured_output. 1 поле – 1 шаг.

Бейзлайн решение на закрытой мощной дорогой модели – верхняя оценка возможностей. Релевантно, даже если решение нужно делать на открытых моделях

Ваншот запрос (с интерактивным редактированием и перезапуском) > чат с кучей коррекционных сообщений

"Before start, ask questions to clarify what remains unclear/ambiguous. Then wait for my response, then proceed with the initial task"

AI делает опытных разработчиков менее продуктивными

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

Ладно, на самом деле я не хотел писать про эту статью, но до сих пор вижу, как ее расшаривают даже в профильных ИИ чатах, так что пора развенчивать мифы.

У этой статьи сразу несколько серьезных проблем:

1. Выборка всего из 16 участников. 16, КАРЛ.

2. Пишут, что было 250 задач. Но если вчитаться, оказывается, что это не на участника, а всего. То есть 16 участников по 16 задач. Если посмотреть на графики в аппендиксе, то видно, что у результатов нет статзначимости 🤥

3. Никто из них не имел серьезного опыта с ИИ-инструментами для разработки. Кривая входа в больших проектах в кодинг с ИИ – очень крутая. Это лендос на lovable собрать за выходные может любой дизайнер/продакт. Но большой проект – это всегда сложная инженерия с кучей нюансов

4. Результаты оценивали в среднем, хотя в контексте предыдущего пункта полезнее всего смотреть на верхней перцентиль – на сколько увеличилась эффективность эффективность у тех, у кого получилось найти эффективные паттерны использования.

———

Удивительно (нет), но у 4 разработчиков эффективность выросла (у двух – почти x2), причем лучший результат был у того, кто уже немного пользовался Cursor до эксперимента. Что только подтверждает связь между умением пользоваться инструментом и производительностью (вау?).

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

Кстати, если хотите провести такое обучение у себя в компании, напишите мне, хочу пилот сделать.

Ну а у авторов статьи получилось красиво хайпануть, еще и нигде не скрывать инфу (СМИ все равно сами вытащат "нужное"). Кстати, очень похожим образом в свое время получилось хайпануть у DeepSeek. Остается только учиться

Кстати, Влад из комментов к посту выше позвал меня на эфир в понедельник (21.07 в 19:00).

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

Кодить уметь не нужно. Целевая аудитория – все активные пользователи ИИ. Бонусом будет мини воркшоп от меня, как без программирования делать динамические сборщики контекста.

Чтобы не пропустить, можно добавить ивент в календарик тут

Ссылка на эфир: https://t.me/NGI_ru?livestream

UPD: https://meet.google.com/pac-uetx-vja

Неделю назад я был на эфире у Влада про Context Engineering. Наконец у меня дошли руки выписать несколько мини-тейков, чтобы не смотреть все два часа (некоторые достаточно противоречивые, как мы любим):

* Контекст-инжиниринг – часть промпт-инжиниринга. Просто теперь все важнее не только правильно собирать слова в инструкции, но и подтягивать релевантные данные извне.

Примеры:
* Дамп дневника → понимает личный контекст → лучше ответы на вопросы про отношения или зоны личностного роста, ошибки мышления
* Информация с созвонов компании → точнее ответы на бизнес вопросы
* Выгрузка тг канала → перенимает стиль текста и зоны фокуса при анализе инфы
* Документация → корректное использование библиотек (кстати, context7 MCP, кто еще не)

* Можно легко перегрузить контекстом. Аналогия – когда на разработчика вывалили весь контекст, который был в голове у менеджера, и теперь разработчик парализован, потому что постоянно вылетает в мысли про смежные зоны и ограничения.

На техническом уровне это объясняется слабым навыком моделей фильтровать неважную часть контекста – "если в условиях это зачем-то дано, значит, мне нужно это как-то использовать"

* Отсюда берется полезный паттерн: отдельно чат – "менеджер", где много контекста, и идет основное размышление и планирование, а отдельно чаты – "исполнители", которые занимаются узкой задачей, владея только нужным для конкретной задачи контекстом

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

Спекулятивное объяснение: в режиме диалога каждая фраза юзера – отдельная инструкция и модели сложно собрать их в одну непротиворечивую, да еще и не зацикливаться на подтверждении своих прошлых ответов.

* Модели хуже обращают внимание на контекст в середине. Одно из решений – просить модель повторить релевантный блок, прежде, чем генерировать финальный ответ. Так, она сама поместит его в конец своей "оперативной памяти", где внимание не проседает

* Просите модель собрать для вас инструменты для сбора данных. На эфире мы попробовали два способа, актуальных для неразработчиков (не требуют деплоя):
1. Самодостаточный html файл, который открывается в любом браузере
2. JS код, который вставляем в браузерную консоль.

* Есть еще варианты всяких агентов, где деплой уже настроен (Lovable, Perplexity Labs, Manus, Google Apps) или вообще ChatGPT Interpreter, который сам напишет код, сам его запустит.

Там Цукерберг разрешил использовать ИИ на собесах

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

Но это все лирика, теперь к практике – как проводить такие собесы у вас в компании.

Кстати, я работал над дизайном технических собеседований в CodeSignal – компании, которая делает собесы-as-a-service (кстати, с детищем Цука в списке основных клиентов). Повыпендривался, теперь можно и к делу

По сути, главный вопрос – а как сделать так, чтобы ИИ не был читерством?

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

С чем у вайб-кодеров проблемы?

1. Добавить фичу, которая "не укладывается" в существующую архитектуру (где опытный разработчик проактивно потребует рефакторинга)

2. Сформулировать правила для ИИ-агента с учетом специфики проекта

3. Писать безопасный код (сколько уже было новостей про захардкоженные секреты, а это только вершина айсберга)

4. Понять, что сама задача поставлена некорректно

Мы приходим к тому, в чем заключается профессионализм – умение самому подумать про промежуточные задачи, а не слепо следовать "промту" интервьюера/тимлида/задачи в тасктрекере.

Критерии задач?

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

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

Потому что именно так и выглядит настоящая работа. И наконец-то собесы станут ближе к реальности. Прогресс не остановить!

Бонус:

Лучшим стартом для такого будет взять челленджи из обучающего туториала Kiro – очень крутого примера обучения кодингу с ИИ на существующей кодовой базе.

Если хочется, чтобы кто-то докрутил под вашу компанию, пишите мне в личку, я такие штуки люблю и умею

AI tools для массмаркета и AI tools для топ-5% про-пользователей – два разных мира.

Как микроволновка и кухня шеф-повара (вот такие аналогии сегодня).

AI микроволновка

- получаешь результат почти сразу после регистрации

- не нужны доменные знания (собирай приложения в lovable без знаний программирования)

- почти нельзя корректировать систему в процессе

- много шаблонов, мало настроек

- работает для стандартных кейсов

Примеры: Lovable, Granola, Canvas, Gamma для презенташек, ElevenLabs, LogoAI

AI кухня шеф-повара

- крутая кривая обучения

- часто работа в режиме копайлота

- видишь промежуточные результаты

- очень гибкая настройка

- плотная интеграция с существующими инструментам

- выходит за рамки шаблонных решений

Примеры: Claude Code, AI фичи в adobe, Harvey для юристов, Canva, ElevenLabs

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

Это продукты-гибриды, где массмаркет часть – это просто большая воронка в PRO версию. При этом, с т.з. паттернов использования, эта лид-магнит часть – принципиально другой продукт.

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

Фильтрация вместо саммаризации

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

Классика.

Что получаем? Общие слова, потеря важных деталей, смещение фокуса в сторону от того, что важно мне. Еще может что-то переврать в процессе "сжатия"

Вместо этого, все чаще прошу не сжимать информацию, а отфильтровать самую важную и показать как есть.

Проанализируй этот документ и вытащи 20 самых важных абзацев/строк, таких, что прочитав их я смогу сформировать 80% понимания исходного документа. Используй принцип MECE (mutually exclusive collectively exhaustive). 
Выпиши их в исходном виде, так, чтобы их можно было корректно использовать для поиска в документе (символы совпадали на 100%)

Оставаться "посередине" обычно полезнее по жизни, чем уходить в крайности

Знать разные точки зрения, их плюсы/минусы, области применения > пользоваться какой-то одной догмой.

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

Одна из крайностей, в которую мне нравится уходить в теме ИИ это:

RAG на эмбеддингах – мусор, не используйте их, а используйте старый дедовский ...

А что именно использовать – мы обсудим с ребятами из @r77_ai. Давно за ними слежу и восхищаюсь, как они строят корпоративные контакты и до каких нестандартных проектов дотягиваются (как вам Анализ поведения свинок для выявления идеального момента для их оплодотворения?)

Четверг, 14 августа, 15-00. Добавляйте напоминалку в календарь, делитесь с теми, кому может быть интересно