Всем привет!

Протестировал последнюю версию 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

AI на практике или учимся читать с помощью AI)

Вот есть неплохая статья - введение в тему работы с ElasticSearch и JPA на Java+Spring https://habr.com/ru/companies/rostelecom/articles/851658/
Всем она хороша, кроме одного - 1700 строк, 120 кб текста, время для чтения - 41 минута. И как нетрудно догадаться - статья покрывает все основные темы по поиску с помощью Elasticsearch, но там прям много воды. Может автору за символы платят, хз)
Но повторюсь по сути все ок.
И тут казалось бы - вот звездный час AI. Тем более они теперь с интернетом дружат.

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

Итоги такие:

0) вне конкурса - пересказ в браузере Яндекс. Сокращает - отлично, но очень тезисно получается, ничего не понятно. Незачет

1) YaGPT - сказал, что не умеет, отправил на внешние сайты. Незачет

2) DeepSeek - полное фиаско. Во-первых забавный факт - когда я забыл отжать галочку: "искать в вебе" - модель стала пересказывать какую-то левую статью про работу с LLM. Включил галочку - модель увидела в ссылке слово rostelecom и стала пересказывать тарифы оператора. Ок, включаю режим рассуждений. Снова мимо, причем с дико странной формулировкой: "Мы не можем напрямую загрузить и обработать веб-страницу, но я могу вспомнить или найти ключевые моменты статьи, основываясь на ее содержании, если я с ней знаком." И далее снова левая статья и ее пересказ. В общем No comments, не пересказ - не конек DeepSeek

3) GigaChat - пересказал всю статью, сильно лучше Яндекс браузера, но потом пошли глюки. В первой версии пересказа был только код, почти без текста. Непонятно. Попросил добавить текста - исчез весь код. Попросил совместить - начал придумывать какие-то левые классы, т.е. потерял контекст. Еще работает медленно. Незачет

4) Perplexity - в целом неплохо пересказал с первого раза. Но - потерял последнюю треть документа - похоже на оптимизацию. Добавил недостающее после указания конкретных глав. Если просишь добавить без конкретики какие главы пропущены - все равно пропускает. Причем чем больше просишь - тем компактнее становится итоговый текст, т.е. видно, что модель экономит контекст. Еще минусы:
а) переставляет местами главы, причем не релевантно смыслу.
б) оставляет мало текста, приходится просить добавлять текстовые описания для атрибутов и вариантов реализации

5) Mistral - примерно все тоже самое, только в первой версии пересказа вообще практически не было текста, только код. Хотя просил я другое. После просьбы добавить текста - добавил. В остальном работает также, как Perplexity, с теми же минусами

Вывод: похоже с первого раза выдать нормальный пересказ большой статьи современные LLM не могут. И это даже не книга. Причина в оптимизации из-за ограниченного контекста. Но в режиме переписки работать можно.

P.S. И статья на 120 кб - это конечно перебор) Я люблю читать - но все равно перебор)

#ai #llm #elasticsearch #java #spring

Борьба с длинной контекста

Два поста назад я проводил эксперимент с LLM - пытался прочитать статью быстрее, скормив ее AI и попросив пересказать.
Ни одна из протестированных моделей с этим не справилась с первого раза, в лучшем случае приходилось подсказывать с указанием пропущенных при пересказе частей.
И я уверен, что причиной является ограниченность контекста модели.

Есть ли тут выход?
Но во-первых очевидный - линейное увеличение размера контекста модели.
Но есть и менее тяжелый с точки зрения железа вариант.
Совместить LLM c RAG.
Документ, или набор документов загружается в RAG. Это фаза анализа.
Далее можно задавать вопросы по загруженному контенту.
Можно даже базовые вопросы вынести в UI - сформируй оглавление, перескажи...
Основной "прикол" такой архитектуры - данные хранятся не в контексте, а в RAG-е, не вытесняются из него с новыми запрсоами.
А при запросе пользователя вначале производится "поиск" в RAG и обогащение контекста, далее - запрос к LLM модели. Самое главное - при этом передается только часть содержимого RAG.

Инструментов с такой архитектурой много, вот здесь проведено небольшое исследование https://dzen.ru/a/Zu8KfXtWcUk-ngpo?ysclid=mczw93o1xo25962418
Причем есть и локальные версии, где на сервер "к дяде" ничего не передается.
Я же попробовал скормить ту же статью NotebookLM (статья общедоступная, решил не заморачиваться).

