Всем привет!

Ну что, началось)
https://www.piter.com/collection/all/product/programmirovanie-na-python-s-pomoschyu-github-copilot-i-chatgpt
Ок, ещё одна книжка про ChatGPT. Смотрим аннотацию: «Используя GitHub Copilot, можно простым языком описать, что должна делать программа, а искусственный интеллект тут же сгенерирует ее.
Узнайте, как создавать и улучшать программы на Python с помощью ИИ, даже если прежде вы не написали ни строчки компьютерного кода.». И ещё: « Глава 4 — первая из двух глав, в которых вы научитесь читать код на языке Python. Действительно, Copilot будет писать код за вас, но вам нужно уметь читать его, чтобы определить, будет ли он делать то, что вы хотите. И не волнуйтесь: Copilot поможет вам читать код!»
И это не ролик, не статья, целая книга...
Войти в IT, если с первого раза не получилось) Интересно, на собесах Copylot уже используют?)
Меня только один вопрос мучает: если человек не захотел или не смог освоить язык программирования (фреймворк) - как хорошо он сможет спроектировать сервис или алгоритм?

#llm #dev

Всем привет!

Немного мыслей по AI моделям.

Вышло довольно много open source моделей - LLama от запрещенной Meta, Mistral, DeepSeek, Grok 1 от Twitter. Еще есть Gemma от Google - легкая, возможно не самая новая модель, специализированные модели от OpenAI. Это хорошо, так как дает возможность подключения к разработке моделей команд, не имеющих большого числа денег на GPU. Дообучение моделей (fine tuning) дешевле первичного обучения. Запуск уже обученной модели - тоже дешевле. Плюс open source - это гарантия, что к AI будет доступ даже если сервисы, описанные мной ранее по тем или иным причинам закроются. И Мета конечно выделяется среди остальных тем, что отдала в open source последнюю тяжелую (большое число параметров) версию модели.

Второй момент: в тестах и в новостях сравниваются 2 группы моделей - общего назначения и специализированные. Общего назначения - ChatGPT, Claude, Gemini, Llama, Grok, DeepSeek, Mistral, YandexGPT, GigaChat. Специализированные, на примере разработки - DeepSeek-Coder-V2, Codestral, CodeLlama, Phind, GigaCode. Можно сделать вывод, что модели последнего поколения достаточно мощные, чтобы хорошо справляться со специализированными задачами, типа написания кода. Но любую модель всегда можно подтюнить, и тогда она или превзойдет модель общего назначения или будет сравнима с ней даже имея меньший размер (требуя меньше железа).

Еще тренд - разделение моделей на легкие и тяжелые. Например, LLama 8b, 70b и 405b, это число параметров в billions. Т.е. есть понимание, что большие модели - это дорого в облуживании, при этом во многих случаях применяются для "стрельбы из пушки по воробьям". Некоторые модели позиционируются как доступные для запуска локально. Локально с правильной видеокартой или AI чипом https://ru.msi.com/Landing/AI-Laptop/nb конечно)

#ml #ai #llm

Всем привет!

Я снова вернулся)

И предновогодний пост будет снова про AI и Java.

Для начала про LLM. Чтобы LLM дала осмысленный ответ - ей нужен правильный промт и побольше контекста. Не даром в новых версиях моделей объем контекста растет - возьмем тот же Gemini с 1 млн токенов.
Но с точки зрения разработки - важен не только объем, но автоматизация работы с контекстом, т.е. некая бизнес-логики. Например, если мы делаем свой агент и у нас несколько источников точных данных, которые мы хотим скормить модели. И эта бизнес-логика скорее всего будет похожая у разных агентов...
LLM - область достаточно молодая, стандарты в ней зарождаются прямо сейчас. Встречайте MCP https://spec.modelcontextprotocol.io/specification/ - сайт стандарта - и https://habr.com/ru/articles/862312/ - интро на русском.
Он стандартизирует в первую очередь транспортное API - клиент и сервер - для работы с источниками точных данных и LLM. Содержит ряд готовых серверов для работы с файловыми данными, СУБД, веб-поиском.

Как это все относится к Java? А вот как: есть Spring AI, уже писал про него https://t.me/javaKotlinDevOps/241 Он дает универсальное API для обращения к различным LLM. Сейчас туда добавили - в статусе experimental - Spring AI MCP https://docs.spring.io/spring-ai/reference/api/model-context-protocol.html
Причем добавили достаточно быстро, хотя до Python конечно же далеко. Вообще поддержка Python, я полагаю, появилась вместе со стандрартом)

