Регрессионный набор вопросов к ИИ-ассистенту с критериями

После исправления базы знаний ассистент может ответить на прежний вопрос другой формулировкой. Проверять такой ответ по памяти трудно: вчера обсуждали кнопку, сегодня источник, завтра выяснилось, что в тексте появился выдуманный объект метаданных. Я разобрала набор из 18 вопросов, где у каждого вопроса записаны критерии проверки. Ответы сохраняются отдельно, затем обычный Python-скрипт ищет нарушения.

В наборе используются обязательные подстроки, допустимые варианты ответа, запрещённые формулировки и регулярные выражения. Отдельные правила проверяют источники. Для смысла, который трудно выразить поиском строк, оставлена ручная проверка. Вторая модель для выставления оценки не нужна.

В сохранённой пересверке от 27.09.2026 автоматические критерии прошли 4 вопроса из 18. Один из этих четырёх затем не прошёл ручную проверку. Я покажу, как читать такой результат и переносить метод на своего ассистента 1С. Вопросы про интеграцию обезличены; сведения о поведении конкретного расширения рассматриваются только как условия исходного теста.

📂 Как вопрос становится проверкой

Регрессионный вопрос полезен, когда он связан с определённой ошибкой. Пользователь спрашивал про условие в настройке, а ассистент указал сообщение, которого в нужной ветке обработки нет. После исправления хочется проверить, исчезло ли именно это утверждение. Для такой проверки достаточно сохранить вопрос и запрещённую подстроку.

Исходный набор собран из уже заданных вопросов. Скрипт сборки берёт текст и продукт из записи запроса, добавляет идентификатор дефекта, приоритет и expect. Если в запросе было изображение, его путь переносится в карточку. Это сохраняет исходный контекст проверки и позволяет отличать текстовую задачу от вопроса по снимку формы.

Основные поля карточки:

Я пересчитала элементы JSON: в наборе 18 карточек. Это объём конкретной подборки. Из него нельзя вывести покрытие всей базы знаний или качество ассистента на произвольном вопросе. Подборка составлена вокруг найденных проблем, поэтому её результат описывает возврат этих проблем после изменений.

🧾 Как записаны критерии

Формат карточки на учебном примере. Вопрос и критерии придуманы для статьи, в наш набор они не входят:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

[
  {
    "id": "rg-period-lock",
    "base": "period-lock",
    "be": "BE-99",
    "priority": "P1",
    "product": "my-product",
    "question": "Можно ли провести документ задним числом, если в базе установлена дата запрета изменения данных?",
    "expect": {
      "all_of": ["дата запрета"],
      "none_of": ["да, можно провести"],
      "sources_not_only": "общие знания"
    }
  }
]

product - область запроса в контракте сервиса; у вашего ассистента она своя. Результат по такой карточке появится только после опроса вашего сервиса.

В проверяющем коде строки переводятся в нижний регистр, буква «ё» заменяется на «е». Другой нормализации нет: лишние пробелы, переносы строк внутри фразы и перестановка слов могут повлиять на результат. Ожидание сравнивается с нормализованным ответом как подстрока.

Название sources_any легко прочитать слишком широко. В реализации цикл проходит по всем строкам списка. Для каждой требуется хотя бы одно совпадение в источниках. Если вы записали несколько категорий, наличие только одной из них не удовлетворит критерию.

1
2
3

for s in exp.get("sources_any", []):
    if not any(low(s) in x for x in src):
        bad.append(f"в sources нет «{s}»")

Запрещённую подстроку нужно выбирать так, чтобы она обозначала известную ошибку. Если запретить название выдуманного объекта, ответ с предупреждением «такого объекта нет» тоже будет отклонён. У этого поведения есть объяснение: проверка не разбирает отрицание или роль цитаты. Выбирайте короткий критерий осознанно и оставляйте ручную оценку для неоднозначных случаев.

🔧 Что делает проверочный скрипт

Проверка начинается с технической оболочки ответа. Если HTTP-статус отличается от 200, функция сразу возвращает нарушение. Если источники пусты или в тексте есть фраза «произошла ошибка», ответ классифицируется как сбой сервиса под видом успешного HTTP-ответа.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

def low(s: str) -> str:
    return s.lower().replace("ё", "е")