И результат был существенно лучше: я с первого раза получил полный пересказ без пропусков глав в том же порядке, как и в исходной статье.
Но не идеален - в статье много кода, и весь код уехал в сноски. В целом подход нормальный для всех, кроме разработчиков(
Как заставить NotebookLM не прятать код под сноски - не нашел( Возможно, не был достаточно убедителен) Возможно - системные промты сильнее)
Кажется это был бы последний штрих для идеального инструмента...

#ai #llm #rag

Что станет с языками программирования?

Недавно на одной AI конференции услышал две довольно радикальные мысли.
1) программирование на высокоуровневых языках исчезнет повторив судьбу ассемблера. Останутся только архитекторы.
2) если модели не нравится ваш код - в смысле она не может его доработать - значит проблема в коде

Вот мои мысли по этому поводу.

1) Эти два утверждения работают только вместе. Т.е. если LLM модель пишет код, то он стандартизирован. И тогда любой нестандартный код - плохой. Т.к. он нарушает code style. Назовем его AI code style. И потому что раз уж мы отдали писать код модели - не надо ей мешать

2) С одной стороны аналогия с заменой ассемблера языками высокого уровня красива. И некие аналогии тут есть. Скорость разработки в теории может так же ускориться. Сложность систем, которые можно разработать, вырастет. А запрос как на повышение скорости разработки, так и на создание все более сложных систем, есть. Да, программирование на LLM - это тоже переход на более высокий уровень

3) Где аналогия хромает? Что общего у ассемблера и Java. Оба они детерминированы. Как и разработка в целом. Да, у нас есть место случайности, но она сосредоточена в нескольких местах - реализация функции random, генерация уникальных идентификаторов приходят на ум. А LLM принципиально недетермирована. Использование недетермированной машины для выполнения детерминированного процесса - ну такое себе.

4) Программирование уже пытались убрать из процесса разработки коммерческого ПО. Вот сейчас появилось много AI платформ для no code (low code) разработки. Знакомые же слова. Я про "no code". Да, BPMN системы. И различные проприетарные low code платформы. Свою ниши они заняли, но эти ниши достаточно узкие. Tilda самый очевидный пример. Но если говорить о глобальной замене программирования и программистов - не взлетело

Что думаете по этому поводу?

#ai #llm #lang

И снова AI агенты...

AI агент по определению должен делать что-то полезное, делать это с использованием AI, автономно и недетерминировано.
Сейчас я хочу рассмотреть свойство полезности.

AI агент в чем-то похож на умный proxy. Ум обеспечивает LLM (или не обеспечивает, тут идут споры))) ). А далее агент вызывает некую существующую функцию. Или несколько функций.
В терминологии AI это tool:
1) https://python.langchain.com/docs/concepts/tools/
2) https://docs.spring.io/spring-ai/reference/api/tools.html

tool - вообще говоря это просто метод Java, Python или любого другого языка, аннотированый соответствующим образом.
Как агент понимает, что умеет tool? Аннотации с описанием назначения тула, входных и выходных параметров.

Но если подумать - мы же живем в REST мире, в нем победил OpenAPI, а там вся необходимая информация есть. И текстовые описания, и граничные значения, и примеры. Даже адреса серверов на разных средах можно в спеке указать.
Нельзя ли это как-то переиспользовать? DRY все таки!

Можно. https://python.langchain.com/docs/integrations/tools/openapi/ на примере Python
Загружаем спеку, преобразуем в формат, понятный AI и создаем агента:

with open("spotify_openapi.yaml") as f:
raw_spotify_api_spec = yaml.load(f, Loader=yaml.Loader)
spotify_api_spec = reduce_openapi_spec(raw_spotify_api_spec)
...
spotify_agent = planner.create_openapi_agent(
spotify_api_spec,
requests_wrapper,
llm,
allow_dangerous_requests=ALLOW_DANGEROUS_REQUEST,
)

Почему не Java?
https://github.com/langchain4j/langchain4j/issues/1307
Ждем-с.
Что-то делается и для Spring AI, но пока сторонними разработчиками https://readmedium.com/connect-existing-openapis-to-llms-with-spring-ai-039ccabde406

Это самый простой способ вызвать существующий функционал.
Если он не подходит по одной следующих причин:

