Регулярная рубрика - новости AI.

Нашел очередную статью про RAG https://habr.com/ru/companies/raft/articles/954158/
Казалось бы, нашел и нашел.
Но что интересно.
Вот есть AI. AI агент для примера.
Он общается с LLM.
LLM бывают разные.
Можно прикрутить AI proxy для совместимости по API.
А еще есть разные фреймворки для построения агентов.
Агент вызывает какие-то тулы.
Или MCP сервера по некому стандартизированному протоколу.
Или другого агента, для этого тоже есть стандартизированные протоколы.
Как источник домен-специфичных данных агент использует RAG.
RAG - это векторное хранилище, они бывают разные. Как специализированные, так и в виде расширения того же PotgreSQL.
Плюс есть технология преобразования данных (текстовых как правило, но не только) в векторный формат (embedding). Это тоже разные специализированные модели (но не те модели, что обрабатывают запрос пользователя).
Плюс есть технология разбиения данных на части (chunks), т.к. поиск по RAG - это сравнение векторов. Поэтому размер вектора для сравнения должен быть конечен, а документы в теории могут весить многие мегабайты.
Так вот. Даже для разбиения докумнетов на chunks уже появилось несколько конкурирующих библиотек, про это статья в начале поста.

О чем это говорит? Растет экосистема. Т.е. технология LLM потихоньку приходит к своей зрелости.

P.S. И поспорю сам с собой: за этот год по словам компетентных людей (я только учусь) сменилось три (!) принципа построения AI агентов.

#ai #rag

LLM как серебряная пуля?

Конечно же нет.
А если серьезно - что не умеет LLM?

1) выдавать актуальную информацию. Фиксится подключением веб-поиска

2) выдавать 100% точные ответы. LLM вероятностна по своей природе, поэтому даже самая мощная модель с огромным контекстным окном с выверенным промтом может галлюцинировать

3) отвечать на доменноспецифичные вопросы. Фиксится RAG, куда закачивается доменная специфика

4) выполнять сложные вычисления. Опять же LLM - статистический вычислитель, а не математический. Решается вынесением вычислений в тулы

5) работать с большими объёмами информации. Над этим - контекстное окно - работают все разработчики LLM, окно уже превышает 1 млн токенов, но в любом случае оно конечно. А ещё токены стоят денег. Альтернативныое решение - помещение больших документов в RAG, чтобы не гонять их туда сюда, или разбиение на части (chunks) перед взаимодействием с LLM.

6) формировать JSON. Ладно, если быть точным - плохо умеет. Как ни странно, уменьшение размера и упрощение шаблона ответа может ускорить его генерацию. structured output не спасает

7) приготовить еду, изготовить телефон, построить дом. В общем взаимодействовать с физическим миром напрямую

8) понимать людей. Да, модель отвечает на любой вопрос. Ну почти любой, цензура как никак) Да, кому-то AI уже заменяет "кожаного" собеседника. Но в описанных случаях будет получен некий среднестатистический ответ, который должен порадовать спрашивающего. А если ваш вопрос уникальный и сложный, то промт должен быть непротиворечивым, компактным и структурированным. Так ли общаются люди? Да нет)))

9) изобретать, ставить задачи, мыслить. Опять же - LLM - это просто статистическая машина, обученная на большом объёме данных.

Так что кожаным мешками работа ещё найдётся.

P.S. и не только строителя дата-центров)

#ai

Разработчики AI переизобрели CSV

А теперь серьезно)
Я уже писал, что LLM общаются с помощью JSON и обработка JSON - не то, с чем LLM хорошо работает: https://t.me/javaKotlinDevOps/484
Поэтому появился TOON.
Почему не YAML или что-то еще?
Данный формат заточен под компактность и удобство обработки LLM. По сути это CSV с метаданными.
Чтобы не быть голословным - пример:

JSON

{ "users": [ { "id": 1, "name": "Alice", "role": "admin" }, { "id": 2, "name": "Bob", "role": "user" } ] }  

TOON

users{id,name,role}: 1,Alice,admin 2,Bob,user

