Ilyas Salikhov

JS-модули в RetailCRM

Год назад начали активно развивать (и продолжаем развивать) JS API в RetailCRM.

Технология построена на подходе vue-remote, когда реальный код js-модуля выполняется в песочнице и его интерпретация в безопасном режиме применяется в интерфейсу системы.

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

На данный момент можно встраиваться в существующие страницы. Дальше планируем дать возможность регистрировать JS-модулям новые страницы системы. Даст новый огромный пласт для расширения системы!

Кстати код js-модулей отлично пишется AI-шкой в силу их небольшого размера и знакомого для AI стека VueJS. Плюс мы даем готовый набор компонентов, которые сами используем для построения интерфейса, что дает возможность строить интерфейсы модуля еще быстрее.

На видео все шторки и попапу рендерятся JS-модулями.

🔗 Инженерия и AI | Ilyas Salikhov

Жизнеспособен ли подход: толстый backend и тонкий frontend

На митапе (проводим их регулярно) Саша Черняев, эксперт в мире Laravel, рассказывал про Hotwire. Если кратко: сервер рендерит HTML, а браузер получает обновления частями и добавляет немного JS для поведения – вместо SPA с большим клиентским состоянием.

Я уже сталкивался с Hotwire и, чтобы опробовать, делал внутреннюю систему на стеке Symfony + Hotwire.

Из доклада узнал, что появилась поддержка мобилок. Приложения выглядят классно. Но, как понимаете, без интернета не работает от слова «совсем».

Какие впечатления от технологии сложились у меня:

➕ Плюсы

1. Работает очень быстро. По ощущениям все летает
2. Нет тяжёлой «первой загрузки» SPA-бандла
2. Не нужно возиться с Webpack/React/... и их настройкой
3. Не требуется разрабатывать API для общения бекенда и фронта
4. Готовое решение для мобилок (правда веб-ориентированное)

➖ Минусы

1. Не подходит для сайтов, которые и не сайты, а скорее приложения, аля Figma или RetailCRM со сложными интерфейсами. Логика становится запутанной
2. Разработчикам требуется достаточно уверенно чувствовать себя в обоих стеках (бекенд и фронтенд)

Когда целесообразно использовать

1. В проекте есть и бекенд, и фронтенд
2. Фронтовая логика не очень сложная
3. Проект небольшой или средний (условно до ~300k строк)
4. Команда разработчиков небольшая
5. Разработчики фуллстеки (умеют и во фронт, и в бекенд)

В таком случае Hotwire помогает быстрее стартовать, а интерфейс получается быстрым. Если же вы разрабатываете сложное «толстое» приложение с богатым клиентским состоянием, разумнее сразу смотреть в сторону SPA.

🔗 Инженерия и AI | Ilyas Salikhov

Как тестировать AI-агентов (python-пакет llm-flaky)

AI-агентов надо тестировать. С этим, думаю, никто не спорит.

Конечно, можно использовать ручное тестирование, но по мере усложнения агента это делать всё сложнее. Да и есть такая «неприятная» часть бизнес-логики, которая заложена в виде промпта. А его изменение, бывает, начинает влиять на поведение агента там, где не ожидаешь.

Короче, тесты нужны. Мы их пишем в виде обычных pytest-ов.

Но LLM — вещь недетерминированная. Сейчас она ответила так, а при следующем прогоне иначе. Мы регулярно сталкивались с «миганиями» тестов. И пришли к тому, что для LLM это ок. Они по определению не гарантируют правильный ответ в всех случаях.

Мы для себя задаем планку в 80% успешных прогонов. Реализуем через многократный прогон теста нужное количество раз. Для 80% тест должен успешно выполниться как минимум 4 раза из 5.

Все упаковали и оформили в pypi-пакет llm-flaky.

Как пользоваться llm-flaky

1. Ставите пакет

2. Размечаете llm-тесты

import pytest

@pytest.mark.llm
async def test_llm_response():
    response = await call_llm("What is 2+2?")
    assert "4" in response

3. Прогоняете и на выходе получаете красивый отчет 🙂

Вы можете настроить свои пороги успешного прохождения llm-теста, в пакете предусмотрены соответствующие параметры.

Также поддерживается рапараллеливание через pytest-xdist. Сильно ускоряет прогоны.

🔗 Инженерия и AI | Ilyas Salikhov

Как организовать работу с промптами для AI-агентов

В RetailCRM мы начинали с промптов в формате строки или f-string. Для простых промптов это ок.

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

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

Мы пришли к тому, что промпт наиболее удобно оформлять в jinja шаблонах (или любом другом шаблонизаторе) с markdown внутри. Покажу на примере.

Пример

Допустим мы решили сделать мини агента, который с помощью нашего сервиса Geohelper определит часовой пояс клиента по номеру телефона.

Сделали начальный промпт

Ты помощник, который определяет часовой пояс по номеру телефона.

Запустим

$ python get_timezone.py 89132342323
          
Номер +7 913 234-23-23

Информация о часовом поясе:
- Регион: Алтайский край
- Сдвиг от UTC: +07:00

Если нужно, могу показать текущее местное время для этого номера или конвертировать заданное время в этот часовой пояс.

Доработаем, чтобы выводил кратко и более содержательно:

Ты помощник, который определяет часовой пояс по номеру телефона.
{# Иначе выводит многословно #}
Выведи результат очень кратко и строго эти данные: часовой пояс, смещение UTC, регион и страну.

Запустим

$ python get_timezone.py 89132342323
          
Смещение UTC: +03:00
Регион: Алтайский край
Страна: Россия (RU)

Уже лучше. Представим, что мы хотим подсказывать смещение относительно нашего часового пояса.

Ты помощник, который определяет часовой пояс по номеру телефона.

Текущий часовой пояс пользователя: {{ server_timezone }} (UTC{{ "%+d" | format(server_offset) }})
Текущее время у пользователя: {{ current_time }}

{# Иначе выводит многословно #}
Выведи результат очень кратко и строго эти данные:
- Разница во времени + пример, сколько времени у пользователя и абонента
- Регион абонента
- Страна абонента

Глянем

python get_timezone.py 89132342323

- Разница во времени: +4 ч — у вас 17:37, у абонента 21:37
- Регион абонента: Алтайский край
- Страна абонента: Россия (RU)

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

Ты помощник, который определяет часовой пояс по номеру телефона.

Текущий часовой пояс пользователя: {{ server_timezone }} (UTC{{ "%+d" | format(server_offset) }})
Текущее время у пользователя: {{ current_time }}

{# Иначе выводит многословно #}
Выведи результат очень кратко и строго эти данные:
- Разница во времени + пример, сколько времени у пользователя и абонента
{% if not short %}
- Регион абонента
- Страна абонента
{% endif %}

Проверим:

$ python get_timezone.py 89132342323

Разница: +4 ч — у вас 17:43, у абонента 21:43
Регион: Алтайский край (Asia/Barnaul)
Страна: Россия (RU)

$ python get_timezone.py 89132342323 --short

Разница: +4 ч — у пользователя 17:44, у абонента 21:44

Как итог

* Промпт читаемый с подсветкой (как jinja, так и markdown)
* Работают проверки от IDE (в том числе на орфографию/пунктуацию)
* Промпт можно обогащать вкраплениями логики
* Одно из самых важных Фрагменты промпта можно дополнять комментариями

А как выглядит финальный промпт в IDE, можно увидеть на картинке к посту.

🔗 Инженерия и AI | Ilyas Salikhov

Channel name was changed to «Ilyas Salikhov»

Channel photo updated

Channel created