Не рассчитывал, что тут сходу появятся посты, не влезающие в тележные 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.

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

Часть 2

3. RAG (Retrieval Augmented Generation)

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

Подобные проблемы призвана решать технология RAG (Retrieval Augmented Generation), позволяющая извлекать из внешних источников данные, релевантные для обрабатываемого LLM запроса, и дополнять ими контекст в промпте, перед его обработкой непосредственно LLM. Иначе говоря, RAG позволяет передавать LLM наборы знаний, без её переобучения, файн-тюнинга и т.п.

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

Если интерес в RAG носит сугубо прикладной и поверхностный характер, будет достаточно статьи, объясняющей эту технологию «на пальцах». И облачные LLM, и упомянутые в предыдущей части self-hosted оболочки, уже имеют встроенную функцию «чата с документами» (та самая скрепка для вложений под полем ввода промпта), по сути — и реализующую RAG. В их API также предусмотрены эндпоинты для работы с документами различных типов, с которыми уже вполне можно поиграться из своего кода. Их можно подсмотреть в документации Open WebUI . Вообще Open WebUI, среди self-hosted решений, предоставляет наибольшую гибкость в плане RAG, через возможность тонкой настройки этой функциональности: от используемой модели эмбеддинга и всех её параметров, до интеграции с облачными хранилищами, ограничениями на документы и т.п.

Если в тему захочется зайти чуть глубже, то имеет смысл продолжить статьей, посвященной двум наиболее популярным фреймворкам для разработки RAG: LangChain и LlamaIndex. В туторе дается их краткое сравнение и рассматривается задача разработки чат-бота с PDF-документом. Первая часть статьи, по сути, повторяет всю вводную предыдущую, т.ч. в этом случае что-то одно из них можно смело пропустить.

Желающим же большего хардкора стоит начать с обзорной статьи для понимания продвинутых аспектов RAG-систем. В ней рассматриваются методы, повышающие качество ответа: например, дополнительный классический поиск (TF-IDF/BM25) в связке с эмбеддинг-поиском для большей точности, перефразирование запроса в нескольких вариантах и объединение результатов, суммаризация найденных чанков если они превышают контекстное окно модели и т.п. Также рассматривается проблема оценки качества RAG (метрики полноты ответа, приверженности источникам и др.). Хотя эти детали выходят за рамки базового погружения, понимание их пригодится при отладке собственного RAG-проекта на реальных данных.

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

Возьмите небольшую коллекцию текстов (например, несколько статей или FAQ-файл) и попробуйте реализовать на Python простой RAG-пайплайн тремя способами: (а) в Open WebUI, взаимодействуя через его API, (б) с помощью LangChain или LlamaIndex по примеру из статьи, и (в) вручную, используя SentenceTransformer для эмбеддингов и FAISS для поиска.

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

Часть 4.