1) нет готового адаптера OpenAPI
2) нет OpenAPI спецификации, или она сделана криво, а доработка ее другой командой требует времени
3) хочется объединить несколько запросов в один tool или обогатить ответ tool-а локальной информацией
4) нужно убрать лишнее из ответа

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

Ну и третий вариант - отдельный MCP сервер https://t.me/javaKotlinDevOps/376.
У него два плюса:
1) MCP API - это специализированное API, адаптированное для использования LLM
2) tool-ом в виде MCP сервера может в теории воспользоваться любой AI агент

#ai #llm #spring #python

Если LLM не понимает твой код (процесс)...

В продолжение поста про мысль о том, что код, который не понимает LLM - плохой код.

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

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

P.S. Вопрос конечно провокационный, но справедливости ради в попытках заставить LLM отвечать корректно я нашел ряд логических противоречий в промте. И перешел от 3 агентов к одному, т.к. в рамках одного проще поддерживать непротиворечивость промта.
P.P.S. Все же русский язык совсем не идеален для описания бизнес-логики.
..P.S. Как со всем этим делать мультиагентную систему, где логика пишется разными людьми и выполняется разными агентами - вопрос.

#llm #ai

Новости AI

1) появился инструмент сравнения разных LLM моделей - один забра запрос передаётся в 2 разные модели, скорость и качество ответа можно сравнить глазами. https://lmarena.ai/ Что интересно - доступны коммерческие LLM без регистрации и СМС, в смысле без VPN и оплаты

2) сейчас у большинства AI чатов появляется режим Research. Это ризонинг + поиск в интернете + какой-то набор tool для обработки полученных данных. Ещё из важного: составляется план исследования и дозапрашиваются непроходимые данные у пользователя. По сути это AI агент, заточенный под исследования.
Недавно тестировал такой режим у Mistral.
На мою просьбу сравнить скорость сборки Docker образов, модель не просто поискала в интернете тесты, а вначале уточнила сложность образа и возможность включить кэширование(!), после чего сделала вот такой план выполнения запроса:
1) создать docker файлы с нужным настройками
2) сформировать команду для измерения времени сборки для всех видов сборки
3) запустить команду n раз, посчитать среднее

В ответе кроме плана и таблицы с результатами (среднее, max, min), была конфигурация тестового сервера (!!!), описание плюсов и минусов всех инструментов сборки и рекомендации по их использованию.

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

Из хорошего - инструмент доступен без VPN и есть бесплатные попытки. Полезен, если для выполнения задачи достаточно поиска. Ещё может с планом исследования помочь. Что интересно: неделю назад было 10 попыток в месяц, сейчас стало 5, кроме того появилось разделение по скорости - одна попытка быстрая, 4 - медленные. Экономика должна быть экономной)

3) OpenRouter - веб-сервис, являющийсф прокси-адаптером к куче LLM моделей с ChatGPT API. Область применения:
а) запуск кода, написанного для OpenAPI, на других моделях
б) динамический выбор модели в зависимости от задачи/цены без необходимости хранить кучу разных credentials у себя
в) отказоустойчивость.
Из хорошего - много моделей и небольшая наценка.
Из плохого - недавно закрыли доступ из России.
Из интересного - вот тут можно глянуть рейтинг моделей, используемых для разработки https://openrouter.ai/rankings?category=programming#categories
Ясно, что он искажён в части доли ChatGPT. Т.к. если тебя полностью устраивает ChatGPT, то ты не будешь использовать прокси. Но все же интересно)

#ai #llm #ai_agents

Основные проблемы AI в разработке.

Я вижу две основные проблемы.

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

Вторая - естественный язык не самое лучшее API из-за своей неоднозначности.

И для второй, а частично и для первой проблемы есть решение - паттерн structured output. Суть проста - мы говорим модели, в каком виде хотели бы получить ответ. Это может быть JSON схема или класс Response. Базовый формат - JSON, но он на уровне библиотеки легко трансформируется в класс для большинства языков программирования. Ключевой момент - вызов модели должен вернуть правильный по структуре JSON с вероятностью 100%. И далее его можно или без лишних проверок парсить и передавать на вход следующему методу.

Реализован паттерн должен быть в самой модели, так как на уровне библиотеки или промта гарантии 100% соответствия получить нельзя.

Вот статья с примером использования:
https://habr.com/ru/articles/923096

P.S. Паттерны есть везде, коллекция AI паттернов постепенно растёт)

#ai #llm