P.S. Да, вспоминая Kotlin в названии канала - если посмотреть примеры Spring AI - получите, распишитесь: https://github.com/spring-projects/spring-ai-examples/blob/main/kotlin/

#llm #spring

Всем привет!

Ну что, AI уже заменил джунов
https://habr.com/ru/news/876162/
?
А если серьёзно - это третий шаг в эволюции LLM:
1) запрос-ответ по данным модели
2) обогащение ответа модели актуальным результатами поиска (AI search, например, Perplexity или SearchGPT) или результатами из локальной базы знаний (RAG)
3) AI agent - не просто отдаёт отчёт, но и делает что-то полезное, но рутинное. В IDE, локальной сети или в интернете. По запросу или в фоновом режиме.

Что ж, движение в верном направлении.
Вот пример агента не из мира разработки https://t.me/disruptors_official/2177
Главное, чтобы качество Junie было на уровне, на данный момент AI - не самая сильная сторона JetBrains.

P.S. GigaCode, к слову, идёт туда же. Один из лидеров - Cursor AI. Позволяет восьмилетним детям писать код))) https://vc.ru/services/1456812-vosmiletnie-deti-teper-mogut-sozdavat-prilozheniya-s-pomoshyu-iskusstvennogo-intellekta-obzor-ii-instrumenta-dlya-programmirovaniya-cursor

P.P.S. Вопрос. Если заменить всех джунов - откуда возьмутся миддлы и сеньоры?)

#llm

Всем привет!

В последнее время все чаще вижу, как LLM в IDE используют для генерации каркаса приложения. Казалось бы - это же задача генератора, а не LLM. Какого-нибудь Spring Initializr (https://start.spring.io/) Почему он этого не делает, а ограничивается по сути только pom-ников или *.gradle?

Потому что это отдельный сервис, требующий поддержки. Который со временем - по мере развития библиотеки, фреймворка или платформы, для которой он предназначен - будет обрастать все более сложной логикой. Обновился фреймворк - нужно обновлять генератор. Появился смежный компонент - будут запросы на добавление интеграции с ним. И при этом генератор все равно будет ограничен в возможностях. Возьмем тот же Amplicode - контроллеры, обработчики ошибок и тесты для Spring приложения он генерировать умеет, что-то еще - нет. Со временем возможностей для генерации будет больше, но 100% кейсов не будет покрыто.

А LLM в теории может сгенерировать что угодно, главное "скормить" ей побольше типового кода. Ключевое слово здесь - типового. Т.е. какую-то сложную логику тоже можно сгенерировать в LLM, но если размер диалога будет в 10 раз больше сгенерированного кода, а время - сравнимо, есть ли в этом смысл? Да, модель нужно будет периодически "подкармливать", но видится, что эту процедуру можно автоматизировать взяв за исходные данные открытый код из того же github.

Есть еще нюанс. LLM - это аналог MP3 128 kBit Joint Stereo ))) Сжатие с потерями. Это если что моя оценка вида "пальцем в небо", очень может быть степень сжатия больше. Распаковка - генерация кода - тоже приведет к потерям. Как проверить, что потерь нет - компиляция, тесты, а главное - предварительная оценка того, насколько типовой код нужен. В итоге для простых задач мы получаем универсальный генератор. И это круто!

P.S. Может показаться, что я наехал на Spring Initializr. Нет, штука полезная. Фактически Spring задали стандарт на рынке - все конкуренты Spring сделали свои инициализаторы: https://code.quarkus.io/ и https://start.microprofile.io/ И в Enterprise я видел попытки сделать свои инициализаторы разной степени успешности.

#llm #ai #code_generation

Всем привет!

Учитывая бурный рост AI - в части возможностей и точности ответов - возникает вопрос: что будет с профессией программиста в частности и ИТ-шника в общем?
Пару мыслей по этому поводу.

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

Что изменится?

2) Для начала - должна вырасти производительность. Пример: объяснить почему при наличии AI простая формочка делается несколько дней будет сложно. Хочешь - не хочешь, фичей придется выдавать больше. Можно привести аналогию со станками и конвейером - и то, и другое позволило в разы увеличить объем производства. А если брать более близкий нам пример - появление персонального компьютера, на который не надо записываться в очередь и скармливать ему перфокарты - также сильно увеличило производительность программиста. Получаем реально существующий NZT - ускоритель для мозга или bycicle of mind - за напоминание спасибо @AViIgnatov!

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

