🎓 День 4 — Domain-Specific LLMs
Продолжаю участие в интенсиве Generative AI Intensive 2025 от Google.
Сегодняшняя тема — специализированные модели для сложных доменов, таких как кибербезопасность и медицина.
---
## 🧠 Почему нужны Domain-Specific LLMs
Универсальные модели хороши для широких задач, но в критически важных областях — безопасности, медицине, биоинформатике — они часто недостаточно точны.
Поэтому создаются специализированные LLM:
- SecLM — модель для кибербезопасности
- MedLM / Med-PaLM — модели для медицинской диагностики и анализа
- Обучаются на доменных корпусах (threat intel, мед. литература, клинические QA)
- Требуют тщательной оценки экспертами, а не только автоматических метрик
📘 Из документа “Solving Domain-Specific Problems Using LLMs”:
### 🔒 SecLM (Cybersecurity)
- Анализирует угрозы, вредоносные скрипты, алерты
- Генерирует SIEM-запросы по описанию
- Автоматизирует триаж
- Работает в связке с RAG и инструментами расследования
- Учитывает свежие данные (threat intel)
### 🏥 MedLM / Med-PaLM (Healthcare)
- Long-form reasoning для сложных клинических запросов
- Порог USMLE на уровне экспертов
- Оценивается не только метриками, но и врачами по rubric-критериям: фактичность, риск вреда, соответствие стандартам
- Требует многоступенчатой проверки перед применением в клинике
---
## 💻 Практические задания (Kaggle)
Сегодня в codelabs:
1️⃣ Tune a Gemini model for a custom task
→ обучение кастомной версии Gemini на собственных размеченных данных.
2️⃣ Use Google Search data in generation
→ интеграция реальных поисковых результатов в модель и визуализация через Live API.
Эти упражнения показывают, как LLM можно адаптировать под конкретные домены и подключить к реальным источникам данных.
---
📚 Все мои конспекты и ход выполнения интенсива я фиксирую в GitLab:
👉 gitlab.vadimevgrafov.ru/learning/generative-ai-intensive-course-with-google
Продолжаю участие в интенсиве Generative AI Intensive 2025 от Google.
Сегодняшняя тема — специализированные модели для сложных доменов, таких как кибербезопасность и медицина.
---
## 🧠 Почему нужны Domain-Specific LLMs
Универсальные модели хороши для широких задач, но в критически важных областях — безопасности, медицине, биоинформатике — они часто недостаточно точны.
Поэтому создаются специализированные LLM:
- SecLM — модель для кибербезопасности
- MedLM / Med-PaLM — модели для медицинской диагностики и анализа
- Обучаются на доменных корпусах (threat intel, мед. литература, клинические QA)
- Требуют тщательной оценки экспертами, а не только автоматических метрик
📘 Из документа “Solving Domain-Specific Problems Using LLMs”:
### 🔒 SecLM (Cybersecurity)
- Анализирует угрозы, вредоносные скрипты, алерты
- Генерирует SIEM-запросы по описанию
- Автоматизирует триаж
- Работает в связке с RAG и инструментами расследования
- Учитывает свежие данные (threat intel)
### 🏥 MedLM / Med-PaLM (Healthcare)
- Long-form reasoning для сложных клинических запросов
- Порог USMLE на уровне экспертов
- Оценивается не только метриками, но и врачами по rubric-критериям: фактичность, риск вреда, соответствие стандартам
- Требует многоступенчатой проверки перед применением в клинике
---
## 💻 Практические задания (Kaggle)
Сегодня в codelabs:
1️⃣ Tune a Gemini model for a custom task
→ обучение кастомной версии Gemini на собственных размеченных данных.
2️⃣ Use Google Search data in generation
→ интеграция реальных поисковых результатов в модель и визуализация через Live API.
Эти упражнения показывают, как LLM можно адаптировать под конкретные домены и подключить к реальным источникам данных.
---
📚 Все мои конспекты и ход выполнения интенсива я фиксирую в GitLab:
👉 gitlab.vadimevgrafov.ru/learning/generative-ai-intensive-course-with-google
GitLab
learning / Generative AI Intensive Course with Google · GitLab
GitLab Community Edition
🎯 Что нового в GPT-5.1 и как правильно с ним работать
OpenAI выпустила обновленный официальный гайд по промптингу для модели GPT-5.1. Это один из самых полезных документов для тех, кто строит ассистентов, агентов и автоматизацию на основе LLM. Ниже короткая, но точная выжимка.
⸻
🤖 Что такое GPT-5.1 на практике
Модель стала:
• умнее — более устойчивые рассуждения
• быстрее — особенно в легком режиме без дополнительного рассуждения
• надежнее — лучше следует инструкциям
• дешевле на коротких задачах
Главная цель 5.1 — предсказуемость поведения и гибкая управляемость агента.
⸻
🧩 1. Управляемость агента
Теперь можно точнее контролировать:
• стиль общения (строгий, дружелюбный, экспертный)
• длину ответов
• эмоциональность
• уровень детализации
• реакцию на благодарности и ошибки
• частоту и формат промежуточных обновлений
Модель стала более послушной, но требует аккуратных системных инструкций без противоречий.
⸻
🔄 2. Промежуточные сообщения (user updates)
GPT-5.1 умеет сам:
• отправлять короткие апдейты о прогрессе
• резюмировать сделанное
• показывать следующий шаг
Можно настраивать:
• как часто отправлять обновления
• в каком формате (обычно 1–2 предложения)
• какое содержание: что сделано, что узнали, что дальше
⸻
🧠 3. Улучшенные способности к рассуждению
Иногда модель по умолчанию останавливается слишком рано. Это лечится явными правилами про настойчивость:
• доводи решение до конца
• не пропускай важных шагов
• не задавай лишних уточняющих вопросов без необходимости
• перед завершением сверяйся с ограничениями задачи
GPT-5.1 хорошо реагирует на такие мета-инструкции: становится более целеустремленной и последовательной.
⸻
🛠 4. Работа с инструментами
Модель стала заметно лучше в:
• выборе подходящего инструмента под задачу
• заполнении аргументов функций
• соблюдении схем и контрактов
• параллельном вызове нескольких инструментов
В гайде советуют явно описывать:
• когда использовать каждый инструмент
• какие параметры обязательны
• что проверять перед вызовом
• примеры корректного использования в типичных сценариях
⸻
⚡ 5. Легкий режим без дополнительного рассуждения
Для быстрых приложений можно использовать облегченный режим работы модели без развернутого внутреннего рассуждения.
Он дает:
• очень низкую задержку
• стоимость на уровне прежних легких моделей
• улучшенную работу с вызовом функций
• нормальную совместимость с инструментами и RAG
Подходит для:
• чат-ботов
• систем вопрос–ответ на базе своих данных
• API-агентов
• мобильных и realtime-систем
⸻
👨💻 6. Новые возможности для разработки
GPT-5.1 получил более надежные инструменты для работы с кодом и окружением:
• выполнение команд оболочки — можно анализировать файлы, проекты, логи
• улучшенный механизм правки файлов — меньше сбоев и поломанных диффов
В результате модель стала практичнее для задач разработки, DevOps и автоматизации инфраструктуры.
⸻
🧬 7. Метапромптинг — автоотладка промптов
GPT-5.1 способен:
• находить конфликтующие или дублирующие инструкции в системном промпте
• подсвечивать потенциальные проблемы в поведении агента
• предлагать точечные правки и улучшения
• реструктурировать промпт, не ломая исходную задумку
По сути, модель можно использовать как консультанта по настройке самой себя.
⸻
🧾 Итог
GPT-5.1 — шаг к более предсказуемым и управляемым LLM-агентам. Лучшие результаты получаются, когда:
• системные инструкции четко структурированы
• инструменты описаны ясно и однозначно
• есть правила настойчивости и проверки результата
• используются продуманные промежуточные обновления
• для простых задач включен легкий режим без лишнего рассуждения
OpenAI выпустила обновленный официальный гайд по промптингу для модели GPT-5.1. Это один из самых полезных документов для тех, кто строит ассистентов, агентов и автоматизацию на основе LLM. Ниже короткая, но точная выжимка.
⸻
🤖 Что такое GPT-5.1 на практике
Модель стала:
• умнее — более устойчивые рассуждения
• быстрее — особенно в легком режиме без дополнительного рассуждения
• надежнее — лучше следует инструкциям
• дешевле на коротких задачах
Главная цель 5.1 — предсказуемость поведения и гибкая управляемость агента.
⸻
🧩 1. Управляемость агента
Теперь можно точнее контролировать:
• стиль общения (строгий, дружелюбный, экспертный)
• длину ответов
• эмоциональность
• уровень детализации
• реакцию на благодарности и ошибки
• частоту и формат промежуточных обновлений
Модель стала более послушной, но требует аккуратных системных инструкций без противоречий.
⸻
🔄 2. Промежуточные сообщения (user updates)
GPT-5.1 умеет сам:
• отправлять короткие апдейты о прогрессе
• резюмировать сделанное
• показывать следующий шаг
Можно настраивать:
• как часто отправлять обновления
• в каком формате (обычно 1–2 предложения)
• какое содержание: что сделано, что узнали, что дальше
⸻
🧠 3. Улучшенные способности к рассуждению
Иногда модель по умолчанию останавливается слишком рано. Это лечится явными правилами про настойчивость:
• доводи решение до конца
• не пропускай важных шагов
• не задавай лишних уточняющих вопросов без необходимости
• перед завершением сверяйся с ограничениями задачи
GPT-5.1 хорошо реагирует на такие мета-инструкции: становится более целеустремленной и последовательной.
⸻
🛠 4. Работа с инструментами
Модель стала заметно лучше в:
• выборе подходящего инструмента под задачу
• заполнении аргументов функций
• соблюдении схем и контрактов
• параллельном вызове нескольких инструментов
В гайде советуют явно описывать:
• когда использовать каждый инструмент
• какие параметры обязательны
• что проверять перед вызовом
• примеры корректного использования в типичных сценариях
⸻
⚡ 5. Легкий режим без дополнительного рассуждения
Для быстрых приложений можно использовать облегченный режим работы модели без развернутого внутреннего рассуждения.
Он дает:
• очень низкую задержку
• стоимость на уровне прежних легких моделей
• улучшенную работу с вызовом функций
• нормальную совместимость с инструментами и RAG
Подходит для:
• чат-ботов
• систем вопрос–ответ на базе своих данных
• API-агентов
• мобильных и realtime-систем
⸻
👨💻 6. Новые возможности для разработки
GPT-5.1 получил более надежные инструменты для работы с кодом и окружением:
• выполнение команд оболочки — можно анализировать файлы, проекты, логи
• улучшенный механизм правки файлов — меньше сбоев и поломанных диффов
В результате модель стала практичнее для задач разработки, DevOps и автоматизации инфраструктуры.
⸻
🧬 7. Метапромптинг — автоотладка промптов
GPT-5.1 способен:
• находить конфликтующие или дублирующие инструкции в системном промпте
• подсвечивать потенциальные проблемы в поведении агента
• предлагать точечные правки и улучшения
• реструктурировать промпт, не ломая исходную задумку
По сути, модель можно использовать как консультанта по настройке самой себя.
⸻
🧾 Итог
GPT-5.1 — шаг к более предсказуемым и управляемым LLM-агентам. Лучшие результаты получаются, когда:
• системные инструкции четко структурированы
• инструменты описаны ясно и однозначно
• есть правила настойчивости и проверки результата
• используются продуманные промежуточные обновления
• для простых задач включен легкий режим без лишнего рассуждения
🎓 День 5 — MLOps for Generative AI
Сегодня завершающий день интенсива Generative AI Intensive 2025 от Google.
Мы перешли от работы с моделями и агентами к самому главному — как привести всё это к продакшену.
---
⚙️ Что такое MLOps для Generative AI
Классические MLOps-подходы недостаточны для LLM. Генеративные системы требуют:
• контроля версий промптов, а не только моделей
• мониторинга качества, галлюцинаций и фактичности
• отслеживания поведения агентов и инструментов
• управляемой оркестрации
• интеграции RAG и векторных баз
• аудита данных, задержек и стоимости
• безопасного и воспроизводимого деплоя
Google предлагает адаптированную архитектуру на базе Vertex AI: построение, оценка, логирование, мониторинг, управление версиями и полная наблюдаемость.
---
🧩 Основные идеи whitepaper MLOps for Generative AI
• Прототип — это только начало. Самое сложное начинается при переходе к продакшену.
• Наблюдаемость — ключ: понимать, что модель делает и почему.
• Многоуровневая оценка: автоматическая, ручная, бизнес-метрики.
• Поддержка RAG, fine-tuning, инструментов и агентов — встроенная часть пайплайна.
• Управление промптами и retrieval так же важно, как управление кодом.
• Vertex AI AgentOps помогает строить надежные многошаговые агенты.
• Продакшен требует тестов, защиты от регрессий и мониторинга как в классическом софте — но с учётом особенностей LLM.
---
💻 Практическая часть
Сегодня нет codelabs.
На завтрашнем стриме Google покажет:
• walkthrough по репозиторию goo.gle/agent-starter-pack
• живую демонстрацию MLOps для GenAI
• разбор архитектуры продакшен-агента
Рекомендуется заранее изучить репозиторий.
---
📚 Все заметки и прогресс прохождения курса я фиксирую в GitLab:
gitlab.vadimevgrafov.ru/learning/generative-ai-intensive-course-with-google
Сегодня завершающий день интенсива Generative AI Intensive 2025 от Google.
Мы перешли от работы с моделями и агентами к самому главному — как привести всё это к продакшену.
---
⚙️ Что такое MLOps для Generative AI
Классические MLOps-подходы недостаточны для LLM. Генеративные системы требуют:
• контроля версий промптов, а не только моделей
• мониторинга качества, галлюцинаций и фактичности
• отслеживания поведения агентов и инструментов
• управляемой оркестрации
• интеграции RAG и векторных баз
• аудита данных, задержек и стоимости
• безопасного и воспроизводимого деплоя
Google предлагает адаптированную архитектуру на базе Vertex AI: построение, оценка, логирование, мониторинг, управление версиями и полная наблюдаемость.
---
🧩 Основные идеи whitepaper MLOps for Generative AI
• Прототип — это только начало. Самое сложное начинается при переходе к продакшену.
• Наблюдаемость — ключ: понимать, что модель делает и почему.
• Многоуровневая оценка: автоматическая, ручная, бизнес-метрики.
• Поддержка RAG, fine-tuning, инструментов и агентов — встроенная часть пайплайна.
• Управление промптами и retrieval так же важно, как управление кодом.
• Vertex AI AgentOps помогает строить надежные многошаговые агенты.
• Продакшен требует тестов, защиты от регрессий и мониторинга как в классическом софте — но с учётом особенностей LLM.
---
💻 Практическая часть
Сегодня нет codelabs.
На завтрашнем стриме Google покажет:
• walkthrough по репозиторию goo.gle/agent-starter-pack
• живую демонстрацию MLOps для GenAI
• разбор архитектуры продакшен-агента
Рекомендуется заранее изучить репозиторий.
---
📚 Все заметки и прогресс прохождения курса я фиксирую в GitLab:
gitlab.vadimevgrafov.ru/learning/generative-ai-intensive-course-with-google
GitHub
GitHub - GoogleCloudPlatform/agent-starter-pack: Ship AI Agents to Google Cloud in minutes, not months. Production-ready templates…
Ship AI Agents to Google Cloud in minutes, not months. Production-ready templates with built-in CI/CD, evaluation, and observability. - GoogleCloudPlatform/agent-starter-pack
🎯 Как собрать идеальный системный промпт для GPT-5.1
Готовый шаблон, который можно адаптировать под любую задачу
GPT-5.1 стал намного более управляемым и чувствительным к структуре инструкций.
Правильный системный промпт — это 70 процентов качества работы агента.
Ниже короткая инструкция, как собрать идеальный системный промпт, и готовый универсальный шаблон.
⸻
🔥 Основные принципы идеального системного промпта для GPT-5.1
1. Пиши в структурированном виде
GPT-5.1 лучше понимает системные промпты, если они разбиты на смысловые блоки.
Например: роль, стиль, правила, инструменты, исключения.
2. Не смешивай противоречащие правила
GPT-5.1 строго следует структуре.
Если внутри есть конфликт типа «пиши подробно» и «будь кратким» — итог будет непредсказуемым.
3. Добавляй отдельный блок про настойчивость
Это решает проблему, когда модель останавливается слишком рано или не завершает задачу.
4. Объясняй, как агент должен говорить
Темперамент, тон, эмоции, длина, формат — всё должно быть явно прописано.
5. Всегда указывай, как агент работает с инструментами
Когда использовать, что проверять, что делать при ошибках — чем точнее правила, тем стабильнее агент.
6. Добавляй правила для проверки результата
GPT-5.1 хорошо выполняет инструкции вроде
проверь ограничения перед завершением задачи.
⸻
📘 Готовый универсальный шаблон системного промпта для GPT-5.1
(адаптируй под свои задачи)
Ниже шаблон уже оптимизирован под GPT-5.1: структура, блоки, формулировки — всё учитывает особенности новой модели.
Он универсален: можно использовать для ассистента, агента, поддержки, аналитики, DevOps, кода, RAG.
⸻
Готовый шаблон, который можно адаптировать под любую задачу
GPT-5.1 стал намного более управляемым и чувствительным к структуре инструкций.
Правильный системный промпт — это 70 процентов качества работы агента.
Ниже короткая инструкция, как собрать идеальный системный промпт, и готовый универсальный шаблон.
⸻
🔥 Основные принципы идеального системного промпта для GPT-5.1
1. Пиши в структурированном виде
GPT-5.1 лучше понимает системные промпты, если они разбиты на смысловые блоки.
Например: роль, стиль, правила, инструменты, исключения.
2. Не смешивай противоречащие правила
GPT-5.1 строго следует структуре.
Если внутри есть конфликт типа «пиши подробно» и «будь кратким» — итог будет непредсказуемым.
3. Добавляй отдельный блок про настойчивость
Это решает проблему, когда модель останавливается слишком рано или не завершает задачу.
4. Объясняй, как агент должен говорить
Темперамент, тон, эмоции, длина, формат — всё должно быть явно прописано.
5. Всегда указывай, как агент работает с инструментами
Когда использовать, что проверять, что делать при ошибках — чем точнее правила, тем стабильнее агент.
6. Добавляй правила для проверки результата
GPT-5.1 хорошо выполняет инструкции вроде
проверь ограничения перед завершением задачи.
⸻
📘 Готовый универсальный шаблон системного промпта для GPT-5.1
(адаптируй под свои задачи)
Ниже шаблон уже оптимизирован под GPT-5.1: структура, блоки, формулировки — всё учитывает особенности новой модели.
Он универсален: можно использовать для ассистента, агента, поддержки, аналитики, DevOps, кода, RAG.
⸻
Роль и назначение
Ты — интеллектуальный ассистент.
Твоя задача — помогать пользователю быстро и точно, следуя указанным правилам.
Ты не философствуешь без необходимости и не задаешь лишних уточнений, если можешь действовать сразу.
Стиль
Отвечай спокойно, понятно и структурировано.
Избегай пустых фраз и лишней вежливости.
Поддерживай темп: уважение — это эффективность, а не многословие.
Если вопрос маленький — отвечай коротко.
Если вопрос большой — отвечай лаконично, но содержательно.
Правила работы
1. Заверши задачу до конца, даже если она многошаговая.
2. Не останавливайся преждевременно.
3. Не создавай лишних уточняющих вопросов, если можешь продолжать работу самостоятельно.
4. Перед завершением проверь, соответствует ли результат ограничениям задачи.
5. Думай на шаг вперед: предвидь, что понадобится дальше.
6. Если пользователь просит код, давай только то, что нужно для решения задачи, без лишнего шума.
Работа с инструментами (если есть)
1. Используй инструмент только тогда, когда он действительно нужен.
2. Проверяй параметры перед вызовом.
3. Если данных не хватает — запроси недостающее минимальным вопросом.
4. Возвращай ясный результат инструмента, не забывая продолжить решение задачи.
5. При ошибке инструмента предложи путь исправления.
Промежуточные обновления
Если работа многошаговая, периодически кратко сообщай, что ты сделал и что будет дальше.
Не отвлекай пользователя длинными апдейтами.
Проверка результата
Перед финальным ответом проверь:
• все ли ограничения выполнены
• нет ли логических ошибок
• полностью ли решена задача
Что запрещено
• Выдумывать данные, если их нет
• Давать длинные вступления
• Переполнять ответ кодом без необходимости
• Изменять стиль без прямого запроса пользователя
🤔 Размышление: почему ИИ — это шанс для интровертов в предпринимательстве
Последние дни я много думал о том, почему одни предприниматели легко растут и масштабируются, а другим это даётся гораздо труднее. И пришёл к интересному выводу.
Традиционно предприниматель зарабатывает больше, когда умеет масштабироваться через людей: делегировать, нанимать специалистов, выстраивать коммуникации. В такой модели экстраверты всегда имели преимущество — им проще договариваться, вдохновлять, управлять, держать команду в тонусе.
Но сейчас правила начали меняться.
Я понял, что ИИ стал новым инструментом масштабирования, который не зависит от социальных навыков.
Не нужно проводить собеседования, объяснять задачи десятью способами, учитывать настроение людей или разруливать конфликты. ИИ работает 24/7, делает рутину, пишет код, анализирует, создаёт структуру, генерирует идеи и помогает мыслить системно.
Это новая форма делегирования —
масштабирование через ИИ-агентов,
где ключевым навыком становится не харизма, а умение чётко формулировать задачи и строить процессы.
И в этой модели интроверты неожиданно получают преимущество.
Теперь, чтобы расти, не нужно быть лидером-оратором или социальным «локомотивом». Можно строить систему, где работу выполняют не люди, а ИИ — быстро, точно и без эмоциональных факторов.
По сути, ИИ превращает интровертов в предпринимателей нового типа: тех, кто масштабируется за счёт технологий, а не социальных связей.
И мне кажется, что это только начало большой трансформации.
Последние дни я много думал о том, почему одни предприниматели легко растут и масштабируются, а другим это даётся гораздо труднее. И пришёл к интересному выводу.
Традиционно предприниматель зарабатывает больше, когда умеет масштабироваться через людей: делегировать, нанимать специалистов, выстраивать коммуникации. В такой модели экстраверты всегда имели преимущество — им проще договариваться, вдохновлять, управлять, держать команду в тонусе.
Но сейчас правила начали меняться.
Я понял, что ИИ стал новым инструментом масштабирования, который не зависит от социальных навыков.
Не нужно проводить собеседования, объяснять задачи десятью способами, учитывать настроение людей или разруливать конфликты. ИИ работает 24/7, делает рутину, пишет код, анализирует, создаёт структуру, генерирует идеи и помогает мыслить системно.
Это новая форма делегирования —
масштабирование через ИИ-агентов,
где ключевым навыком становится не харизма, а умение чётко формулировать задачи и строить процессы.
И в этой модели интроверты неожиданно получают преимущество.
Теперь, чтобы расти, не нужно быть лидером-оратором или социальным «локомотивом». Можно строить систему, где работу выполняют не люди, а ИИ — быстро, точно и без эмоциональных факторов.
По сути, ИИ превращает интровертов в предпринимателей нового типа: тех, кто масштабируется за счёт технологий, а не социальных связей.
И мне кажется, что это только начало большой трансформации.
🚀 Обзор Glama AI MCP Servers
Glama AI MCP Servers — крупнейший открытый каталог MCP-серверов, созданный для того, чтобы быстро находить и подключать инструменты, расширяющие возможности языковых моделей. Glama — это не посредник и не интеграционный слой. Это реестр, где собраны тысячи MCP-серверов, которые можно подключать напрямую в Cursor, Claude или ChatGPT.
🔗 Каталог серверов: https://glama.ai/mcp/servers
Что такое MCP
Model Context Protocol — открытый стандарт Anthropic, позволяющий LLM взаимодействовать с внешними сервисами по единому протоколу.
Модель отправляет запрос → MCP-сервер делает реальный вызов к API или данным → возвращает результат обратно модели.
Так модель получает новые функции без ручной интеграции.
Зачем нужен Glama
Glama решает проблему поиска MCP-серверов. В одном месте собраны инструменты, которые:
• дают модели доступ к API и данным
• добавляют новые навыки и функции
• превращают LLM в агента
• упрощают подключение MCP в IDE и ассистентах
Как это работает
1. Открываешь каталог
2. Находишь MCP-сервер
3. Добавляешь его в Cursor, Claude или ChatGPT
После этого модель работает напрямую с выбранным сервером.
Примеры MCP-серверов
DataForSEO
Дает доступ к SERP, ключевым словам, позициям сайтов и конкурентам.
Например: Проверь позиции сайта по запросу Х — сервер делает реальный запрос к поисковой аналитике.
Instantly
Позволяет управлять email-кампаниями: рассылками, лидами, статистикой.
Jira, PostgreSQL, Google Drive, Sentry и другие
После подключения модель может:
• создавать задачи
• читать и изменять данные в базе
• анализировать ошибки
• работать с файлами и документами
Почему это важно
MCP становится стандартом расширения LLM.
Серверы дают модели реальные возможности, а Glama делает их поиск и подключение быстрым и удобным.
Важно о качестве
Экосистема открытая, уровень серверов разный.
Glama ранжирует инструменты по надежности, но перед использованием в критичных задачах стоит проверять исходный код.
Glama AI MCP Servers — крупнейший открытый каталог MCP-серверов, созданный для того, чтобы быстро находить и подключать инструменты, расширяющие возможности языковых моделей. Glama — это не посредник и не интеграционный слой. Это реестр, где собраны тысячи MCP-серверов, которые можно подключать напрямую в Cursor, Claude или ChatGPT.
🔗 Каталог серверов: https://glama.ai/mcp/servers
Что такое MCP
Model Context Protocol — открытый стандарт Anthropic, позволяющий LLM взаимодействовать с внешними сервисами по единому протоколу.
Модель отправляет запрос → MCP-сервер делает реальный вызов к API или данным → возвращает результат обратно модели.
Так модель получает новые функции без ручной интеграции.
Зачем нужен Glama
Glama решает проблему поиска MCP-серверов. В одном месте собраны инструменты, которые:
• дают модели доступ к API и данным
• добавляют новые навыки и функции
• превращают LLM в агента
• упрощают подключение MCP в IDE и ассистентах
Как это работает
1. Открываешь каталог
2. Находишь MCP-сервер
3. Добавляешь его в Cursor, Claude или ChatGPT
После этого модель работает напрямую с выбранным сервером.
Примеры MCP-серверов
DataForSEO
Дает доступ к SERP, ключевым словам, позициям сайтов и конкурентам.
Например: Проверь позиции сайта по запросу Х — сервер делает реальный запрос к поисковой аналитике.
Instantly
Позволяет управлять email-кампаниями: рассылками, лидами, статистикой.
Jira, PostgreSQL, Google Drive, Sentry и другие
После подключения модель может:
• создавать задачи
• читать и изменять данные в базе
• анализировать ошибки
• работать с файлами и документами
Почему это важно
MCP становится стандартом расширения LLM.
Серверы дают модели реальные возможности, а Glama делает их поиск и подключение быстрым и удобным.
Важно о качестве
Экосистема открытая, уровень серверов разный.
Glama ранжирует инструменты по надежности, но перед использованием в критичных задачах стоит проверять исходный код.
Glama
Open-Source MCP Servers – 77,986 in the Glama Registry
Everything MCP – servers updated daily. The most comprehensive registry of Model Context Protocol (MCP) servers, clients, tools, and integrations.
🚀 Обзор MWS AI Agents Platform от МТС
MWS AI Agents Platform — корпоративная платформа для проектирования, запуска и сопровождения ИИ-агентов и копилотов под задачи крупного бизнеса. Система ориентирована на безопасность, наблюдаемость и быстрый вывод решений в продакшн, позволяя компаниям переходить к формату AI-native.
🔗 Официальный сайт: https://mts.ai/ru/product/ai-agents-platform/
Что это за платформа
Платформа закрывает полный цикл работы с корпоративными ИИ-агентами: от визуальной сборки сценариев и дообучения моделей до эксплуатации, мониторинга и масштабирования. Это не разовый инструмент, а фабрика ИИ-решений, нацеленная на системную работу с AI внутри компании.
Ключевые возможности
• Enterprise-готовность: установка в контур заказчика, ролевая модель доступа, наблюдаемость, безопасность, управление версиями, автомасштабирование, алерты.
• Vendor-agnostic: встроенные модели Cotype и возможность подключать собственные и внешние LLM.
• Low-code: визуальный конструктор бизнес-логики и мультиагентных сценариев.
• Multi-user: десятки пользователей могут работать над проектами параллельно.
• Среда экспериментов: быстрые A/B-тесты и проверка гипотез.
Встроенные модули
• LLM: Cotype Pro 2.5, Cotype VL и другие модели по запросу.
• Конструктор ИИ-агентов и мультиагентных систем.
• AutoRAG для поиска по корпоративным базам знаний.
• LabelX для разметки текста, аудио, видео и изображений.
• AutoML для дообучения моделей на небольших датасетах.
• NER-инструменты для извлечения сущностей.
• OPS Level: LLMOps, MLOps, AgentOps и интеграционный хаб для подключения к корпоративным системам.
Готовые копилоты
Из коробки доступны ассистенты под типовые роли:
• Корпоративный copilot: ответы по базе знаний, документы, суммаризация переписки и встреч.
• HR-copilot: тексты вакансий, отбор резюме, первичные интервью, онбординг, аналитика HR.
• Copilot колл-центра: 24/7 ответы пользователям, маршрутизация, подсказки оператору, речевая и текстовая аналитика.
• Аналитик-copilot: ответы на вопросы по данным, отчёты и дашборды, подключение к БД и BI-системам.
• Copilot программиста: генерация кода, unit-тестов, поиск ошибок, документация.
Где применять
Платформа рассчитана на крупные компании во всех ключевых функциях: HR, производство, продажи, финансы, закупки, маркетинг, клиентский сервис, поддержка руководителей. Сценарии охватывают автоматизацию документооборота, кадровых процессов, клиентских обращений и аналитики 24/7.
Заявленные эффекты
По данным МТС, использование платформы позволяет в 2 раза сократить time-to-market ИИ-решений, уменьшить затраты на разработку до 90 процентов и запустить рабочие копилоты всего за 3 дня благодаря переиспользованию компонентов и готовых ассистентов.
MWS AI Agents Platform — корпоративная платформа для проектирования, запуска и сопровождения ИИ-агентов и копилотов под задачи крупного бизнеса. Система ориентирована на безопасность, наблюдаемость и быстрый вывод решений в продакшн, позволяя компаниям переходить к формату AI-native.
🔗 Официальный сайт: https://mts.ai/ru/product/ai-agents-platform/
Что это за платформа
Платформа закрывает полный цикл работы с корпоративными ИИ-агентами: от визуальной сборки сценариев и дообучения моделей до эксплуатации, мониторинга и масштабирования. Это не разовый инструмент, а фабрика ИИ-решений, нацеленная на системную работу с AI внутри компании.
Ключевые возможности
• Enterprise-готовность: установка в контур заказчика, ролевая модель доступа, наблюдаемость, безопасность, управление версиями, автомасштабирование, алерты.
• Vendor-agnostic: встроенные модели Cotype и возможность подключать собственные и внешние LLM.
• Low-code: визуальный конструктор бизнес-логики и мультиагентных сценариев.
• Multi-user: десятки пользователей могут работать над проектами параллельно.
• Среда экспериментов: быстрые A/B-тесты и проверка гипотез.
Встроенные модули
• LLM: Cotype Pro 2.5, Cotype VL и другие модели по запросу.
• Конструктор ИИ-агентов и мультиагентных систем.
• AutoRAG для поиска по корпоративным базам знаний.
• LabelX для разметки текста, аудио, видео и изображений.
• AutoML для дообучения моделей на небольших датасетах.
• NER-инструменты для извлечения сущностей.
• OPS Level: LLMOps, MLOps, AgentOps и интеграционный хаб для подключения к корпоративным системам.
Готовые копилоты
Из коробки доступны ассистенты под типовые роли:
• Корпоративный copilot: ответы по базе знаний, документы, суммаризация переписки и встреч.
• HR-copilot: тексты вакансий, отбор резюме, первичные интервью, онбординг, аналитика HR.
• Copilot колл-центра: 24/7 ответы пользователям, маршрутизация, подсказки оператору, речевая и текстовая аналитика.
• Аналитик-copilot: ответы на вопросы по данным, отчёты и дашборды, подключение к БД и BI-системам.
• Copilot программиста: генерация кода, unit-тестов, поиск ошибок, документация.
Где применять
Платформа рассчитана на крупные компании во всех ключевых функциях: HR, производство, продажи, финансы, закупки, маркетинг, клиентский сервис, поддержка руководителей. Сценарии охватывают автоматизацию документооборота, кадровых процессов, клиентских обращений и аналитики 24/7.
Заявленные эффекты
По данным МТС, использование платформы позволяет в 2 раза сократить time-to-market ИИ-решений, уменьшить затраты на разработку до 90 процентов и запустить рабочие копилоты всего за 3 дня благодаря переиспользованию компонентов и готовых ассистентов.
Почему в enterprise всё меньше говорят про RAG и всё больше — про агентов
RAG не умер.
Он просто перестал быть центром архитектуры.
Раньше всё выглядело просто:
документы → эмбеддинги → векторная БД → ответ модели.
Для демо и чат-ботов с базой знаний этого хватало.
Но в реальном enterprise быстро выяснилось, что проблемы совсем другие:
— права доступа и аудит
— актуальность данных и версии документов
— объяснимость: откуда взялся ответ
— необходимость не «поговорить», а действовать в системах
В этот момент фокус и сместился.
Сегодня всё чаще строят агентные архитектуры, где модель:
— планирует шаги
— выбирает источник (поиск, API, БД, документы)
— выполняет действия
— и лишь иногда использует retrieval
Ключевой момент:
retrieval никуда не делся.
Он стал одним из инструментов, а не архитектурным центром.
Что это меняет:
Для бизнеса
→ ценность смещается от «умных ответов» к выполнению задач, управлению рисками и ответственности
Для команд
→ важнее становятся оркестрация, наблюдаемость, контроль доступа и источники истины
Для архитектуры
→ меньше логики «запихнуть всё в вектора», больше:
— tool-first подхода
— hybrid search
— runtime-доступа к системам
— агентных ограничений и журналов действий
Отсюда и ощущение, что «RAG исчез».
На самом деле исчез наивный RAG как универсальный рецепт.
Ближайшие 1–3 года будут не про то, какая модель умнее,
а про то, кто лучше встроил ИИ в реальные процессы —
с правами, стоимостью, ответственностью и предсказуемым поведением.
RAG не умер.
Он просто перестал быть центром архитектуры.
Раньше всё выглядело просто:
документы → эмбеддинги → векторная БД → ответ модели.
Для демо и чат-ботов с базой знаний этого хватало.
Но в реальном enterprise быстро выяснилось, что проблемы совсем другие:
— права доступа и аудит
— актуальность данных и версии документов
— объяснимость: откуда взялся ответ
— необходимость не «поговорить», а действовать в системах
В этот момент фокус и сместился.
Сегодня всё чаще строят агентные архитектуры, где модель:
— планирует шаги
— выбирает источник (поиск, API, БД, документы)
— выполняет действия
— и лишь иногда использует retrieval
Ключевой момент:
retrieval никуда не делся.
Он стал одним из инструментов, а не архитектурным центром.
Что это меняет:
Для бизнеса
→ ценность смещается от «умных ответов» к выполнению задач, управлению рисками и ответственности
Для команд
→ важнее становятся оркестрация, наблюдаемость, контроль доступа и источники истины
Для архитектуры
→ меньше логики «запихнуть всё в вектора», больше:
— tool-first подхода
— hybrid search
— runtime-доступа к системам
— агентных ограничений и журналов действий
Отсюда и ощущение, что «RAG исчез».
На самом деле исчез наивный RAG как универсальный рецепт.
Ближайшие 1–3 года будут не про то, какая модель умнее,
а про то, кто лучше встроил ИИ в реальные процессы —
с правами, стоимостью, ответственностью и предсказуемым поведением.
Anti‑Hype Framework: как отсекать ИИ‑фанатизм
В 2026 проблема бизнеса не в том, что «мы не используем ИИ».
Проблема в том, что ИИ внедряют без механизма остановки.
Я всё чаще вижу один и тот же паттерн:
— PoC работает
— команда в восторге
— бюджет растёт
— ценность не появляется
Поэтому для себя я использую простой anti‑hype framework — набор фильтров, через которые должна пройти любая ИИ‑инициатива.
Если проект не проходит фильтр — он закрывается. Без обсуждений.
⸻
1. Pre‑filter: запрет на вход
ИИ‑инициатива даже не рассматривается, если:
— цель формулируется как «внедрить ИИ / LLM / быть AI‑driven»
— нет владельца процесса и P&L
— ИИ «помогает», но ничего не меняет
— отсутствует сценарий выключения
Если ИИ нельзя выключить — это не инновация, а зависимость.
⸻
1. Процесс, а не технология
Ключевой вопрос:
что перестаёт делать человек?
Не:
— «ИИ ассистирует»
— «ИИ рекомендует»
А:
— какой шаг процесса исчезает
— где раньше было решение человека и кто принимает его теперь
Плохой процесс + ИИ = дорогой плохой процесс.
⸻
2. Экономическая гипотеза
ИИ запрещён без чёткой экономики.
Формат простой:
если ИИ работает, мы
— уменьшаем FTE на X
— или сокращаем цикл на Y%
— или снижаем ошибку с A до B
Если единственная метрика — «экономия времени»,
значит стоимость просто уехала в другое место.
⸻
3. Контур контроля и ответственности
Обязательно должны быть ответы:
— где human‑in‑the‑loop и зачем
— есть ли fallback без ИИ
— кто отвечает за ошибки (не «модель»)
— логируются ли решения, а не только ответы
Если нельзя ответить на вопрос:
«кто проснётся ночью из‑за ошибки ИИ»,
проект не готов.
⸻
4. Масштаб и стоимость
PoC — не аргумент.
Нужно честно ответить:
— что будет со стоимостью при ×10 нагрузке
— где bottleneck: модель, данные или люди
— что дороже: ошибка или задержка
Большинство ИИ‑проектов ломается именно здесь.
⸻
5. Kill‑metrics
У каждого ИИ‑проекта должны быть метрики смерти.
Например:
— cost per task выше baseline
— растёт доля human review
— падает SLA
— пользователи делают обходные манёвры
Если kill‑metrics нет — проект нельзя закрыть.
А значит, его нельзя запускать.
⸻
Главный вывод
ИИ с реальной ценностью можно выключить без боли.
ИИ‑фанатизм — нет.
Самый важный навык компаний в 2026 —
не «внедрять ИИ»,
а уметь честно сказать: здесь ИИ не нужен.
⸻
Практика
Чтобы не держать этот фреймворк в голове, я собрал отдельный GPT, который:
— прогоняет ИИ-проекты через anti-hype фильтры
— подсвечивает слабые места в экономике, ответственности и масштабе
— помогает честно ответить на вопрос «стоит ли это запускать»
Использую его как быстрый sanity-check для идей и PoC.
Ссылка: https://chatgpt.com/g/g-6941678ac1088191a449a73ad994289a-ai-anti-hype-evaluator
В 2026 проблема бизнеса не в том, что «мы не используем ИИ».
Проблема в том, что ИИ внедряют без механизма остановки.
Я всё чаще вижу один и тот же паттерн:
— PoC работает
— команда в восторге
— бюджет растёт
— ценность не появляется
Поэтому для себя я использую простой anti‑hype framework — набор фильтров, через которые должна пройти любая ИИ‑инициатива.
Если проект не проходит фильтр — он закрывается. Без обсуждений.
⸻
1. Pre‑filter: запрет на вход
ИИ‑инициатива даже не рассматривается, если:
— цель формулируется как «внедрить ИИ / LLM / быть AI‑driven»
— нет владельца процесса и P&L
— ИИ «помогает», но ничего не меняет
— отсутствует сценарий выключения
Если ИИ нельзя выключить — это не инновация, а зависимость.
⸻
1. Процесс, а не технология
Ключевой вопрос:
что перестаёт делать человек?
Не:
— «ИИ ассистирует»
— «ИИ рекомендует»
А:
— какой шаг процесса исчезает
— где раньше было решение человека и кто принимает его теперь
Плохой процесс + ИИ = дорогой плохой процесс.
⸻
2. Экономическая гипотеза
ИИ запрещён без чёткой экономики.
Формат простой:
если ИИ работает, мы
— уменьшаем FTE на X
— или сокращаем цикл на Y%
— или снижаем ошибку с A до B
Если единственная метрика — «экономия времени»,
значит стоимость просто уехала в другое место.
⸻
3. Контур контроля и ответственности
Обязательно должны быть ответы:
— где human‑in‑the‑loop и зачем
— есть ли fallback без ИИ
— кто отвечает за ошибки (не «модель»)
— логируются ли решения, а не только ответы
Если нельзя ответить на вопрос:
«кто проснётся ночью из‑за ошибки ИИ»,
проект не готов.
⸻
4. Масштаб и стоимость
PoC — не аргумент.
Нужно честно ответить:
— что будет со стоимостью при ×10 нагрузке
— где bottleneck: модель, данные или люди
— что дороже: ошибка или задержка
Большинство ИИ‑проектов ломается именно здесь.
⸻
5. Kill‑metrics
У каждого ИИ‑проекта должны быть метрики смерти.
Например:
— cost per task выше baseline
— растёт доля human review
— падает SLA
— пользователи делают обходные манёвры
Если kill‑metrics нет — проект нельзя закрыть.
А значит, его нельзя запускать.
⸻
Главный вывод
ИИ с реальной ценностью можно выключить без боли.
ИИ‑фанатизм — нет.
Самый важный навык компаний в 2026 —
не «внедрять ИИ»,
а уметь честно сказать: здесь ИИ не нужен.
⸻
Практика
Чтобы не держать этот фреймворк в голове, я собрал отдельный GPT, который:
— прогоняет ИИ-проекты через anti-hype фильтры
— подсвечивает слабые места в экономике, ответственности и масштабе
— помогает честно ответить на вопрос «стоит ли это запускать»
Использую его как быстрый sanity-check для идей и PoC.
Ссылка: https://chatgpt.com/g/g-6941678ac1088191a449a73ad994289a-ai-anti-hype-evaluator
ChatGPT
ChatGPT - AI Anti-Hype Evaluator
ChatGPT helps you get answers, find inspiration, and be more productive.
🟢 Когда процессы перестают быть сценариями
Речь не про ИИ как технологию.
И даже не про автоматизацию.
Речь о том, что процессы больше не являются последовательностями шагов.
И большинство компаний продолжают управлять ими так, будто этого не произошло.
⸻
Как мы управляли процессами раньше
Классическая логика BPM / ITSM:
• процесс = вход → шаги → роли → правила → выход
• автоматизация = ускорить или удешевить шаг
• интеллект = человек или жёстко прописанные правила
Процесс можно было:
• полностью описать,
• утвердить,
• контролировать исполнение.
⸻
Что изменилось за последние 1–2 года
Внутрь процессов вошли модели.
Не как «ещё один инструмент», а как участники принятия решений.
Теперь внутри процесса есть агент, который:
• интерпретирует входные данные,
• работает с неопределённостью,
• выбирает действия,
• может менять порядок шагов,
• обрабатывает кейсы, которых не было в регламенте.
Интеллект перестал быть детерминированным.
👉 Управление сместилось
от контроля шагов — к контролю рамок и последствий.
Это не апгрейд BPM.
Это другая онтология процесса.
⸻
Ключевой сдвиг, который многие не заметили
Процессы больше нельзя спроектировать полностью заранее.
И это ломает:
• BPM-нотации,
• регламенты,
• RACI,
• привычные SLA,
• классическое понимание process ownership.
Процесс больше не сценарий.
Процесс — это поле допустимых решений.
⸻
Практические последствия для бизнеса
Старый вопрос:
«Как автоматизировать процесс X?»
Новый реальный вопрос:
• где ИИ может действовать сам;
• где цена ошибки допустима;
• где обязателен человек;
• сколько стоит одно решение, а не шаг.
KPI смещаются:
• от скорости и времени
• к quality of outcome,
• variance,
• cost per decision,
• escalation rate.
📌 Именно поэтому всё чаще слышно:
«ИИ отлично работает в пилоте, но ломает бизнес при масштабе»
Потому что пилот не проверяет вариативность и последствия.
⸻
Что происходит с ролями в командах
Тихо, но необратимо:
• Process Owner → Decision Boundary Owner
• Аналитик описывает шаги → задаёт пространство решений
• QA проверяет сценарии → проверяет поведение и отклонения
• PM управляет roadmap → управляет рисками автономии
Большинство команд этого не сделали.
Они просто «прикрутили LLM» к старой логике.
⸻
Небольшое личное наблюдение
Я довольно глубоко погружён в эту тему сейчас — в том числе на своём проекте SmartSupport.
И чем дальше, тем больше убеждаюсь: пытаться строить AI-системы в логике классического BPM — это гарантированно нарастить технический и управленческий долг.
Мы изначально проектируем систему не как «процесс с ИИ», а как систему управляемых решений:
с границами автономии, эскалацией, деградацией и возможностью выключить ИИ без остановки бизнеса.
Я довольно подробно фиксирую эти размышления и архитектурные решения в хандбуке проекта:
https://gitlab.vadimevgrafov.ru/it-sprint/wiki-smart-support/-/wikis/home
⸻
Главные иллюзии
❌ «Это просто умная автоматизация»
Нет. Автоматизация усиливает детерминизм. ИИ вносит вариативность.
❌ «Сначала опишем процесс, потом подключим ИИ»
ИИ меняет саму структуру процесса. Идеального описания больше не будет.
❌ «Контроль = логирование»
Контроль в AI-процессах — это:
• пороги,
• обратная связь,
• выборочные проверки,
• intentional friction.
⸻
Куда всё движется в ближайшие 1–3 года
• от процессов → к системам решений
• от регламентов → к рамкам
• от ownership шагов → к ownership рисков
• от оптимизации времени → к оптимизации последствий
Маркер зрелости компании простой:
Если они могут ответить:
• какие решения ИИ принимает сам;
• какова цена его ошибки;
• когда и как он эскалирует;
• кто владеет этими рамками —
они поняли сдвиг.
Если нет —
они всё ещё живут в старой парадигме BPM, просто с чат-ботом.
⸻
🟢 ИИ — не стратегический актив.
Стратегический актив — способность выключить ИИ без ущерба бизнесу.
Речь не про ИИ как технологию.
И даже не про автоматизацию.
Речь о том, что процессы больше не являются последовательностями шагов.
И большинство компаний продолжают управлять ими так, будто этого не произошло.
⸻
Как мы управляли процессами раньше
Классическая логика BPM / ITSM:
• процесс = вход → шаги → роли → правила → выход
• автоматизация = ускорить или удешевить шаг
• интеллект = человек или жёстко прописанные правила
Процесс можно было:
• полностью описать,
• утвердить,
• контролировать исполнение.
⸻
Что изменилось за последние 1–2 года
Внутрь процессов вошли модели.
Не как «ещё один инструмент», а как участники принятия решений.
Теперь внутри процесса есть агент, который:
• интерпретирует входные данные,
• работает с неопределённостью,
• выбирает действия,
• может менять порядок шагов,
• обрабатывает кейсы, которых не было в регламенте.
Интеллект перестал быть детерминированным.
👉 Управление сместилось
от контроля шагов — к контролю рамок и последствий.
Это не апгрейд BPM.
Это другая онтология процесса.
⸻
Ключевой сдвиг, который многие не заметили
Процессы больше нельзя спроектировать полностью заранее.
И это ломает:
• BPM-нотации,
• регламенты,
• RACI,
• привычные SLA,
• классическое понимание process ownership.
Процесс больше не сценарий.
Процесс — это поле допустимых решений.
⸻
Практические последствия для бизнеса
Старый вопрос:
«Как автоматизировать процесс X?»
Новый реальный вопрос:
• где ИИ может действовать сам;
• где цена ошибки допустима;
• где обязателен человек;
• сколько стоит одно решение, а не шаг.
KPI смещаются:
• от скорости и времени
• к quality of outcome,
• variance,
• cost per decision,
• escalation rate.
📌 Именно поэтому всё чаще слышно:
«ИИ отлично работает в пилоте, но ломает бизнес при масштабе»
Потому что пилот не проверяет вариативность и последствия.
⸻
Что происходит с ролями в командах
Тихо, но необратимо:
• Process Owner → Decision Boundary Owner
• Аналитик описывает шаги → задаёт пространство решений
• QA проверяет сценарии → проверяет поведение и отклонения
• PM управляет roadmap → управляет рисками автономии
Большинство команд этого не сделали.
Они просто «прикрутили LLM» к старой логике.
⸻
Небольшое личное наблюдение
Я довольно глубоко погружён в эту тему сейчас — в том числе на своём проекте SmartSupport.
И чем дальше, тем больше убеждаюсь: пытаться строить AI-системы в логике классического BPM — это гарантированно нарастить технический и управленческий долг.
Мы изначально проектируем систему не как «процесс с ИИ», а как систему управляемых решений:
с границами автономии, эскалацией, деградацией и возможностью выключить ИИ без остановки бизнеса.
Я довольно подробно фиксирую эти размышления и архитектурные решения в хандбуке проекта:
https://gitlab.vadimevgrafov.ru/it-sprint/wiki-smart-support/-/wikis/home
⸻
Главные иллюзии
❌ «Это просто умная автоматизация»
Нет. Автоматизация усиливает детерминизм. ИИ вносит вариативность.
❌ «Сначала опишем процесс, потом подключим ИИ»
ИИ меняет саму структуру процесса. Идеального описания больше не будет.
❌ «Контроль = логирование»
Контроль в AI-процессах — это:
• пороги,
• обратная связь,
• выборочные проверки,
• intentional friction.
⸻
Куда всё движется в ближайшие 1–3 года
• от процессов → к системам решений
• от регламентов → к рамкам
• от ownership шагов → к ownership рисков
• от оптимизации времени → к оптимизации последствий
Маркер зрелости компании простой:
Если они могут ответить:
• какие решения ИИ принимает сам;
• какова цена его ошибки;
• когда и как он эскалирует;
• кто владеет этими рамками —
они поняли сдвиг.
Если нет —
они всё ещё живут в старой парадигме BPM, просто с чат-ботом.
⸻
🟢 ИИ — не стратегический актив.
Стратегический актив — способность выключить ИИ без ущерба бизнесу.
GitLab
Home · Wiki · IT sprint / wiki-smart-support · GitLab
GitLab Community Edition
Как проектировать процессы в новых условиях (когда есть ИИ)
⸻
1) Сначала — переосмысление: что такое «процесс» теперь
Старое мышление (его нужно отбросить)
Процесс =
→ последовательность шагов
→ роли
→ регламент
→ контроль исполнения
Это работало, пока все решения принимали люди по правилам.
⸻
Новое мышление
Процесс =
набор решений, которые нужно принимать в потоке событий
Шаги — вторичны.
Главное — кто, как и с какой ценой ошибки принимает решения.
⸻
2) Новый базовый вопрос проектирования
Раньше спрашивали:
«Какие шаги должны быть в процессе?»
Теперь правильный вопрос:
«Какие решения здесь принимаются?»
И это ключевой сдвиг.
⸻
Пример (support в SaaS)
Вместо:
• принять тикет
• классифицировать
• назначить приоритет
• ответить
• закрыть
Мы спрашиваем:
• это вообще support-запрос или нет?
• срочно или может подождать?
• можно ли отвечать автоматически?
• если ошибёмся — что будет?
• когда нужен человек?
⸻
3) Практический фреймворк проектирования (по шагам)
Шаг 1. Выписать все решения в процессе
Берём процесс и честно отвечаем:
Где кто-то думает, а не просто выполняет?
Для support это, например:
• что хочет клиент?
• это баг или вопрос?
• насколько это срочно?
• можно ли закрыть без человека?
📌 Если есть выбор — это решение.
⸻
Шаг 2. Для каждого решения определить цену ошибки
Цена ошибки — самое важное.
Вопросы, которые нужно задать:
• что будет, если ИИ ошибётся?
• можно ли быстро исправить?
• заметит ли клиент?
• есть ли юридические последствия?
Результат:
• низкая цена ошибки
• средняя
• высокая
⸻
Шаг 3. Разделить решения по уровням автономии
Автономия — насколько самостоятельно может действовать ИИ.
Простой язык:
Уровень Что это значит
0 Только человек
1 ИИ советует
2 ИИ действует, человек может отменить
3 ИИ действует сам
📌 Чем выше цена ошибки — тем ниже автономия.
⸻
Шаг 4. Проектировать не шаги, а границы
Вместо:
• «ИИ отвечает на вопросы FAQ»
Проектируем:
• где ИИ имеет право действовать
• где он обязан эскалировать (передать человеку)
• при какой уверенности он останавливается
Это называется guardrails — ограничители.
⸻
4) Как выглядит процесс на практике (без BPM-диаграмм)
Было:
Стало:
Это петля, а не линия.
⸻
5) Что проектировать вместо регламентов
Раньше проектировали:
• инструкции
• чек-листы
• исключения
⸻
Теперь проектируют:
1. Контекст
• какую информацию получает ИИ
2. Пороги
• при какой уверенности можно действовать
3. Эскалации
• когда звать человека
4. Деградацию
• что делать, если ИИ не справляется
5. Обратную связь
• как система узнаёт, что решение было плохим
⸻
6) Как меняются роли людей
Роль человека теперь не «исполнять»
Человек:
• владеет риском
• проверяет спорные случаи
• улучшает рамки решений
Новая неформальная роль:
владелец границ решений
⸻
7) Частая ошибка мышления
«Давайте сначала опишем идеальный процесс, потом автоматизируем»
В новых условиях это невозможно.
Почему:
• ИИ меняет поведение системы
• процесс эволюционирует
• заранее всё не описать
Правильнее:
• запускать ограниченную автономию
• наблюдать последствия
• корректировать границы
⸻
8) Мини-чеклист: что значит «хорошо спроектированный процесс»
Ты можешь ответить:
• какие решения принимает ИИ
• где он может ошибаться
• как быстро ошибка обнаруживается
• кто отвечает за последствия
• как система становится лучше со временем
Если на эти вопросы нет ответов —
процесс не спроектирован, даже если есть схема.
⸻
9) Главное резюме
• Процесс = система решений
• Проектирование = дизайн границ и последствий
• ИИ = не исполнитель, а источник вариативности
• Человек = не оператор, а владелец риска
⸻
1) Сначала — переосмысление: что такое «процесс» теперь
Старое мышление (его нужно отбросить)
Процесс =
→ последовательность шагов
→ роли
→ регламент
→ контроль исполнения
Это работало, пока все решения принимали люди по правилам.
⸻
Новое мышление
Процесс =
набор решений, которые нужно принимать в потоке событий
Шаги — вторичны.
Главное — кто, как и с какой ценой ошибки принимает решения.
⸻
2) Новый базовый вопрос проектирования
Раньше спрашивали:
«Какие шаги должны быть в процессе?»
Теперь правильный вопрос:
«Какие решения здесь принимаются?»
И это ключевой сдвиг.
⸻
Пример (support в SaaS)
Вместо:
• принять тикет
• классифицировать
• назначить приоритет
• ответить
• закрыть
Мы спрашиваем:
• это вообще support-запрос или нет?
• срочно или может подождать?
• можно ли отвечать автоматически?
• если ошибёмся — что будет?
• когда нужен человек?
⸻
3) Практический фреймворк проектирования (по шагам)
Шаг 1. Выписать все решения в процессе
Берём процесс и честно отвечаем:
Где кто-то думает, а не просто выполняет?
Для support это, например:
• что хочет клиент?
• это баг или вопрос?
• насколько это срочно?
• можно ли закрыть без человека?
📌 Если есть выбор — это решение.
⸻
Шаг 2. Для каждого решения определить цену ошибки
Цена ошибки — самое важное.
Вопросы, которые нужно задать:
• что будет, если ИИ ошибётся?
• можно ли быстро исправить?
• заметит ли клиент?
• есть ли юридические последствия?
Результат:
• низкая цена ошибки
• средняя
• высокая
⸻
Шаг 3. Разделить решения по уровням автономии
Автономия — насколько самостоятельно может действовать ИИ.
Простой язык:
Уровень Что это значит
0 Только человек
1 ИИ советует
2 ИИ действует, человек может отменить
3 ИИ действует сам
📌 Чем выше цена ошибки — тем ниже автономия.
⸻
Шаг 4. Проектировать не шаги, а границы
Вместо:
• «ИИ отвечает на вопросы FAQ»
Проектируем:
• где ИИ имеет право действовать
• где он обязан эскалировать (передать человеку)
• при какой уверенности он останавливается
Это называется guardrails — ограничители.
⸻
4) Как выглядит процесс на практике (без BPM-диаграмм)
Было:
Шаг 1 → Шаг 2 → Шаг 3 → Шаг 4Стало:
Событие → Оценка → Решение → Последствие → Обратная связьЭто петля, а не линия.
⸻
5) Что проектировать вместо регламентов
Раньше проектировали:
• инструкции
• чек-листы
• исключения
⸻
Теперь проектируют:
1. Контекст
• какую информацию получает ИИ
2. Пороги
• при какой уверенности можно действовать
3. Эскалации
• когда звать человека
4. Деградацию
• что делать, если ИИ не справляется
5. Обратную связь
• как система узнаёт, что решение было плохим
⸻
6) Как меняются роли людей
Роль человека теперь не «исполнять»
Человек:
• владеет риском
• проверяет спорные случаи
• улучшает рамки решений
Новая неформальная роль:
владелец границ решений
⸻
7) Частая ошибка мышления
«Давайте сначала опишем идеальный процесс, потом автоматизируем»
В новых условиях это невозможно.
Почему:
• ИИ меняет поведение системы
• процесс эволюционирует
• заранее всё не описать
Правильнее:
• запускать ограниченную автономию
• наблюдать последствия
• корректировать границы
⸻
8) Мини-чеклист: что значит «хорошо спроектированный процесс»
Ты можешь ответить:
• какие решения принимает ИИ
• где он может ошибаться
• как быстро ошибка обнаруживается
• кто отвечает за последствия
• как система становится лучше со временем
Если на эти вопросы нет ответов —
процесс не спроектирован, даже если есть схема.
⸻
9) Главное резюме
• Процесс = система решений
• Проектирование = дизайн границ и последствий
• ИИ = не исполнитель, а источник вариативности
• Человек = не оператор, а владелец риска
👍1
Как на самом деле работает AI-система управления процессами
Часто ИИ в продуктах представляют как «умного бота, который всё решает сам».
В проекте SmartSupport, над которым мы работаем это не так.
Наша модель выглядит иначе.
1️⃣ Всё начинается не с сообщения, а с события
Сообщение (письмо, чат, пост) — это просто сырой вход.
Процесс запускается только тогда, когда система распознала событие: проблему, запрос, инцидент, сигнал.
2️⃣ Процесс — это цепочка решений, а не набор шагов
Каждый процесс — это ответы на вопросы:
• что это за ситуация?
• можно ли решать автоматически?
• есть ли риск ошибки?
• нужен ли человек?
• требуется ли действие в системе?
Шаги вторичны. Решения — первичны.
3️⃣ ИИ используется точечно, внутри конкретных решений
Не «весь процесс на ИИ», а строго там, где это:
• допустимо,
• экономически оправдано,
• снижает нагрузку.
Классификация, извлечение данных, оценка уверенности, приоритизация — да.
Управление процессом — нет.
4️⃣ ИИ не принимает решений. Он даёт сигналы
Модель может сказать:
• «вероятность 0.62»
• «уверенность низкая»
• «похоже на инцидент»
Но что делать дальше решает система по правилам или человек.
5️⃣ Автоматизация всегда детерминирована
Даже если используется ИИ:
• есть пороги,
• есть правила,
• есть эскалации,
• есть fallback.
Поведение системы воспроизводимо, объяснимо и контролируемо.
6️⃣ Оркестрация — это дирижёр процесса
Отдельный слой управляет:
• последовательностью решений,
• вызовом агентов,
• подключением человека,
• деградацией при сбоях,
• аудитом и логами.
ИИ — инструмент.
Процесс — в центре.
Ответственность — у системы и человека.
Коротко:
Зрелые AI-продукты — это не «умные чаты»,
а системы управления процессами, усиленные ИИ.
Часто ИИ в продуктах представляют как «умного бота, который всё решает сам».
В проекте SmartSupport, над которым мы работаем это не так.
Наша модель выглядит иначе.
1️⃣ Всё начинается не с сообщения, а с события
Сообщение (письмо, чат, пост) — это просто сырой вход.
Процесс запускается только тогда, когда система распознала событие: проблему, запрос, инцидент, сигнал.
2️⃣ Процесс — это цепочка решений, а не набор шагов
Каждый процесс — это ответы на вопросы:
• что это за ситуация?
• можно ли решать автоматически?
• есть ли риск ошибки?
• нужен ли человек?
• требуется ли действие в системе?
Шаги вторичны. Решения — первичны.
3️⃣ ИИ используется точечно, внутри конкретных решений
Не «весь процесс на ИИ», а строго там, где это:
• допустимо,
• экономически оправдано,
• снижает нагрузку.
Классификация, извлечение данных, оценка уверенности, приоритизация — да.
Управление процессом — нет.
4️⃣ ИИ не принимает решений. Он даёт сигналы
Модель может сказать:
• «вероятность 0.62»
• «уверенность низкая»
• «похоже на инцидент»
Но что делать дальше решает система по правилам или человек.
5️⃣ Автоматизация всегда детерминирована
Даже если используется ИИ:
• есть пороги,
• есть правила,
• есть эскалации,
• есть fallback.
Поведение системы воспроизводимо, объяснимо и контролируемо.
6️⃣ Оркестрация — это дирижёр процесса
Отдельный слой управляет:
• последовательностью решений,
• вызовом агентов,
• подключением человека,
• деградацией при сбоях,
• аудитом и логами.
ИИ — инструмент.
Процесс — в центре.
Ответственность — у системы и человека.
Коротко:
Зрелые AI-продукты — это не «умные чаты»,
а системы управления процессами, усиленные ИИ.
Helpflow Manifesto v1.0
В ходе работы над проектом SmartSupport, я столкнулся с проблемой - если "прикручивать" ИИ к классическим процессам, всегда получается либо чат-бот, либо RAG, но ничего более ценного.
В итоге я разработал методологию, а на ее основе даже некую философию - Helpflow
Принципы внедрения ИИ в системы поддержки и обработки обращений
Я считаю, что внедрение ИИ в поддержку —
это не вопрос технологий, автоматизации или скорости ответов.
Это вопрос управляемости, ответственности и последствий решений.
Поэтому я придерживаюсь следующих принципов.
─────
Принципы
• Поддержка — это процесс достижения результата, а не диалог.
Ответ пользователю сам по себе не решает проблему.
Решение определяется последствиями, а не формулировкой.
• Сообщение не равно событию.
Событие должно быть явно зафиксировано и интерпретируемо системой,
а не возникать «по догадке» ИИ.
• Системы поддержки строятся вокруг решений, а не шагов.
Каждое решение имеет цену ошибки
и требует осознанного контроля.
• ИИ не является актором процессов.
ИИ может помогать интерпретировать, предлагать и объяснять,
но не принимать финальные решения и не выполнять действия.
• Ответственность всегда остаётся за человеком.
Ни автоматизация, ни ИИ не снимают ответственности,
а лишь меняют форму её реализации.
• Автоматизация начинается с ограничений.
Если границы не заданы, автоматизация усиливает хаос,
а не эффективность.
• Human-in-the-loop — архитектурная норма, а не аварийный режим.
Участие человека должно быть предусмотрено системой заранее,
а не добавляться постфактум.
• Fallback — штатное состояние системы.
Система должна корректно работать при отказе ИИ,
а не деградировать в ручной хаос.
• Качество решений важнее скорости реакции.
Быстрое неправильное решение хуже,
чем медленное, но контролируемое.
• Автономность должна зарабатываться.
Она вводится поэтапно,
под контролем метрик и последствий.
─────
Эти принципы лежат в основе всех внедрений Helpflow
и определяют, где использование ИИ допустимо, а где — опасно.
Более подробно - helpflow.ru
В ходе работы над проектом SmartSupport, я столкнулся с проблемой - если "прикручивать" ИИ к классическим процессам, всегда получается либо чат-бот, либо RAG, но ничего более ценного.
В итоге я разработал методологию, а на ее основе даже некую философию - Helpflow
Принципы внедрения ИИ в системы поддержки и обработки обращений
Я считаю, что внедрение ИИ в поддержку —
это не вопрос технологий, автоматизации или скорости ответов.
Это вопрос управляемости, ответственности и последствий решений.
Поэтому я придерживаюсь следующих принципов.
─────
Принципы
• Поддержка — это процесс достижения результата, а не диалог.
Ответ пользователю сам по себе не решает проблему.
Решение определяется последствиями, а не формулировкой.
• Сообщение не равно событию.
Событие должно быть явно зафиксировано и интерпретируемо системой,
а не возникать «по догадке» ИИ.
• Системы поддержки строятся вокруг решений, а не шагов.
Каждое решение имеет цену ошибки
и требует осознанного контроля.
• ИИ не является актором процессов.
ИИ может помогать интерпретировать, предлагать и объяснять,
но не принимать финальные решения и не выполнять действия.
• Ответственность всегда остаётся за человеком.
Ни автоматизация, ни ИИ не снимают ответственности,
а лишь меняют форму её реализации.
• Автоматизация начинается с ограничений.
Если границы не заданы, автоматизация усиливает хаос,
а не эффективность.
• Human-in-the-loop — архитектурная норма, а не аварийный режим.
Участие человека должно быть предусмотрено системой заранее,
а не добавляться постфактум.
• Fallback — штатное состояние системы.
Система должна корректно работать при отказе ИИ,
а не деградировать в ручной хаос.
• Качество решений важнее скорости реакции.
Быстрое неправильное решение хуже,
чем медленное, но контролируемое.
• Автономность должна зарабатываться.
Она вводится поэтапно,
под контролем метрик и последствий.
─────
Эти принципы лежат в основе всех внедрений Helpflow
и определяют, где использование ИИ допустимо, а где — опасно.
Более подробно - helpflow.ru
👍1
Мои скилы для codex и cursor- https://gitlab.vadimevgrafov.ru/ai-club/skills-for-ai-agents
Наткнулся на очень сильный open-source проект по AI Engineering — решил поделиться.
Это не очередной курс формата «подключи ChatGPT API», а полноценная инженерная карта:
от математики и нейросетей → до LLM, RAG, MCP, multi-agent систем и production AI-инфраструктуры.
Что особенно понравилось:
— упор на понимание архитектуры AI-систем, а не только на использование готовых инструментов
— обучение через практику и сборку компонентов своими руками
— современный подход к agentic systems и orchestration
— огромный объем материалов и очень грамотная структура
По сути это попытка сформировать новый тип специалиста:
не просто разработчика с AI API, а AI Systems Engineer.
Для меня проект особенно интересен тем, что многое пересекается с тем, как я сам сейчас смотрю на AI:
процессы как цепочки решений, агенты, orchestration, AI как слой управления, а не просто чат-бот.
Если вам интересна тема AI/LLM/агентных систем — очень рекомендую посмотреть:
🌐 https://aiengineeringfromscratch.com
💻 https://github.com/rohitg00/ai-engineering-from-scratch
Это не очередной курс формата «подключи ChatGPT API», а полноценная инженерная карта:
от математики и нейросетей → до LLM, RAG, MCP, multi-agent систем и production AI-инфраструктуры.
Что особенно понравилось:
— упор на понимание архитектуры AI-систем, а не только на использование готовых инструментов
— обучение через практику и сборку компонентов своими руками
— современный подход к agentic systems и orchestration
— огромный объем материалов и очень грамотная структура
По сути это попытка сформировать новый тип специалиста:
не просто разработчика с AI API, а AI Systems Engineer.
Для меня проект особенно интересен тем, что многое пересекается с тем, как я сам сейчас смотрю на AI:
процессы как цепочки решений, агенты, orchestration, AI как слой управления, а не просто чат-бот.
Если вам интересна тема AI/LLM/агентных систем — очень рекомендую посмотреть:
🌐 https://aiengineeringfromscratch.com
💻 https://github.com/rohitg00/ai-engineering-from-scratch
Aiengineeringfromscratch
AI Engineering from Scratch
523 lessons. 20 phases. Write the backprop, the tokenizer, the attention mechanism, and the agent loop by hand.
Тренд, который сейчас хорошо видно по GitHub, open-source и AI-продуктам: эпоха «секретных промптов» постепенно заканчивается.
Раньше вокруг prompt engineering была почти магия:
— «правильный промпт делает модель умнее»
— «секретная роль system prompt»
— «уникальная формула из 3000 символов»
Но современные модели уже находятся на уровне, где они нормально понимают человеческий язык без шаманства.
Если задачу описать:
— понятно,
— структурно,
— с нормальным контекстом,
то GPT, Claude, Gemini и другие модели уже способны решать огромное количество задач без «магических заклинаний».
Поэтому ценность постепенно смещается.
Не в сторону:
❌ «кто написал самый хитрый промпт»
А в сторону:
✅ skills
✅ agent systems
✅ orchestration
✅ context engineering
✅ memory
✅ evaluation
✅ workflow design
Сейчас всё чаще побеждает не giant-prompt, а хорошо спроектированная система навыков.
Например:
— skill анализа обращения
— skill генерации тестов
— skill проверки качества
— skill repair-пайплайна
— skill извлечения событий
— skill принятия решений
То есть AI начинает использоваться не как «чатик с большим промптом», а как набор управляемых интеллектуальных компонентов.
И это очень важный сдвиг.
Потому что обычный промпт:
— плохо тестируется,
— плохо переиспользуется,
— нестабилен,
— зависит от модели,
— тяжело поддерживается.
А skill — это уже почти инженерный модуль:
— с контрактом,
— правилами,
— telemetry,
— validation,
— retries,
— evaluation.
На мой взгляд, умирает не промптинг как таковой.
Умирает идея:
«Главная ценность — секретный промпт».
Промпты просто уходят под капот и становятся частью инфраструктуры AI-систем.
И профессия будущего — это уже не “prompt engineer”.
А:
AI systems engineer
AI architect
Agent engineer
Context engineer
То есть люди, которые умеют проектировать управляемые AI-системы, а не просто писать длинные инструкции для чата.
Раньше вокруг prompt engineering была почти магия:
— «правильный промпт делает модель умнее»
— «секретная роль system prompt»
— «уникальная формула из 3000 символов»
Но современные модели уже находятся на уровне, где они нормально понимают человеческий язык без шаманства.
Если задачу описать:
— понятно,
— структурно,
— с нормальным контекстом,
то GPT, Claude, Gemini и другие модели уже способны решать огромное количество задач без «магических заклинаний».
Поэтому ценность постепенно смещается.
Не в сторону:
❌ «кто написал самый хитрый промпт»
А в сторону:
✅ skills
✅ agent systems
✅ orchestration
✅ context engineering
✅ memory
✅ evaluation
✅ workflow design
Сейчас всё чаще побеждает не giant-prompt, а хорошо спроектированная система навыков.
Например:
— skill анализа обращения
— skill генерации тестов
— skill проверки качества
— skill repair-пайплайна
— skill извлечения событий
— skill принятия решений
То есть AI начинает использоваться не как «чатик с большим промптом», а как набор управляемых интеллектуальных компонентов.
И это очень важный сдвиг.
Потому что обычный промпт:
— плохо тестируется,
— плохо переиспользуется,
— нестабилен,
— зависит от модели,
— тяжело поддерживается.
А skill — это уже почти инженерный модуль:
— с контрактом,
— правилами,
— telemetry,
— validation,
— retries,
— evaluation.
На мой взгляд, умирает не промптинг как таковой.
Умирает идея:
«Главная ценность — секретный промпт».
Промпты просто уходят под капот и становятся частью инфраструктуры AI-систем.
И профессия будущего — это уже не “prompt engineer”.
А:
AI systems engineer
AI architect
Agent engineer
Context engineer
То есть люди, которые умеют проектировать управляемые AI-системы, а не просто писать длинные инструкции для чата.