Телеграм канал «»

Го создавать армию агентов ИИ.. Встречаемся тут

P.s. мой проект в ближайшем будущем😱

🧠 ИИ-агент для исследования статей и патентов
LLM помогает составить поисковые запросы и сводку. Backend собирает данные, сохраняет источники и проверяет правила отбора.
🔎 Как работает бот
Через /new пользователь задаёт тему, вопрос, период публикаций и формат отчёта.
Бот предлагает план: запросы, источники и лимиты. Пользователь нажимает «Запустить».
Бот собирает записи из OpenAlex и EPO OPS, сохраняет исходные данные и SHA-256.
Удаляет дубли и оценивает релевантность по правилам.
Отправляет в Telegram .md-отчёт с документами, ссылками, доказательствами и ограничениями.
⚙️ Под капотом
FSM собирает параметры → Pydantic валидирует задачу → make_plan() строит план → run_research() выполняет поиск и анализ → render_markdown() собирает отчёт.
Блокирующий сбор выполняется через asyncio.to_thread(). Нужны контроль квот, таймауты, повторы запросов и сигнал отмены для потока.
⚠️ Каждый вывод — со ссылкой. Аннотация не заменяет полный текст, а релевантность не доказывает достоверность.

#python #ai_engineering

📚 Эпохи, батчи и темп обучения — на примере иностранных слов

Представьте набор из 12 карточек со словами. Модель учится на них, а мы выбираем, как организовать обучение.
Эпоха — один полный проход по всем 12 карточкам.
Батч — порция карточек, после которой модель обновляет веса. Если в батче 4 карточки, за эпоху получится 3 обновления.
Темп обучения — величина шага при обновлении весов. Маленький шаг может замедлить обучение, слишком большой — мешать уменьшению ошибки.
🔧 Это три разные настройки: сколько раз пройти набор, сколько примеров взять на одно обновление и насколько сильно изменить веса. Аналогия со словами помогает их запомнить; сама модель не учит язык так, как человек.

#ai_engineering #engineering_notes

⚠️ Retries для AI-агентов: как повтор создаёт дубли

Агент вызвал create_ticket. Backend создал заявку, но ответ потерялся из-за таймаута. Агент повторяет tool call — и без защиты появляется вторая заявка.
🔧 Создайте operation_id до первого вызова операции записи. При каждом повторе передавайте тот же ключ. Backend фиксирует ключ и результат так, чтобы параллельные попытки не создали дубли: если операция уже выполнена, он возвращает прежний результат.
Новый UUID на каждой попытке бесполезен — для сервиса это разные операции. А два самостоятельных запроса пользователя должны иметь разные ключи.
📊 Ограничьте число попыток и добавьте паузу между ними. Ошибки валидации и доступа повторять не нужно. В логах связывайте попытки одним operation_id.
Повтор безопасен, когда он не повторяет побочный эффект.

#production #reliability #ai_engineering

⚙️ Как учится машина? Представьте спуск с горы в тумане.

Высота — это ошибка модели. Положение на склоне — значения её весов и смещений. Всю гору сразу не видно, но можно определить уклон там, где стоишь.
🧠 Так работает градиентный спуск: модель оценивает ошибку, вычисляет градиент и меняет параметры в сторону её уменьшения. Затем повторяет шаг.
📏 Размер шага задаёт темп обучения. Слишком маленький — движение медленное. Слишком большой — можно перескочить низину и не приблизиться к минимуму.
Важная граница метафоры: локальный уклон не показывает, где находится самое глубокое место на всей поверхности. Градиентный спуск постепенно ищет параметры с меньшей ошибкой, но не обещает найти глобальный минимум.

#ai_engineering #engineering_notes

📰 Проектирование DR при длительной потере ключевого ЦОДа

Разбор на примере сбоя в Yandex Cloud 8–9 октября 2026 года, когда потеряла питание зона ru-central1-b, а затем вышли из строя модули ещё одного дата-центра в Калуге; сроки восстановления не назывались. Статья предлагает сценарии отказов, архитектуру восстановления на независимой площадке и расчёт RPO/RTO на модельном примере из 40 ВМ — практическая польза для проектирования отказоустойчивого бэкенда.

🏷 Теги: #Enterprise #Research

🔗 Открыть материал: https://habr.com/ru/companies/hstx/articles/1092602/

⚙️ Что происходит после tool call?

Агент выбрал инструмент — дальше начинается backend-запрос. MCP-клиент отправляет tools/call; сервер проверяет аргументы, вызывает API, а тот обращается к данным. Результат идёт обратно тем же маршрутом.
🧠 На возврате клиент проверяет is_error. Если tool вернул строку «ошибка 500» как обычный ответ, вызов выглядит успешным. Ошибку выполнения нужно обозначить как ошибку tool.
📊 Передавайте контекст трассы через MCP-сервер и HTTP-вызов к backend. Тогда видно, где возникла задержка: у tool, API или базы. На границе сервиса задавайте таймаут и безопасный текст ошибки.
На карточке синий путь — запрос, золотой — результат или ошибка. Код внизу показывает проверку ответа клиента.
Tool call — начало пути, а не готовый ответ пользователю.

#mcp #backend #observability