Синдром "не знаю, что искать"
Знаете это чувство, когда тикет приходит, а у инженера поддержки глаза по пять копеек? Он открывает Jira, Confluence, кидает запрос в RAG-систему, получает кучу документов — и все равно не знает, с чего начать. Классический RAG (Retrieval-Augmented Generation) выдает релевантные чанки, но не соединяет их в связную историю. Он как библиотекарь, который вываливает на стол три тома энциклопедии и говорит: "Разбирайся сам".
Проблема не в том, что знания нет. Проблема — в отсутствии навигации. Пользователь не формулирует запрос как инженер. Он пишет: "У меня не грузится страница", а RAG ищет "страница не грузится" — и находит инструкции по настройке CDN, кэшированию и, боже упаси, замене роутера. Результат — время на разрешение тикета растет, CSI падает, команда выгорает. Выход — перейти от тупого поиска к агентному анализу. К ИИ-агенту, который сам понимает контекст, строит цепочку рассуждений и принимает решения.
Ключевая мысль: агент — это не улучшенный поиск. Агент — это следователь, который собирает улики, строит версии и находит преступника, даже если пользователь сказал просто "что-то упало".
Анатомия перехода: от RAG-пайплайна к Agentic RAG
Давайте честно: что мы обычно имеем в продакшене? Chain: User -> Query -> Embedding -> Vector DB -> Top-K -> LLM -> Answer. Всё. Агентная архитектура добавляет слой Reasoning & Action. Агент не просто отдает запрос, а:
- Анализирует запрос — выделяет сущности (сервис, ошибка, время, затронутые пользователи).
- Планирует шаги — "сначала проверю логи, потом гляну changelog, потом дерну API мониторинга".
- Исполняет инструменты — вызывает API, SQL-запросы, читает тикеты, парсит Confluence.
- Синтезирует ответ — собирает факты в единую картину и предлагает действия.
Вот тут и пригодится концепция Agentic RAG, которую мы разбирали в статье Agentic RAG против Classic RAG: переход от пайплайна к контрольному циклу. Вместо линейного пайплайна — управляющий цикл с обратной связью. Агент может переформулировать запрос, если первый поиск не дал результатов, или уточнить у пользователя.
Архитектура ИИ-агента поддержки: взломанный чертеж
Разберем на примере реального кейса — внедрения ИИ-агента в МТС. Они прошли путь от пилотного RAG-бота до полноценного агента, который автономно анализирует тикеты L1-L2. Архитектура — четыре слоя:
1 Слой инструментов (Tools)
Агент умеет работать с API техподдержки. В МТС это: поиск по базе знаний, запросы к Jira (getTicket, updateTicket), чтение Confluence, вызов скриптов диагностики, дергание Prometheus/Grafana. Каждый инструмент — это функция с описанием на естественном языке. LLM решает, какой инструмент применить.
from typing import Any
@tool
def search_knowledge_base(query: str, filters: dict = None) -> list[dict]:
"""Ищет статьи в Confluence по query, фильтрует по меткам."""
return confluence.search(query, max_results=5, filters=filters)
@tool
def get_ticket_context(ticket_id: str) -> dict[str, Any]:
"""Возвращает полный контекст тикета: описание, комментарии, вложения, историю статусов."""
return jira_client.get_ticket(ticket_id)2 Слой принятия решений (Agent Core)
Тут живет LLM (в 2026 году это, скорее всего, Llama 3.3 70B или Gemini 2.0 Ultra, если у вас есть GPU, либо YandexGPT 4 для российского контура). Агент использует ReAct-промптинг: он пишет "Thought:", "Action:", "Observation:" и повторяет цикл, пока не найдет ответ или не исчерпает лимит шагов.
SYSTEM_PROMPT = """Ты — агент техподдержки МТС. У тебя есть инструменты:
- search_knowledge_base(query: str)
- get_ticket_context(ticket_id: str)
- run_diagnostic_script(script_name: str)
Твоя задача — анализировать тикеты, собирать факты и предлагать решение или эскалацию.
Всегда думай по шагам: Thought, Action, Observation."""3 Слой памяти (Memory)
Агент помнит контекст диалога — историю предыдущих вызовов, результаты поиска, уже принятые решения. В МТС использовали буфер на 10 последних сообщений + краткосрочную память через векторное резюме. Это не давало агенту "забывать" середину сложного расследования.
4 Слой оркестрации и мониторинга
Без него никуда. Каждый шаг логируется, счетчики идут в Prometheus, алерты — в Telegram. Если агент зациклился (одно и то же Action > 3 раз) — срабатывает circuit breaker, и тикет уходит человеку. Подробнее про такие грабли — в статье Архитектура автономных ИИ-агентов без роутинга.
Кейс МТС: от 45% к 78% разрешения без участия человека
Старт был скромным: классический RAG на базе знаний Confluence отвечал на 45% вопросов первой линии. Часто — невпопад. После перехода на Agentic RAG показатель вырос до 78%. Но главное — агент начал выявлять первопричины, которые не были явно описаны в документации.
Пример: массовый инцидент "не отправляются СМС". Агент проанализировал 12 тикетов, вытащил из логов ошибку "timeout from SMSC", сходил в changelog — оказалось, ночью обновили версию библиотеки. Решение: откат + уведомление команде. Без агента это выяснили бы к обеду, а он — за 5 минут.
⚠️ Важный нюанс: агент не умеет делать неизвестные действия. Для новых типов проблем нужны новые инструменты или обучение на новых данных. Иначе он просто скажет "я не знаю" — и правильно.
Как НЕ надо делать: типичные ошибки
Давайте пройдемся по граблям, на которые наступила не только МТС, но и многие другие команды. Если не хотите повторять — записывайте.
Ошибка 1. Скармливать агенту все подряд
Векторные базы — не свалка. Не пихайте туда 50 тысяч страниц Confluence с устаревшими инструкциями. Агент будет теряться и выдавать чушь. Нужна чистка, дедупликация и мета-тегирование. Тут поможет eval-пайплайн, описанный в статье Как построить eval пайплайн для RAG-агента: кейс Битрикс24. Вы должны знать, какую точность вы получаете на каждом шаге.
Ошибка 2. Агент без лимитов
Если не ограничить количество шагов и токенов, агент может уйти в бесконечный цикл или нагенерать простыню на 10к токенов. В МТС поставили лимит — 10 действий на тикет. Если за 10 шагов не нашел ответ — эскалация. И правильно.
Ошибка 3. Забыть про контекст диалога
Часто бывает: пользователь сначала пишет "у меня лагает интерфейс", а потом "и еще счет не пришел". Агент должен понимать, что это два разных запроса, или один — с общим корнем. Механизм memory window спасает, но не всегда. Лучше использовать агента с состоянием, как в корпоративном ИИ-агенте Яндекса — там deep research собирает контекст не только из диалога, но из внешних источников в реальном времени.
Пошаговый план: сборка агента за уикенд
Хватит теории. Давайте соберем минимального агента, который умеет анализировать тикеты и искать ответы в базе знаний. Стек: Python, LangGraph (или CrewAI, кому как удобнее), Qdrant для векторов, OpenAI-совместимый API. Предположим, что база знаний уже есть.
1 Подготовка окружения и инструментов
pip install langgraph langchain langchain-openai qdrant-clientfrom langchain_openai import ChatOpenAI
from langchain.tools import tool
from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated, Sequence
llm = ChatOpenAI(model="gpt-4o", temperature=0)
# тут наши инструменты2 Определяем граф состояний
class AgentState(TypedDict):
ticket_id: str
ticket_text: str
steps: int
memory: Annotated[list, "conversation_history"]
final_answer: str
def analyze_ticket(state: AgentState) -> AgentState:
# Анализируем тикет, выделяем ключевые сущности
prompt = f"Извлеки из тикета {state['ticket_text']} проблему, сервис, ожидаемое поведение"
analysis = llm.invoke(prompt)
state["memory"].append(analysis.content)
state["steps"] += 1
return state
def search_and_synthesize(state: AgentState) -> AgentState:
# Ищем по базе знаний, формируем ответ
query = state["memory"][-1] # последний анализ
docs = vector_store.similarity_search(query, k=3)
synthesis_prompt = f"На основе найденных документов: {docs}\nОтветь на вопрос из тикета."
answer = llm.invoke(synthesis_prompt)
state["final_answer"] = answer.content
return state
def decide_next(state: AgentState) -> str:
if state["final_answer"] or state["steps"] >= 10:
return "end"
else:
return "continue"
# Строим граф
builder = StateGraph(AgentState)
builder.add_node("analyze", analyze_ticket)
builder.add_node("search", search_and_synthesize)
builder.set_entry_point("analyze")
builder.add_edge("analyze", "search")
builder.add_conditional_edges("search", decide_next, {"continue": "analyze", "end": END})
graph = builder.compile()3 Интеграция с тикетной системой
def process_ticket(ticket_id: str):
ticket = jira.get_ticket(ticket_id)
initial_state = {
"ticket_id": ticket_id,
"ticket_text": ticket.description,
"steps": 0,
"memory": [],
"final_answer": ""
}
result = graph.invoke(initial_state)
# Пишем ответ в тикет
jira.add_comment(ticket_id, result["final_answer"])
return result["final_answer"]Метрики, которые реально важны
Не надейтесь на F1-score по ответам. В техподдержке главное — снижение времени разрешения (MTTR) и процент эскалированных тикетов. В МТС после внедрения агента MTTR упал на 40% для L1, а эскалаций стало меньше на 30%. Также замеряли CSI при взаимодействии с агентом — он не должен быть ниже, чем с живым оператором. Если агент грубит или не помогает — меняйте промпты или решайте, стоит ли его запускать на этом тикете.
Отдельная история — KPI самого агента. В статье ИИ-агенты душат KPI разбирается, как агенты могут "накручивать" свои метрики. Например, отвечать быстро, но поверхностно, чтобы MTTR был низким. Следите, чтобы качество не страдало в погоне за цифрами. Добавьте мониторинг повторных обращений по той же теме — если агент не решил проблему с первого раза, это плохо.
Нужна ли Confluence? Агент может жить без базы знаний
Звучит странно, но бывает. Если у вас нет структурированной базы, но есть поток тикетов и их решения — можно обучить агента искать по истории решенных заявок. Это делается через векторную БД, куда кладутся пары (проблема -> решение). Так сделали в одном стартапе — агент работал без Confluence, только по архивным тикетам. Но тут важна аккуратность: устаревшие решения могут навредить. Об этом — в материале Агентный RAG поверх SQL-таблиц.
Честный взгляд: когда агент — зло
Давайте без розовых очков. Автономный анализ тикетов не работает в условиях высокой неопределенности и уникальных инцидентов. Если у вас стартап, где каждый второй тикет — это новая дичь, не стройте агента. Сначала причешите процессы. И второй момент: агент — это дополнительные затраты. Каждый вызов LLM стоит денег. В МТС при 10k тикетов в день расходы на модель окупились экономией времени операторов, но если у вас 10 тикетов — проще обучить человека.
И еще: не пытайтесь заменить агентами L3. L3 — это архитекторы решений, они смотрят на систему целиком. Агент хорош только для рутинных L1-L2, где есть четкие алгоритмы. Для старта можно внедрить гибрид: агент готовит саммари и черновик ответа, а человек утверждает. Это описано в гайде Как внедрить нейросети в IT-компанию.
Неочевидный совет: начинайте с одного тикет-категории
Если вы решите строить агента, не пытайтесь объять необъятное. Выберите одну категорию, где больше всего дублирующихся тикетов (например, "проблемы с авторизацией"), и настройте агента под нее. Соберите датасет, протестируйте, улучшите. А потом — раскатывайте на другие категории. Такой подход окупается быстрее и не убивает репутацию плохими ответами. Заодно оцените, сколько времени это сэкономит — и тогда смело тащите в продакшен.
Если хотите посмотреть, как похожий агент решает проблемы в Kubernetes — загляните в разбор Реализация AI-агента для траблшутинга в Kubernetes: кейс IVI. Там и архитектура, и промпты, и грабли.