def check(item: dict, rec: dict) -> list:
    bad = []
    if rec.get("http_status") != 200:
        return [f"HTTP {rec.get('http_status')}"]
    resp = rec.get("response") or {}
    answer = resp.get("answer") or ""
    sources = [str(s) for s in resp.get("sources") or []]
    a, src = low(answer), [low(s) for s in sources]
    exp = item.get("expect", {})
    if "произошла ошибка" in a or not sources:
        return [f"ошибка сервиса под видом ответа (HTTP 200): «{answer[:80]}»"]
    if "A533;" in answer or any("A533;" in s for s in sources):
        bad.append("битый UTF-8 (U+FFFD)")
    if resp.get("request_id") != rec.get("trace_id"):
        bad.append(f"request_id не вернулся: {resp.get('request_id')!r}")
    want_product = exp.get("product", item.get("product", "my-product"))
    if resp.get("product") != want_product:
        bad.append(f"product: ждали {want_product}, пришёл {resp.get('product')}")
    for s in exp.get("all_of", []):
        if low(s) not in a:
            bad.append(f"нет «{s}»")
    if exp.get("any_of") and not any(low(s) in a for s in exp["any_of"]):
        bad.append("нет ни одного из: " + ", ".join(f"«{s}»" for s in exp["any_of"]))
    for s in exp.get("none_of", []):
        if low(s) in a:
            bad.append(f"есть «{s}»")
    for rx in exp.get("none_re", []):
        m = re.search(rx, a)
        if m:
            bad.append(f"есть «{m.group(0)}»")
    for s in exp.get("sources_any", []):
        if not any(low(s) in x for x in src):
            bad.append(f"в sources нет «{s}»")
    for s in exp.get("sources_none", []):
        hits = [x for x in sources if low(s) in low(x)]
        if hits:
            bad.append(f"в sources «{s}»: {len(hits)} из {len(sources)}")
    only = exp.get("sources_not_only")
    if only and sources and all(low(only) in x for x in src):
        bad.append(f"все источники - «{only}»")
    return bad

Для запуска этого фрагмента нужны импорты re и обвязка чтения файлов; полный проверяющий скрипт - в архиве к статье. Функция возвращает список нарушений. Пустой список означает прохождение автоматических проверок, которые удалось выполнить для этой записи.

Ранний возврат ограничивает полноту отчёта. При HTTP 502 вы не увидите дополнительные претензии к подстрокам. При пустых источниках функция также заканчивает проверку раньше сверки продукта и идентификатора. Это удобно для первичного разбора: сначала нужно получить пригодный ответ, затем проверять содержание.

Правило непустых источников относится к конкретному контракту RAG-сервиса. Если ваш ассистент имеет допустимый режим ответа без источников, переносить его без изменения нельзя. Точно так же фраза «произошла ошибка» может встретиться в нормальном объяснении пользовательской ошибки. Перед применением общей проверки сопоставьте её с ответами вашего API.

Сверка request_id выполнена простым сравнением с trace_id записи. Для правильно собранных ответов это проверяет возврат отправленного идентификатора. Если оба поля отсутствуют, равенство None == None пройдёт. Поэтому полноту самой записи нужно обеспечить на этапе опроса или дополнить отдельной проверкой присутствия полей в своей адаптации.

Пример из набора ловит дефис после первого сегмента идентификатора ссылки:

1
2
3

{
  "none_re": ["ref=[0-9a-z]{8}-"]
}

Такое правило фиксирует узкую форму найденной ошибки. Оно не проверяет правильность всей навигационной ссылки и не открывает объект в 1С. Отчёт о совпадении говорит, что в тексте обнаружена запрещённая последовательность. Для подтверждения работоспособности ссылки нужна другая проверка.

📡 Как собираются ответы

Для сбора ответов используется отдельный скрипт ask_oracle.py. Перед применением на своём сервисе замените константу адреса. В статье указан адрес-заглушка:

1

ENDPOINT = "https://example.local/api/ask"

Скрипт создаёт UUID для каждого запроса и помещает его в request_id и заголовок X-Trace-ID. В тело также входят question, product и session_id. Исходная реализация задаёт одну фиксированную сессию rb-prod-04 для всего пакета. Она не создаёт отдельный диалог на каждый вопрос.

При наличии image_file содержимое файла кодируется в Base64 и передаётся в поле image. Для вопроса по форме требуется тот же снимок, к которому относятся ожидания. Другой снимок с похожими переключателями сделает ручной критерий неверным.

Повторная попытка защищена от перезаписи старой. Если файл с тем же id уже существует, он переименовывается в <id>.prev-N.json. Затем новый ответ занимает основное имя. Проверяющий скрипт читает основное имя; предыдущие попытки нужно анализировать отдельно.

В PowerShell запуск на своём наборе выглядит так:

1
2
3

