А тут точно надо 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

Как меня видит ChatGPT? 😀

С последними обновлениями ChatGPT начал потрясающе справляться с задачей генерации изображений.

От генерации людей с 8 пальцами на руке до реально крутых и ожидаемых картинок 😍
И этот прорыв всего за один год!

Если вы активно пользуетесь:
https://chatgpt.com/
или
https://gemini.google.com/

👉 то попробуйте этот промпт:

Create a caricature of me and my job based on everything you know about me

на русском:

Нарисуй меня в виде карикатуры вместе с моей работой. Используй всё, что ты обо мне уже знаешь

👉 Дополнительно потребуется загрузить ваше фото: можно сразу, либо AI вас сам спросит.


Только ChatGPT/Gemini. В других нейросетях пока не достигли такого уровня "вау", а где-то генерация изображений просто не поддерживается.


Как вам результат по мне? Похожа? 😀

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

#AI_for_analysts

🐞 Разбор вопросов с подвохами по REST API: какой HTTP-метод + URL выбрать? 🐞

От того, как вы выбираете метод + URL, зависит, будет ли ваш REST API понятным и предсказуемым для клиентов и команды.

В этом посте разберём типовые ошибки в дизайне эндпоинтов — те самые, из-за которых потом появляются “костыли”, споры в чатах и переделки.


API-метод:
👉 Получение списка вакансий
[результаты]

❌ A. POST .../api/v1.1/jobs/search

Получение, просмотр, поиск - это всё про метод GET.
Метод POST - для создания данных в БД.

Да, так делают. Но это уже просто HTTP API, без стиля REST.

❌ B. GET .../api/jobs/v1.1/list

Две ошибки в одном методе и 14% голосов 🥲

1. Версию рекомендуется делать ДО указания ресурса / объекта данных (jobs), которым управляют.

2. Никакого list не надо! По стандарту GET /jobs/{jobId} получить конкретную вакансию, а GET /jobs без id - список.

✅ C. GET .../api/v1.1/jobs
Тут всё идеально с точки зрения дизайна REST API.


❌ D. POST .../api/v1.1/jobs
Метод POST - для создания данных в БД.
Это метод "Создать вакансию".


✅ E. GET .../api/v1.1/job

Тут всё отлично, но голосов мало.
Почему не выбрали?
👉 Единственное число в эндпоинте - это ок для REST API. Писала об этом тут.

▫️ F. GET .../api/v1.1/public/jobs

Ок, но не ок.
Если public - название каталога API на сервере, то лучше его делать ДО версии, а не после.
Вариант допустим, но не лучший.

▫️ G. GET .../api/v1.1/candidate/jobs

Ок, но не ок.
Проблема как и выше, но тут считаем, что API для кандидата и название каталога API - candidate?

Сейчас метод читается как "получить вакансии кандидатов...?".

❌ H. GET https://jobmatchga.api.com/v1.1/jobs

Здесь с точки зрения порядка в базовом URL api.com оказывается основным сайтом системы, что неверно.
Поддомен для API делают иначе.

✅ I. GET https://api.jobmatchga.com/public/
v1.1/jobs

Тут всё отлично.
API находится на поддомене основного сайта jobmatchga.com.
Дизайн отличный и почему-то так мало голосов 😃
Пример в Avito



—-
Подсказки:
📚 Как выбирать методы: GET, POST, PUT, PATCH, DELETE
📚 Правила проектирования URL
—-


Запоминайте ошибки и будьте внимательны в будущем. Не попадайтесь! 🤝

#RestApiGA #JobMatchGA