28 мая 2026 года The New Stack выпустил разбор о том, почему наблюдаемость ИИ перестала быть приятным бонусом и стала обязательной инженерной дисциплиной. Если раньше баг искали по логам и стек-трейсу, то в LLM-сервисах система может не падать вообще, но при этом отвечать хуже, дольше и дороже. Для русскоязычных команд, которые уже собирают RAG, внутренних ассистентов и агентные сценарии, это прямой сигнал: без наблюдаемости ИИ прод превращается в лотерею с токенами.
Материал, как пишет The New Stack, оформлен не как манифест, а как практический туториал: автор Oladimeji Sowole на примере небольшого question-answering сервиса показывает, какие именно слои нужно инструментировать, чтобы потом не гадать, где система поехала. Публикация вышла как спонсорский пост Andela, но полезную инженерную мысль это не отменяет: AI-система здесь рассматривается не как один вызов модели, а как цепочка из retrieval, reranking, внешних tool calls, reasoning, валидации и телеметрии. И сломаться, что особенно неприятно, может каждый этап по отдельности.
Ключевой тезис статьи звучит почти как приговор привычному дебагу: три старые опоры больше не работают. Во-первых, одинаковый вход больше не гарантирует одинаковый выход. Во-вторых, ошибка не обязана падать исключением: tool мог вернуть пустой ответ, retrieval мог принести шум, а модель могла уверенно дорисовать остальное сама. В-третьих, логи больше не описывают всю историю целиком, потому что значимая часть поведения размазана между промптом, контекстом, внешними зависимостями и скрытыми переходами внутри пайплайна. Отсюда и сдвиг от log-based debugging к observability-driven engineering: мало знать, что запрос отработал, нужно видеть, почему он отработал именно так.
В качестве опорного стека автор берёт вполне приземлённый набор: FastAPI и Uvicorn для сервиса, LangChain, langchain-openai и langchain-community для orchestration-слоя, FAISS и rank-bm25 для retrieval, httpx и tenacity для внешних вызовов, OpenTelemetry для трассировки, tiktoken для оценки расхода токенов и Pydantic для схемной проверки ответа. Отдельно важна мысль про токены: в статье они считаются не как бухгалтерская истина, а как операционная оценка. Даже приблизительный подсчёт уже помогает ловить runaway-агентов, раздутый контекст и незаметный рост стоимости. Для энтерпрайз-команд это, пожалуй, самый полезный холодный душ: проблема часто не в том, что модель ошиблась, а в том, что никто не заметил, как она стала отвечать вдвое длиннее и в полтора раза дороже.
Ещё один сильный фрагмент касается retrieval и tool use. Sowole прямо пишет: если retrieval неверный, дальше всё тоже будет неверным, просто очень убедительно. Поэтому в системе нужно логировать, какие документы были подняты и что реально попало в контекст. С tool calls та же история, только неприятнее: они часто ломаются тихо. В статье для внешних запросов показан минимальный production-safeguard с allowlist доверенных доменов, retry через tenacity и запретом бездумно ходить по URL, которые подсунула модель. Причина прозаична: без такого ограничения агент легко превращается в SSRF-вектор и начинает щупать внутренние сервисы или cloud metadata endpoints. Для команд, которые уже дают агентам доступ к документации, CRM или внутренним API, это не паранойя, а нормальная гигиена.
Отдельный акцент сделан на том, что даже простой workflow лучше сначала держать детерминированным. В примере The New Stack вопрос проходит через retrieval, собирается контекст, оцениваются токены, вызывается модель, а ответ затем проверяется через Pydantic-схему. Такой путь скучнее, чем модный «агент сам решит, что делать», зато его можно разбирать по шагам. Если ломается схема вывода, это уже подсказка: либо модель проигнорировала формат, либо upstream-контекст оказался битым, либо кто-то незаметно поменял контракт. Ирония эпохи в том, что самый взрослый путь для AI-продукта сейчас нередко выглядит как сознательное ограничение свободы модели, а не как раздача ей ещё пяти инструментов и браузера.
Практическая ценность статьи в том, что она не ограничивается лозунгом «нужна телеметрия». Автор показывает конкретный operational-минимум: трейсинг через OpenTelemetry, локальный ConsoleSpanExporter для отладки и более нормальную production-схему через OTLP с отправкой данных в Jaeger, Grafana, Tempo, Datadog или Honeycomb. После такой обвязки команда может отвечать на базовые, но критичные вопросы: почему ответ оказался неверным, почему изменился результат на одинаковом запросе, почему выросла латентность, почему поползли расходы. По сути, наблюдаемость ИИ здесь выступает не отдельным рынком тулзов, а способом вернуть инженерии причинно-следственную связь, которую генеративные системы охотно размывают.
Для российского рынка здесь читается понятный тренд. Чем больше компаний внедряют внутренние ассистенты, поиск по базе знаний, AI-надстройки над саппортом и «агентов» для рутинных операций, тем быстрее выясняется, что продакшен-проблемы возникают не на демо, а после него. Пока пайплайн маленький, многое ещё можно списать на промпт. Когда в контуре появляются retrieval, внешние API, валидация, права доступа и бюджет на токены, отладка становится задачей уровня SRE и платформенной инженерии. Вопрос уже не в том, нужен ли команде ещё один LLM, а в том, сможет ли она объяснить поведение существующего. И это, похоже, главный маркер зрелости ближайших AI-сервисов: выигрывать будут не те, кто громче всех называет систему агентом, а те, кто умеет наблюдать, воспроизводить и чинить её поведение до того, как пользователь заметит деградацию.