4) интересный вопрос насчет T-Shape vs узкий специалист. С одной стороны узкого специалиста сложнее заменить, особенно, если его фреймворк не очень распространен. С другой стороны рутина отдается на откуп LLM, поэтому от менеджеров будет ожидание горизонтального роста на смежные специализации. Что можно сказать точно - разработчик узкого профиля, умеющий в аналитику, тесты и не боящийся ПРОМа - точно незаменим)

5) Самый интересный момент - что будет с джунами? Т.к. теперь джун должен уметь не только писать промты, но и проверять качество кода. Это либо повышенные требования к ВУЗу\курсам, или растянутая по времени стажировка, во время которой джун должен "обогнать" LLM. Хорошая новость: если вы - джун время прокачаться до сеньора еще есть)

#it #llm

Всем привет!

Вот только написал, что исследовательские задачи — точно не место для AI, как на тебе https://t.me/andre_dataist/172 )))

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

P.S. Ещё интересны 4 и 5 уровень развития моделей из поста выше.

#llm #ai #it

Всем привет!

Я долго держался, но не написать о Deepseek всё же не смог)

Что хотелось бы отметить:
1) Модели уже больше года, а в январе стали известны (распиарены) результаты её последней версии

2) Начиналось всё с модели для разработчиков, называется Coder, потом был Coder v2

3) Тренд на универсализацию моделей продолжается, сейчас Coder недоступен на официальном сайте, только основная модель

4) В окне ввода промпта можно включить объяснение логики получения ответа — и это новый тренд. По сути это данные аудита. В применении к AI-агенту — данные будут храниться определённое время для разбора полётов

5) И последняя фича DeepSeek — возможность AI-поиска, уже не тренд, а скорее становится базовым требованием

6) Разработчики Deepseek связаны с алгоритмическим трейдингом. С одной стороны, это деньги на разработку модели и железо, с другой — источник знаний для оптимизации модели. В алгоритмическом трейдинге решают миллисекунды

7) Ну и наконец — «я же говорил».
Пост про сравнение AI-моделей: https://t.me/javaKotlinDevOps/331. Единственный момент — тогда мне больше понравилась Perplexity. Надо будет сравнить ещё раз)

8) В Perplexity уже встроили модель Deepseek как один из вариантов

9) Deepseek можно развернуть локально, см. инструкцию https://habr.com/ru/articles/878276/. Т. е., в open source выложили всю модель. Удивляют системные требования

10) Ходят слухи, что Deepseek будут внедрять и в одной крупной российской ИТ-компании.

#llm #ai

Всем привет!

AI быстро развивается, интегрируется с традиционным ПО и было бы странно, если бы и для AI не появились ... свои паттерны)
Встречаем, от одного из лучших специалистов по паттернам: https://martinfowler.com/articles/gen-ai-patterns/

Маленький комментарий: да, AI паттерны могут показаться элементарными, но свою роль они выполняют - это некий язык, кубики, из которых строится архитектура приложения/корпоративная архитектура.
Еще хорошо написано про такую важную штуку как оценка (eval). Ведь модели не идемпотентны - могут менять свой ответ на одних и тех же входных данных. А значит традиционные практики тестирования не подходят. Модель тестирующая сама себя - прямой путь к скайнету) А вот если взять другую модель, а для страховки отдать результат на проверку человеком...

#llm #ai #testing #patterns

Всем привет!

Протестировал последнюю версию GigaCode, доступную наружу, небольшой итог.

