не совсем, это Anthropic ), первая версия ui была слишком "плоской", работала, но не юзерфрендли, а что нужно юзеру кроме стабильности, чтобы было красиво, затягивало, функционально, поэтому дизайн взят с другого проекта по алертингу (о нем чуть позже будет статейка), а он в свою очередь был взят с Grafana Oncall
я с гпу года 3 - 4 назад в кубах работал, в openshift если быть точнее, было так себе да, заводилось тогда все через манипуляции, не знаю сейчас может проще стало
это хороший вопрос, честно я даже о нем не думал, видимо это еще впереди, и с учетом того что тул в н8н может поправить любой из команды, выглядит как большая дырка пока что
Перед запуском тест забирает из production MCP актуальный список инструментов, их схемы и контракты. Затем реальной модели задаётся сохранённый вопрос (из истории, отобранный вручную). Когда модель вызывает tool, запрос перехватывается. Вместо обращения в прод источники тест возвращает готовый ответ (в виде raw метрик и логов), ранее полученный в реальной проблеме (для нас это ок, поскольку тулы в mcp узкопрофилированые, при правильных входных данных отдадут правильную выборку). При этом проверяются имя инструмента и его аргументы: кластер, namespace, сервис, время и окно поиска. Если агент выбрал другой ЦОД, потерял время или вызвал неподходящий tool, сохранённый ответ не подставится и тест завершится ошибкой. После этого проверяется итоговый ответ от самой модели по сырым данным: присутствуют ли подтверждённые факты, не появилась ли выдуманная причина, не назвал ли агент недоступный источник исправным. Один сценарий запускается несколько раз, чтобы увидеть нестабильность выбора инструментов.
Все это работает сейчас долго, и честно хочется универсальности и чуть быстрее получать результат теста, но пока не получилось ничего лучше...
есть в планах, но есть бюрократические тяжбы на которые пока нет времени )
не совсем, это Anthropic ), первая версия ui была слишком "плоской", работала, но не юзерфрендли, а что нужно юзеру кроме стабильности, чтобы было красиво, затягивало, функционально, поэтому дизайн взят с другого проекта по алертингу (о нем чуть позже будет статейка), а он в свою очередь был взят с Grafana Oncall
я с гпу года 3 - 4 назад в кубах работал, в openshift если быть точнее, было так себе да, заводилось тогда все через манипуляции, не знаю сейчас может проще стало
своя, и видимо с тем же названием...надо поправить чтобы не было путаницы, спасибо
это хороший вопрос, честно я даже о нем не думал, видимо это еще впереди, и с учетом того что тул в н8н может поправить любой из команды, выглядит как большая дырка пока что
Перед запуском тест забирает из production MCP актуальный список инструментов, их схемы и контракты. Затем реальной модели задаётся сохранённый вопрос (из истории, отобранный вручную). Когда модель вызывает tool, запрос перехватывается. Вместо обращения в прод источники тест возвращает готовый ответ (в виде raw метрик и логов), ранее полученный в реальной проблеме (для нас это ок, поскольку тулы в mcp узкопрофилированые, при правильных входных данных отдадут правильную выборку). При этом проверяются имя инструмента и его аргументы: кластер, namespace, сервис, время и окно поиска. Если агент выбрал другой ЦОД, потерял время или вызвал неподходящий tool, сохранённый ответ не подставится и тест завершится ошибкой.
После этого проверяется итоговый ответ от самой модели по сырым данным: присутствуют ли подтверждённые факты, не появилась ли выдуманная причина, не назвал ли агент недоступный источник исправным. Один сценарий запускается несколько раз, чтобы увидеть нестабильность выбора инструментов.
Все это работает сейчас долго, и честно хочется универсальности и чуть быстрее получать результат теста, но пока не получилось ничего лучше...
может быть было проще взять Flagger для Canary, ведь он давно все умеет в автомате и даже с анализом и вебхуками.