Не рассчитывал, что тут сходу появятся посты, не влезающие в тележные 4к символов, и впредь обязательно постараюсь быть сдержаннее... но чёт не удержался: https://telegra.ph/Po-sledam-prostrelennyh-nog-v-parserah-Go-i-ne-tolko-06-21

Каких разработчиков уже заменяет ИИ?

Самое страшное, на мой взгляд, что может произойти с разработчиком — это профессиональная стагнация. Когда он постепенно сужает зону своей ответственности и продуктивность до предела «лишь бы не уволили»: на троечку с плюсом, где только можно. И медленно перестаёт развиваться как профи.

А ИИ ли виноват в том, что им заменяют разработчиков? «На зеркало неча пенять...»

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

Которые каждый раз, когда на горизонте появляется что-то новое, делают характерное лицо: «фу, это для зумеров» — а потом пишут свой велосипед, который работает хуже, медленнее и баговее. Потому что «ну ведь работает же», а в новой библиотеке или технологии — это же ещё разобраться надо.

Которые всегда и везде ищут виноватых за пределами своего уютного болотца, а не внутри него.

Которые делают всё, чтобы не принимать решений:
«тут архитектор нужен»,
«пусть лид согласует»,
«не знаю, у меня все работает»,
«этого нет в требованиях, все вопросы к продакту»…

Зато багов меньше. Ну, меньше кода — меньше багов. Всё честно.

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

И вижу здесь некоторую иронию в том, что они сами сделали себя заменяемыми, зажавшись в установке: «меньше ответственности = меньше риска». И теперь удивляются, почему на языке чувствуется привкус чужой пыли.

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

Нет смысла гадать, заменит ли ИИ таких разработчиков. Пока они чиллят в своём уютном изолированном мирке, отрицая очередной, как им кажется, «зумерский хайп», это — лишь вопрос времени.

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

Как разработчику быстро вкатиться в тему LLM? Введение

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

В одном — люди вовсю обсуждают очередные открытые и не очень LLM, делятся опытом их использования в своих проектах, владеют тонкостями настройки копайлотов и т.п.

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

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

отрицание, гнев, торг...

1. промпт-инжиниринг,
2. взаимодействие с LLM через API,
3. Retrieval-Augmented Generation (RAG),
4. автономные ИИ-агенты,
5. мультиагентные системы и протоколы взаимодействия.

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

Погнали?

1. Промпт-инжиниринг
2. Взаимодействие с LLM через API
3. RAG (Retrieval Augmented Generation)
4. Автономные ИИ-агенты
5. Мультиагентные системы и протоколы взаимодействия

Как разработчику быстро вкатиться в тему LLM? Часть 1

Введение

1. Промпт-инжиниринг

Не устану повторять, что искусственный интеллект, пока ещё, силён настолько, насколько силен отдающий ему команды естественный. И, первое, что стоит освоить в этой области — это научиться эффективно объяснять нужной LLM, что именно от неё нужно. То есть, писать промпты под правильно выбранную под задачи модель. И то, и другое неплохо объясняет вот эта статья. Не лишним будет также ознакомиться и вот с этой шпаргалкой.

Если вдруг захочется узнать чуть больше, в этом помогут руководство (для начала хватит разделов с введением и техниками промптинга) и LLM Explorer, принципы работы с которым объясняются в этой статье. Коллекций готовых и проверенных промптов на все случаи жизни — тьма. Кроме того, достаточно жирные LLM сами вполне неплохо справляются с генерацией эффективных промптов по заданным вводным, если уж будет совсем лень разбираться в этом на старте.

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

а) Общение с LLM, как с живым человеком. Чем раньше придёт понимание, что там нет ничего живого, а от человеческого — только переработанные в векторное представление продукты информационной жизнедеятельности людей, тем быстрее пойдёт дело с промптингом.

б) Пренебрежение начальным контекстом. Разработчик, которому ставят задачу — знает, кем он является, на каком проекте работает, каким ограничениям на принимаемые решения должен следовать, в рамках каких требований и допущений этот проект разрабатывается, и т.п. А LLM — нет. Ей это всё нужно объяснить. Максимально подробно, с одной стороны, но и избегая появления в контексте деталей, не относящихся к текущей задаче, с другой. И да, между строк модели читать вполне умеют. И, при любом удобном случае, делают это там, где вообще не надо было.

