А тут точно надо AI? Показательная история из университета 🤓

Мне кажется, моя учёба по AI в Johns Hopkins University продолжается бесконечно 😅

И она делает меня счастливее, потому что ощущение “как много я не знала” - лучшее!
Но и без "поумничать" у меня судя по всему никуда.


На последнем занятии мы разбирали готовое решение AI чат-бота для интернет-магазина на Python.
Учебное демо - ок… но я-то думаю про реальность.

И поэтому снова начала перестраивать архитектуру решения и рассуждать с преподавателем по поводу изменения кода на 80% 😃

Почему?
👉 Потому что многие путают внедрение AI и обычную автоматизацию, и пытаются засунуть LLM туда, где достаточно нормально запрограммировать.



📌 Рассказываю к чему докопалась:
1. Есть AI чат-бот для Интернет-магазина.
2. Пользователь пишет:
«Где мой заказ? И когда его доставят?»
3. LLM (большая языковая модель = AI) понимает: вопрос индивидуальный → просит номер заказа.
4. Пользователь присылает номер.


И дальше варианты 👇

1️⃣ Заранее, до начала диалога, загрузить в LLM всю базу заказов (через файл) и искать там

Это было в учебном примере.
Ок, так можно.
Но зачем в LLM вообще вгрузили базу заказов?
Всех-всех пользователей. Там и персональные данные, и чеки, и всё в этом файле.
Ещё и через большой JSON-файл, который явно при каждом новом диалоге (или хотя бы раз в час), надо обновлять.
Зачем вообще заставлять LLM парсить этот JSON?

При таком раскладе ещё и сложные промпты надо писать, чтобы LLM ни в коем случае не выдала данные по чужому заказу и не раскрыла чужие перс данные.

Если уж что-то и подгружать, то только заказы авторизованного пользователя в начале диалога.
Но нет, в учебном примере грузили вообще всё 🥲

2️⃣ Пусть LLM через MCP полезет в базу и достанет данные

Уже лучше.
Есть недавно созданный MCP-протокол, используя который можно подключиться к вашей БД PostgreSQL и забирать из неё нужные данные напрямую.
Это уже лучше, чем работа с JSON-файлом со всеми заказами.
Одна проблема появляется.
Надо защищаться, чтобы у нас не украли БД, обманув LLM через вредоносный промпт (команду к AI).
Про MCP делала небольшое демо тут.

3️⃣ Мы принимаем номер заказа от пользователя и далее вызываем обычный метод системы, который возвращает статус и дату доставки

Как по мне - это лучший вариант.
Простая и привычная автоматизация, которая решает все проблемы защиты перс данных и потенциальных атак, которые могут сделать для LLM.
Тут:
+ и запросы к AI экономим (да-да, запросы по API платные, если не своя LLM, а, например, DeepSeek или OpenAI)
+ и кучу промптов на защиту от кражи перс данных придумывать не надо
+ LLM - про понимание пользователя, вызов метода из кода - про понятное получение данных из БД


Итого 👇
В задаче на AI-чат-бота для интернет-магазина LLM нужна не как “доступ к базе”, а как умный диспетчер:
• распознать команду от пользователя “получить статус доставки” или иную
• запросить у пользователя номер заказа
• аккуратно вызвать нужный метод
• красиво сформулировать ответ пользователю
Остальное - отдайте программистам на автоматизацию.

А “парсить огромный JSON” и писать кучу защитных промптов - это норм как учебный пример, но не как продакшн.


Такая вот история 😃
Надеюсь удалось донести вам чуть больше "подводных камней" про системы с AI.


А вообще я уже много месяцев с урывками выходных и в абсолютном завале со своей учёбой.
Но узнавать и пробовать новое,особенно в AI - 🤍🤍🤍


#AI_for_analysts

📗 3 вида параметров в HTTP (REST API), где чаще всего путаются аналитики 📗

Мини-гайд про виды параметров HTTP (REST API) запросов, в которых чаще всего косячат новички:


👉 query-parameters — после ? в URL.
фильтры, сортировки, пагинация, поисковые строки, api-key (если так принято).

Формат:

GET /products?name=milk&limit=10&offset=20&order=price,asc

Получить список продуктов с названием "milk", 10 записей, начиная с 20-ой, сортировать по возрастанию цены

Типичные проблемы:
• Отправляют бизнес-данные для создания/изменения в query, вместо тела json.
• Дробят сортировку в несколько параметров, вместо одного аккуратного.
• Добавляют query в POST/PUT без причины.



👉 path-parameters — часть пути (эндпоинта).
Идентификатор конкретного ресурса или вложенного ресурса.

Формат:

GET /products/{productId} → GET /products/3a46b…

Можно внутри пути:

PATCH /products/{productId}/archive

Типичные проблемы:
• Отправляют ?productId=… в query, хотя это сущность, а не фильтр.



👉 body-parameters — тело запроса json.
Сообщение, когда создаём/меняем данные.
Только для POST | PUT | PATCH.
Кроме json могут быть другие форматы.

Формат:

{
"name": "Яблоки Гала",
"shortName": "Гала",
"description": "Сладкие и хрустящие"
}

Типичные проблемы:
• Отправляют огромное количество параметров в query-параметры, которые там не помещаются, и могут быть обрезаны сервером при определенных настройках безопасности.
• Используют body (json) для GET или DELETE, где оно не поддержано.


В гайде:
✔️ название параметра и его определение
✔️ скрины из Postman
✔️ особенности
✔️ примеры


Изучайте, запоминайте и не путайтесь 🤝

#RestApiGA

🚀 Всё про кэш 🚀

Кэш — двигатель производительности системы.

Именно он спасает нас от медленных ответов и заставляет экраны приложений грузиться быстрее.

Кэш есть в процессорах, браузерах, БД, микросервисах.

Но просто положить данные в кэш недостаточно.
Важно понимать:
+ когда кэшировать,
+ что кэшировать,
+ как обновлять кэш.

С мини-книгой к посту вы сможете быстро разобраться в особенностях работы с кэшем.

🔹 Введение
🔹 Зачем кэшировать
🔹 Стратегии кэширования
🔹 Инвалидация кэша
🔹 Стратегии вытеснения кэша
🔹 Время жизни кэша (TTL)
🔹 Согласованность со временем
🔹 Холодный и горячий кэш
🔹 Standalone кэш

Мало работали с кэшем?
Загружайте мини-книгу и изучайте ключевые термины 📚

#АрхитектураGA #RestApiGA