Что понравилось:
1) неплохо генерирует тесты, подбирает разные входные данные для попадания в разные ветки алгоритма. Не уверен, что полнота покрытия 100%, но неплохо
2) генерирует каркас для Spring приложения - контроллер, сервис, адаптер. Да, AI генерация рулит.
3) можно использовать для подключения новых библиотек по имени класса. Единственный минус - подставляет не последние версии
4) может заменить все println на вызов логгера в файле
5) GigaCode научился работать с контекстом всего проекта, а не только открытых файлов. По факту: на больших проектах не тестировал, но на малых все равно делает ошибки - в autocomplete предлагает несуществующий метод. Похоже имя метода генерируется как производная от названия переменной, в которую сохраняется результат вызова) К слову, встроенный в IDEA бесплатный AI делает ровно те же ошибки. Нужен ретест, но в любом случае это движение в правильном направлении.
6) находит ошибки при вызове /improve. Не все, на моем тестовом файле с порядка 50 ошибками нашел 4. Уже что-то. Предложил использовать try-with-resources, конкатенацию строк заменить на StringBuilder, также нашел проглатывание ошибки без логирования и некорректное удаление в цикле. Также умеет удалять дублирующиеся методы. Но не умеет выносить повторяющийся код в отдельный метод.
7) вызов /review - тут уже интереснее. Я вызывал его до /improve и после. На первом ревью модель нашла отличающийся по сравнению с improve набор проблем. Понятно, для некоторых из них простого фикса нет, но например найденный на ревью возврат null можно было бы пофиксить на improve. Еще интереснее прошло ревью после применения улучшений. Модель поставила под сомнение использование try-with-resources и StringBuilder сказав, что "в данном случае это не имеет большого значения, так как количество строк в файле, вероятно, не очень велико". Как она поняла, что данных мало - непонятно) Вообще говоря, замечание справедливо, в разработке очень редко можно дать однозначный ответ без уточнения деталей. Но как будто бы пропущен вопрос - с каким объемом данных мы работаем? Аналогично, про правку при удалении в цикле - уменьшение счетчика, сказала, что он затрудняет читаемость и может привести к ошибкам. Т.е. 3 из 4 собственных правок под вопросом) Еще модель выдала неверное замечание про то, что try-catch приводит к созданию объекта исключения, хотя по факту он возникает в библиотечном коде, который вызывается внутри try-catch

И три недостатка:
1) команда /doc Да, она хорошо генерирует JavaDoc по названию и содержанию метода. И да, есть такое правило в SonarQube. Но я считаю, что правило обязательных JavaDoc надо отключать, методы, переменные и классы называть осмысленно, и только в отдельных сложных случаях добавлять JavaDoc. Видимо сделано для ленивых программистов)
2) кэширование. Тестируя /review и /improve на изменяющемся файле постоянно сталкиваюсь с тем, что ошибка уже поправлена, а модель все еще ругается на нее. Да, для review помогает ctrl+enter, непонятно зачем на обновление контекста нужно отдельное сочетание клавиш. А improve по-прежнему пытается исправить уже исправленные ошибки)
3) для improve напрашивается кнопка "заменить", т.к. сейчас приходится выделять все и жать на insert

Вывод - в целом использовать можно.

#llm #ai #gigacode

Не Spring-ом единым...

Появилась еще одна библиотека для Java для работы с LLM, а точнее конкретно с OpenAI. Официальная, от OpenAI
<dependency>
<groupId>com.openai</groupId>
<artifactId>openai-java</artifactId>
<version>0.22.0</version>
</dependency>

На что хотелось бы обратить внимание:
1) OpenAI наконец то "дошла" до Java разработчиков
2) Разработчики библиотеки очень любят method chaining (ссылка на статью с примерами в конце поста). Со стороны даже кажется, что череcчур, можно было бы и по-короче инициализировать библиотеку
3) есть поддержка web-поиска
4) есть неочевидное разделение на Completion API - простые вопросы к LLM, типа "как на Java получить список файлов в каталоге" и Assistants API - "напиши мне микросервис, возвращающий курсы акций на бирже". Почему неочевидное - в моделях я вижу обратную тенденцию к унификации, когда одна модель используется для всех типов задач.
5) Assistants API умеет в File Search и Code Interpreter

И небольшой каталог решений по работе с LLM на Java:

1) Spring AI - https://docs.spring.io/spring-ai/reference
Примеры использования:
hello world https://habr.com/ru/articles/784128/
Более сложные примеры
https://piotrminkowski.com/2025/01/28/getting-started-with-spring-ai-and-chat-model/
https://piotrminkowski.com/2025/01/30/getting-started-with-spring-ai-function-calling/
Telegram bot, OpenAI и Spring AI https://habr.com/ru/companies/dockhost/articles/884876/

2) langchain4j https://github.com/langchain4j/langchain4j Характерно, что проект сделан на основе одноименной Python библиотеки. Поддерживается в Quarkus https://www.baeldung.com/java-quarkus-langchain4j

3) прямая интеграция с OpenAI https://www.baeldung.com/java-openai-api-client

P.S. Возможно Assistants API "жрет" больше токенов, отсюда и разделение

#llm #openai #ai #spring