$env:PYTHONIOENCODING = 'utf-8'
python tools/ask_oracle.py questions-backend-regression.json out/
python tools/check_api_regression.py questions-backend-regression.json out/

Команды предполагают, что адрес уже адаптирован, карточки обезличены и пути к изображениям доступны. Адрес example.local служит заглушкой. Перед сетевым запуском проверьте контракт своего API; приведённый опросник не универсален для произвольной формы запроса.

По умолчанию используются четыре рабочих потока, число меняется через ORACLE_WORKERS. В исходном клиенте таймаут запроса равен 180 секундам. Эти значения описывают настройку опросника и не гарантируют время ответа. Проверка сохранённых файлов сама по себе сетевых запросов не делает.

Для повторов с другим префиксом есть параметр проверяющего скрипта:

1

python tools/check_api_regression.py questions-backend-regression.json out/ --prefix rc4-

Префикс меняет ожидаемое имя файла ответа: rc4- плюс base. Он не меняет поле id в наборе и не переименовывает сохранённые файлы. Если опросник использует прежний id, ответ сохранится с прежним именем. Подготовку другого набора идентификаторов нужно выполнять отдельно и явно.

При отсутствии файла проверка выводит НЕТ ОТВЕТА и засчитывает вопрос как непройденный. Повреждённый JSON или структура неожиданного типа способны прервать выполнение: полноценной валидации схемы в исходной реализации нет. Такой запуск тоже нельзя объявлять успешной регрессией.

📉 Что показала пересверка

Сохранённый прогон выполнен 27.09.2026 в интервале 15:23–15:31 UTC с префиксом rc4-. В отчёте автоматическое OK получили BE-02, BE-08, один вопрос BE-14 и BE-07. Остальные 14 карточек не прошли. Это исторический результат конкретного набора и ответов.

Часть вывода привожу с исходными длительностями; строки с названиями объектов стороннего расширения убраны. Итог я повторила 05.10.2026 на сохранённых ответах: снова 4 из 18. Короткий trace служит идентификатором запроса, доступа к сервису он не даёт.

BE-02  P1  ch2-04-button-title                OK [5.5 с, trace 9f7e7469]
BE-16  P2  ch3-14-nav-link-code               НЕ ПРОШЁЛ [16.1 с, trace 62c2a893]: есть «разделенных дефисами»; есть «ref=a1b2c3d4-»
BE-07  P2  ch5-01-401-after-rotation          OK [4.6 с, trace c78e8729]
                                             ВРУЧНУЮ: в одном ответе нет взаимоисключающих утверждений о сроке жизни токена (раньше: «истёк» и «бессрочный до отзыва»)

итого: 4 из 18 прошли автоматические критерии

В строках, которые я убрала, есть два типичных провала. В одном ответе нет обязательного названия флага настройки: это повод открыть полный ответ и выяснить, пропущено ли условие или использована другая формулировка. В другом есть запрещённая фраза из прежнего неверного ответа.

BE-16 ловит две формы ошибки: словесное описание и характерный фрагмент ссылки. Оба нарушения относятся к одному вопросу и увеличивают число сообщений, но вопрос всё равно считается одним непройденным элементом.

Для BE-07 автоматическая часть прошла. Ручная пересверка обнаружила в одном ответе утверждения о том, что срок токена истёк и что он действует бессрочно до отзыва. В сохранённой заметке этот вопрос отмечен как непройденный вручную. Значит, строку «4 из 18» нельзя переименовать в «четыре правильных ответа».

Вопрос со снимком формы, напротив, прошёл ручную проверку: были указаны пять переключателей, пояснительная надпись не была принята за переключатель. Это отдельное подтверждение поверх автоматического OK. Скрипт такое подтверждение не хранит в вычисляемом результате; в материалах оно записано текстом.

Сохранена и история повторов. В первых попытках трёх вопросов сервис вернул HTTP 200 с сообщением об ошибке поиска и пустыми источниками. Они выполнялись при четырёх потоках; после повторов по одному появились обычные ответы. Наблюдение показывает последовательность событий. Причинную связь между параллелизмом и сбоем я по этому прогону не устанавливаю.

Сводка по основным файлам отражает последние сохранённые попытки. Предыдущие ответы со сбоями остаются отдельными файлами. Для оценки устойчивости нужно учитывать и их: успешный повтор не отменяет произошедший отказ. Для оценки содержания последнего ответа используется основной файл.

🔎 Как разбирать провал

При техническом отказе полезны время отправки, статус и предыдущие попытки. При несовпадении product нужно смотреть маршрутизацию запроса. При неверных источниках следует проверить состав найденных материалов. При отсутствии обязательной подстроки прочитайте весь ответ: лексический критерий мог оказаться слишком узким.