Разница видна невооруженным глазом. Разные тесты показывают выигрыш по размеру на 20-60%, см. https://habr.com/ru/news/966734/
Но есть нюанс - по сути у нас таблица, и максимальная выгода получается на табличных данных. На вложенных структурах - сильно меньше.
Плюс улучшается точность работы модели, но уже не так сильно - процентов на 5.
С другой стороны модели в плане точности ответа уже дошли до такого уровня, когда любые проценты важны.

Другой важный момент - мир AI становится все ближе к обычному ИТ. Примеры:
1) TOON как оптимизированный протокол. Не gRPC, но движение в том же направлении.
2) все актуальнее в связи с нехваткой железа в датацентрах становится кэширование - как в рамках сессии, так и долгосрочное. А это тянет за собой TTL, инвалидацию кэша...
3) structured output - https://t.me/javaKotlinDevOps/473 - это тоже шаг к традиционным программам
4) RAG как некий аналог БД микросервиса

Что дальше?
Многопоточность? Полноценная БД? Транзакции? Очереди?

#ai #llm

Всем привет!

Я вернулся)

Вернуться заставило вот это видео Егора
Бугаенко https://vkvideo.ru/playlist/3430647_-1001/video-226887147_456239441

Рекомендую. Егор делает то, что у него лучше всего получается) После просмотра возникает один вопрос - так, а что с AI?)

P.S. Ещё из интересного в докладе - linter для shell скриптов https://www.shellcheck.net/# С хорошим online редактором, что важно, т.к. не всегда есть пайплайн, куда можно его включить.
А из грустного - ArchUnit, о котором я хотел написать, все ещё сыроват. Но все равно напишу про него и Spring Modulith.

P.P.S. Надо было в конце доклада майку разыграть. С одной известной надписью-мемом)

#ai #linter #xunit

Заметка про стандартизацию AI.

Вот и кандидат на стандарт для хранения контекста диалога подъехал https://habr.com/ru/companies/bothub/news/972054 Не факт, что именно эта технология, см. Китай и Гонконг, но сам принцип вполне может стать стандартом.

P.S. Не понимаю, правда, почему его с RAG сравнивают. RAG для хранения доменноспецифичных данных

#ai

Небольшой комментарий про quantum resistant фичу в новой Java.

Да, кажется что ещё рано беспокоится.

Но кто мешает задампить что-то зашифрованное сейчас, и взломать при появлении работающего квантового компьютера?

Ещё момент - AI был известен в узких кругах давно, а для широкой публики возник внезапно только при года назад, когда появились более менее работающие LLM

#ai #security

Зачем нужны MCP сервера?

Как я уже говорил: основная проблема AI в разработке - результат работы AI по определению не детерминирован, а код должен решать какую-то определенную задачу с строгой бизнес-логикой.
А что, если не придумывать код на ходу - а это по сути восстановление информации после ее сжатия с потерями - а просто понять, какой именно код нужен и взять готовый пример.
Эту проблемы может решить MCP сервер, в который загрузили официальную документацию с примерами.
Например, https://context7.com/?q=spring
Идея кажется отличной, но есть пару вопросов:
1) по приведенной выше ссылке - какой источник для Spring мне выбрать? Где больше токенов? Или более новый? Или по всем искать? (но это же долго)
2) как понять, что информацию загрузили правильно - всю, без искажений? к какой именно версии относится? у каждого источника есть Benchmark, но как и кто мерит - не ясно
3) кто отвечает за загрузку? предполагается, что это делают авторы библиотек https://context7.com/docs/adding-libraries , но по факту это не так. будет ли загрузка по данному источнику и дальше работать? если это энтузиасты - большой вопрос... одно дело быть автором open-source библиотеки, другое - безымянным автором источника данных в context7

Вообще идея крутая - зачем восстанавливать информацию или парсить интернет, когда можно подсунуть LLM точный источник. Ее бы стандартизировать (что будет с context7 через год? хорошо, если он станет Docker в своей области, а если нет?), популяризовать и прикрутить верификацию авторов - вообще идеально бы было. Сделал jar - добавь source jar, javadoc jar и mcp сервер.

#mcp #ai