в) Решение слишком комплексных задач в один присест. Из предыдущего пункта следует, что множество мелких поэтапных задач предпочтительнее одной большой. Чем компактнее и строже контекст, тем лучше результат на выходе. «Слона надо есть по частям» — вот, здесь это тоже актуально.

г) Использование одних и тех же подходов «в лоб», на всех задачах подряд. Ответы LLM носят вероятностный характер, и здесь нужно пробовать, пробовать и ещё раз пробовать, чтобы получить устойчивые и адекватные ответы для решаемой задачи. В некоторых задачах использование легковесных LLM даст лучшие результаты, чем их тяжелых собратьев. Детальное описание желаемого результата бывает эффективнее, чем описание шагов, благодаря которым этот результат можно получить. Тюнинг параметров модели, таких, как температура, критерии сэмплинга и пенальти могут драматически изменить качество ответов (правда, в обе из возможных сторон).

Ну и задача на потренироваться по этой части:

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

Часть 2.

Как разработчику быстро вкатиться в тему LLM? Часть 2

Часть 1

2. Взаимодействие с LLM через API

Потренировавшись в промптинге через веб-морды любых доступных LLM, самое время переходить к вопросам использования их API у себя в коде. Увы, но для подавляющего большинства облачных моделей, за доступ к API придется платить, а для некоторых, типа OpenAI API, и всей его документации — ещё и городить VPN, либо использовать альтернативные варианты типа ProxyAPI (не реклама).

Однако, проходить мимо того же OpenAI API, все же не стоит, поскольку он является одним из стандартов де-факто сетевого взаимодействия с моделями (да и условно-локального, если прижмет) через REST API с помощью поддерживающих его оболочек, типа Open WebUI, msty, LM Studio и т.п. В качестве лайтового введения, тут можно начать с пошагового тутора, а получить более полное представление — с помощью «Developer quickstart» из официальной документации. Множество готовых примеров использования OpenAI API есть в кукбуке. Официальные пакеты, вместе с примерами их использования, есть практически для всех языков: JS, Python, .NET, Go и т.п.

Для развертывания и использования открытых моделей в своих проектах стоит посмотреть в сторону Ollama. Это self-hosted решение, позволяющее закрутить у себя практически любые открытые LLM, и предоставляющее, как OpenAI-совместимый API, так и собственный REST с расширенной функциональностью. Подход к освоению примерно тот же — Quickstart, Examples, и вперёд. Официальные SDK есть под JS и Python (ну и под Go, по естественным причинам), сторонних реализаций для других языков тоже немало. Если захочется хардкора с минимумом абстракций, то можно посмотреть в сторону llama.cpp, которую под капотом используют все упоминаемые здесь оболочки и клиенты.

Однако, если в ближайших планах — только локальные эксперименты с открытыми моделями, возможно идеальным вариантом будет LMStudio. Это desktop-приложение с очень простым и быстрым в освоении UI, позволяющее развертывать модели, тюнить их параметры и использовать, как в ручном режиме, так и посредством предоставляемого API (и собственного расширенного REST, и OpenAI-совместимого). Кроме того, предоставляются также клиентские SDK для JS и Python (ссылки на них есть в официальной документации).

Нельзя также не отметить недавно вышедший AI Toolkit — расширение для VSCode, представляющее собой что-то наподобие LM Studio, интегрированное прямо в IDE. Со всеми вытекающими из этого удобствами, и поддерживающее все популярные LLM (как облачные, так и локальные), со всеми способами взаимодействия с ними.

Сетап автора представляет собой:

– LMStudio на ноутбуке для абстрактных экспериментов с худенькими моделями;
– AI Toolkit для экспериментов в IDE, в рамках конкретных проектов, и как потенциальная замена LMStudio в будущем;
– торчащий в локальную сеть Open WebUI под ollama, с кучей моделей пожирнее, развернутых на более мощном домашнем компе.

Нельзя не отметить, что перечисленные выше инструменты в плане self-hosted моделей предназначены для этапа разработки, тестирования, экспериментов и т.п. Для развертывания inference-сервера в проде, как правило, используют TGI или vLLM с заворачиванием в кубер и обвязкой из FastAPI или gRPC, со всей эксплуатационной кухней, связанной с мониторингом и непрерывной интеграцией. Ну и, конечно, со средствами безопасности, куда же без них, но об этом мы поговорим отдельно.

Задача на потренироваться:

Всё то же самое, что и в предыдущей части, только из кода на любимом языке, с помощью локальной или облачной LLM, с загрузкой данных по заданной неделе через соответствующие API Google-календаря и Google-задач.

Часть 3.