Основные проблемы AI в разработке.
Я вижу две основные проблемы.
Первая - принципиально недетерминированный ответ как отражение вероятностной природы LLM. Если в креативных задачах это плюс, но в разработке скорее минус.
Вторая - естественный язык не самое лучшее API из-за своей неоднозначности.
И для второй, а частично и для первой проблемы есть решение - паттерн structured output. Суть проста - мы говорим модели, в каком виде хотели бы получить ответ. Это может быть JSON схема или класс Response. Базовый формат - JSON, но он на уровне библиотеки легко трансформируется в класс для большинства языков программирования. Ключевой момент - вызов модели должен вернуть правильный по структуре JSON с вероятностью 100%. И далее его можно или без лишних проверок парсить и передавать на вход следующему методу.
Реализован паттерн должен быть в самой модели, так как на уровне библиотеки или промта гарантии 100% соответствия получить нельзя.
Вот статья с примером использования:
https://habr.com/ru/articles/923096
P.S. Паттерны есть везде, коллекция AI паттернов постепенно растёт)
#ai #llm
Я вижу две основные проблемы.
Первая - принципиально недетерминированный ответ как отражение вероятностной природы LLM. Если в креативных задачах это плюс, но в разработке скорее минус.
Вторая - естественный язык не самое лучшее API из-за своей неоднозначности.
И для второй, а частично и для первой проблемы есть решение - паттерн structured output. Суть проста - мы говорим модели, в каком виде хотели бы получить ответ. Это может быть JSON схема или класс Response. Базовый формат - JSON, но он на уровне библиотеки легко трансформируется в класс для большинства языков программирования. Ключевой момент - вызов модели должен вернуть правильный по структуре JSON с вероятностью 100%. И далее его можно или без лишних проверок парсить и передавать на вход следующему методу.
Реализован паттерн должен быть в самой модели, так как на уровне библиотеки или промта гарантии 100% соответствия получить нельзя.
Вот статья с примером использования:
https://habr.com/ru/articles/923096
P.S. Паттерны есть везде, коллекция AI паттернов постепенно растёт)
#ai #llm
Хабр
Structured Output как полноценная замена Function Calling
В этой статье мы рассмотрим альтернативный подход вызова инструментов LLM, который использует Structured Output вместо традиционного Function Calling для обеспечения надежности...
Разработчики AI переизобрели CSV
А теперь серьезно)
Я уже писал, что LLM общаются с помощью JSON и обработка JSON - не то, с чем LLM хорошо работает: https://t.me/javaKotlinDevOps/484
Поэтому появился TOON.
Почему не YAML или что-то еще?
Данный формат заточен под компактность и удобство обработки LLM. По сути это CSV с метаданными.
Чтобы не быть голословным - пример:
JSON
TOON
Разница видна невооруженным глазом. Разные тесты показывают выигрыш по размеру на 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
А теперь серьезно)
Я уже писал, что 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
Telegram
(java || kotlin) && devOps
LLM как серебряная пуля?
Конечно же нет.
А если серьезно - что не умеет LLM?
1) выдавать актуальную информацию. Фиксится подключением веб-поиска
2) выдавать 100% точные ответы. LLM вероятностна по своей природе, поэтому даже самая мощная модель с огромным…
Конечно же нет.
А если серьезно - что не умеет LLM?
1) выдавать актуальную информацию. Фиксится подключением веб-поиска
2) выдавать 100% точные ответы. LLM вероятностна по своей природе, поэтому даже самая мощная модель с огромным…