Для none_re отдельно проверяйте границы совпадения. Регулярное выражение ловит форму текста, но не знает структуры языка 1С. Оно может найти запрещённое имя в цитате ошибочного совета, который ассистент опровергает. Тогда нужен разбор контекста и, возможно, ручное условие для этого вопроса.

Ручные критерии стоит формулировать так, чтобы проверяющий мог записать результат и причину. Условие «ответ хороший» не подходит. В исходном наборе есть более конкретные ожидания: перечень переключателей на снимке и отсутствие взаимоисключающих утверждений в одном ответе. Такие проверки можно повторить другому человеку.

После изменения ассистента повторите тот же набор с новым каталогом ответов. Сопоставьте нарушения по base и дефекту, проверьте вопросы с manual. Если менялись документы или условия теста, зафиксируйте это рядом с результатом. Сравнивать ответы на разные формулировки как один эксперимент без оговорки нельзя.

🧭 Ограничения

Набор содержит 18 вопросов вокруг известных дефектов конкретного ассистента. В сохранённом отчёте указана дата 27.09.2026. Версии серверной модели, поискового компонента и всех документов для этого прогона не зафиксированы в использованных материалах, поэтому я не заявляю результат для определённой версии модели или текущего состояния сервиса.

Сетевой опрос сервиса для статьи я не повторяла; повторила только проверку сохранённых ответов. Учебную карточку и свои вопросы проверьте на своём сервисе. Ожидания о поведении стороннего расширения на другие конфигурации 1С не переносятся.

Поиск подстрок допускает ошибочный ответ с нужными словами и отклоняет верный ответ с другой лексикой. Регулярные выражения не проверяют выполнение кода, достоверность документа или работоспособность ссылки. Непустые sources подтверждают наличие поля с элементами; содержимое источника и соответствие конкретному утверждению требуют отдельной проверки.

Автоматическое OK не включает выполнение manual. В исходном прогоне это существенно для BE-07. Полноценной оценки смысловой точности, полноты ответа и отсутствия всех противоречий скрипт не даёт. Вторая модель не использовалась, смысловую оценку оставили человеку.

Клиент использует фиксированный session_id и допускает параллельные запросы. Влияние истории сессии и параллелизма на ответы здесь отдельно не измерено. Проверка предполагает корректную структуру JSON; повреждённые записи способны остановить пакет. Сверка идентификаторов не проверяет их наличие, если оба значения пропущены.

Длительности в историческом выводе относятся к отдельным обращениям. По ним я не рассчитывала среднее время ответа или гарантии скорости. Результат «4 из 18» описывает прохождение автоматических правил на последней сохранённой попытке каждого вопроса и не выражает долю верных ответов ассистента в эксплуатации.

📚 Источники

• questions-backend-regression.json: 18 карточек с вопросами и expect; структура и выбранные критерии приведены в тексте.
• build_backend_regression.py: сборка карточек из сохранённых запросов, перенос поля изображения и связь с дефектами.
• check_api_regression.py и ask_oracle.py: правила проверки, сохранение ответов, префиксы и история попыток. В листинге адрес заменён на https://example.local/api/ask.
• «Перепроверка дефектов сервиса, 27.09.2026», отчёт backend-recheck-2026-09-27.txt: автоматические результаты и отдельные ручные решения. Раздел «Регрессионный набор и как им пользоваться» плана бэкенда подтверждает порядок опроса и проверки.
• Предшественники на Infostart: ИИ-инструменты для 1С на исполняемом бенчмарке: 35 задач, реальная платформа, разбор ошибок (Ruslic, 21.09.2026); Какая нейросеть лучше всего решает задачи 1С: бенчмарк моделей и агентных подходов (Vaslot, 10.07.2026); CI для 1С до слияния в master: EDT, эталонные базы и параллельные тесты на Merge Request (zolotov7481, 28.09.2026). Там сравнивают модели на задачах кода; здесь проверяются ответы ассистента пользователям.

📎 Файл к статье

В архиве к статье - 50.8-companion.zip: проверочный скрипт check_api_regression.py, опросник ask_oracle.py с адресом-заглушкой, учебный набор из трёх карточек с ответами для пробного запуска без сети, шаблон ручной проверки, вывод прогона 06.10.2026 и README. Наш рабочий набор из 18 вопросов в архив не входит: он построен на поведении стороннего расширения. Перед запуском на своём сервисе замените адрес и значение product под контракт своего API и подтвердите каждое ожидание по своим материалам.

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор 48 технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S