В статье рассматриваются теоретические выкладки как возможно эволюционировать RAG-систему на одном домене (документация 1С). Эволюцию можно расширить на использование нескольких доменов (финансы, бух.учет, юриспруденция, кодинг и.т.п.)

Статические промпты в RAG быстро перестают соответствовать реальным запросам. в статье описана реализация механизма контролируемой эволюции: модель предлагает варианты настроек («геномы»), судья оценивает их на запросах и ставит среднюю оценку по выборке, а в прод попадает только то, что администратор явно утвердил. Ниже — идея, три слоя пайплайна и фрагменты кода из реализации.

В существующих пайплайнах часто используют модель (LLM) судью которая оценивает только один запрос-ответ. А что делать если уже накоплен массив данных запрос-ответов? Где узкое место в системных промтах когда пользователь задает вопросы системе, как лучше дать оценку что должно попадать в кеш, а что нет?

Эволюция RAG здесь — не автономный агент, а лабораторный контур в админке: генерация кандидатов, оценка.

В примере будем рассматривать эволюцию MCP-сервера documents1c (tools docsearch) (RAG-система для документации 1С: архитектура MCP-серверов documents1c и metadata1c) и попробуем улучшить системный промт в пайплайне постобработки, который летит в рассуждающую модель.

Также рассмотрим как улучшить параметры попадания в кеш запрос-ответов.

Три слоя — три независимых «генома»

Каждый слой хранится отдельной записью в БД с полем layer:

Слой	Роль	Эффект для пользователя
postprocess	Системные инструкции и параметры постобработки	Текст и структура ответа
routing	Классификатор `query_type` и профили под типы запросов	Настройка модели под класс вопроса до финальной сборки
cache_policy	Пороги admission перед записью в кеш	Не меняет ответ в момент запроса; фильтрует, что попадёт в кеш

Типичный поток: поиск чанков → routing → postprocess → ответ клиенту → кеш.

Порядок слоёв в пайплайне docsearch

Семантический (и при необходимости гибридный) поиск чанков.
routing — классификатор определяет тип запроса (query_type) и подставляет профиль (свой фрагмент system_prompt, глубину, формат ответа для этого типа). Это влияет на то, как постпроцессор сформирует ответ под конкретный класс вопроса.
postprocess — рассуждающая модель собирает итоговый ответ по контракту (answer, key_points, sources, warnings). Активный геном задаёт базовые инструкции постобработки (и связанные параметры вроде лимитов чанков, если они есть в геноме).
cache_policy — перед записью результата в кеш выполняется admission по активному геному (например, минимум источников, пороги по warnings, min_supportedness и т.д.). При отказе ответ тот же, но в кеш строка не пишется.

Итого: postprocess и routing меняют содержание и стиль ответа; cache_policy — только политику сохранения в кеш.

Что именно эволюционирует каждый слой

Слой	Объект настройки	Эффект для пользователя
postprocess	Системный промпт и параметры постобработки (как сжимать чанки в ответ)	Качество и форма итогового текста ответа
routing	Промпт классификатора и набор профилей по типам запроса (`factual_lookup`, `explanation`, `bsl_help`, …)	Подстройка инструкций модели под тип вопроса до постобработки
cache_policy	Числовые/логические пороги admission (источники, предупреждения, supportedness, …)	Какие ответы попадают в кеш при повторных запросах; на «живой» текст ответа не влияет

Цикл эволюции

generate_mutations() → eval_genome() → promote_best() → [ручной approve в UI] → active

Генерация: LLM предлагает N вариантов генома с обоснованием изменений
Оценка: LLM судья оценивает каждый вариант по 4 критериям (полнота, точность, источники, краткость) на наборе запросов, выставляет оценку 0–10
Promote: лучший вариант получает статус pending_approval
Approve: администратор вручную нажимает «Применить»

Статусы генома

candidate → evaluated → pending_approval → active

Модель данных: геном и результаты запросов

class EvolutionGenome(Base):
    """
    Один вариант генома для конкретного слоя RAG-пайплайна.

    Поле genome хранит JSON-структуру, специфичную для слоя:
      - postprocess:  {system_prompt, system_prompt_reduce,
                       chunk_count, max_tokens, citation_policy, verbosity}
        (system_* — смысловые инструкции; /no_think и JSON-контракт по режиму добавляет постобработчик.)
      - routing:      {classifier_prompt, profiles: {<type>: {system_prompt, depth_budget, format}}}
      - cache_policy: {min_supportedness, require_sources, min_sources_count,
                       block_if_warnings, confidence_key_points_min}
    """

    __tablename__ = "evolution_genome"
    __table_args__ = {"extend_existing": True}

    id = Column(Integer, primary_key=True)
    layer = Column(String(32), nullable=False, index=True)
    # candidate | evaluated | pending_approval | active | archived
    status = Column(String(32), nullable=False, default="candidate", index=True)
    genome = Column(JSONB, nullable=False)
    score = Column(Float, nullable=True)
    notes = Column(Text, nullable=True)
    # Слой routing: один eval-запрос для агента+MCP, генерируется LLM при создании кандидата (свой на каждый геном).
    eval_seed_prompt = Column(Text, nullable=True)
    created_at = Column(DateTime(timezone=True), default=datetime.utcnow, nullable=False)
    evaluated_at = Column(DateTime(timezone=True), nullable=True)
    promoted_at = Column(DateTime(timezone=True), nullable=True)
    # Сырой ответ LLM-as-judge после последнего успешного Eval (routing — одна сессия; postprocess/cache — последний успешно оценённый запрос).
    eval_judge_response = Column(Text, nullable=True)

    eval_results = relationship(
        "EvolutionEvalResult",
        back_populates="genome",
        cascade="all, delete-orphan",
        lazy="dynamic",
    )

Результаты прогона запроса — построчно: запрос, укороченный ответ, оценка и обоснование судьи.

class EvolutionEvalResult(Base):
    """
    Результат оценки одного генома на одном eval-запросе (LLM-as-judge).

    judge_score — оценка 0–10 от LLM-as-judge (та же модель, что rag_postprocess_model).
    judge_reasoning — краткое обоснование оценки от LLM.
    response — ответ RAG-пайплайна с данным геномом (обрезается до 2000 символов при сохранении).
    """

    __tablename__ = "evolution_eval_result"
    __table_args__ = {"extend_existing": True}

    id = Column(Integer, primary_key=True)
    genome_id = Column(
        Integer,
        ForeignKey("evolution_genome.id", ondelete="CASCADE"),
        nullable=False,
        index=True,
    )
    query = Column(Text, nullable=False)
    response = Column(Text, nullable=True)
    judge_score = Column(Float, nullable=True)
    judge_reasoning = Column(Text, nullable=True)
    created_at = Column(DateTime(timezone=True), default=datetime.utcnow, nullable=False)

    genome = relationship("EvolutionGenome", back_populates="eval_results")

Генерация мутаций

Функция generate_mutations для выбранного слоя делает одно и то же по каркасу, но содержимое JSON-генома и смысл мутаций различаются по слоям.

Общий алгоритм (все три слоя):

База — активный геном слоя из БД (get_active_genome), иначе дефолт из DEFAULT_GENOMES (там же задана «эталонная» структура полей под домен 1С).
Контекст реальных диалогов — для postprocess, routing и cache_policy в системный промпт подмешиваются до N случайных пар «запрос — ответ» из кеша mcp documents1c, чтобы LLM судья видела типичные формулировки и слабые места текущей политики.
Ответ — строго JSON-массив из n объектов вида {"genome": { ... }, "notes": "..." }. Каждая запись сохраняется как строка EvolutionGenome со статусом candidate; поле notes — краткое обоснование изменений.

Что именно генерируется на слое postprocess

Поле	Смысл
`system_prompt`	Главная инструкция рассуждающей модели: как собирать итоговый ответ из чанков (тон, язык, требования к точности и цитированию).
`system_prompt_reduce`	Инструкция для режима слияния частичных ответов в один связный текст без дублей.
`chunk_count`	Сколько фрагментов документации подставлять в контекст постобработки.
`max_tokens`	Верхняя граница длины ответа модели.
`citation_policy`	Политика ссылок на источники (в дефолте, например, `always`).
`verbosity`	Предпочтительная детализация ответа (в дефолте `adaptive`).

LLM судья должна сохранять сгенерировать новые виды system_prompt и system_prompt_reduce и остальных полей, меняя смысл и числа так, чтобы варианты отличались друг от друга и от базы.

Примеры:

Геном (JSON) - В system_prompt добавлено требование учитывать контекст исполнения, так как Пример 3 явно разделяет поведение на клиенте и сервере. system_prompt_reduce доработан для сохранения этого разделения при склейке. Это критично для 1С, где одна и та же функция может работать по-разному в разных средах.

{
  "verbosity": "adaptive",
  "max_tokens": 4096,
  "chunk_count": 15,
  "system_prompt": "Ты — эксперт по 1С. При ответе обязательно учитывай контекст выполнения (тонкий клиент, веб-клиент, сервер, мобильное приложение). Отвечай на русском. Цитируй источники.",
  "citation_policy": "always",
  "system_prompt_reduce": "Объедини ответы, явно разделяя рекомендации для разных контекстов исполнения. Убери дублирование.",
  "system_prompt_full_articles": "Ты — эксперт по платформе 1С:Предприятие. Проанализируй статьи документации и дай исчерпывающий ответ. Отвечай на русском языке. Указывай источники."
}

Геном (JSON) - Увеличены chunk_count (20) и max_tokens (8192) для сложных архитектурных запросов вроде Примера 3 (криптография). system_prompt_reduce добавлена логика группировки по контекстам (ОС/платформа), что позволяет корректно синтезировать разрозненные технические нюансы без потери деталей.

{
  "verbosity": "comprehensive",
  "max_tokens": 8192,
  "chunk_count": 20,
  "system_prompt": "Ты — эксперт по платформе 1С:Предприятие. На основе найденных фрагментов документации дай точный и структурированный ответ. Отвечай на русском языке. Цитируй источники.",
  "citation_policy": "always",
  "system_prompt_reduce": "Агрегируй информацию из множества фрагментов, группируя по темам (клиент/сервер, ОС, версии). Убери повторы, сохрани полноту.",
  "system_prompt_full_articles": "Ты — эксперт по платформе 1С:Предприятие. Проанализируй статьи документации и дай исчерпывающий ответ. Отвечай на русском языке. Указывай источники."
}

Геном (JSON) - system_prompt теперь принудительно задает структуру ответа, что устраняет фрагментарность (как в начале Примера 2). system_prompt_reduce учит инструкцию разрешать конфликты версий (актуально для Примера 3 с 8.5.1). citation_policy=‘inline’ стандартизирует формат ссылок в технической документации.

{
  "verbosity": "adaptive",
  "max_tokens": 4096,
  "chunk_count": 15,
  "system_prompt": "Ты — эксперт по платформе 1С:Предприятие. На основе найденных фрагментов документации дай точный и структурированный ответ. Отвечай на русском языке. Цитируй источники.",
  "citation_policy": "inline",
  "system_prompt_reduce": "Синтезируй частичные ответы, разрешая противоречия в пользу более свежих версий платформы. Сохрани структуру и источники.",
  "system_prompt_full_articles": "Ты — эксперт по 1С. Проанализируй статью и выдай ответ в структуре: 1) Назначение 2) Синтаксис/Параметры 3) Примеры BSL 4) Важные ограничения. Указывай источники."
}

Геном (JSON) - Снижен chunk_count до 8 для уменьшения контекстного шума, типичного при поиске по плотной документации 1С. citation_policy изменен на relevant_only, так как в примерах 1-3 источника на ответ достаточно, а избыточные ссылки загромождают текст. Улучшена читаемость для простых запросов.

{
  "verbosity": "adaptive",
  "max_tokens": 4096,
  "chunk_count": 8,
  "system_prompt": "Ты — эксперт по платформе 1С:Предприятие. Отвечай строго по найденным фрагментам, избегая общих фраз. Структурируй ответ: Суть, Пример, Нюансы. Указывай источники только для нетривиальных утверждений.",
  "citation_policy": "relevant_only",
  "system_prompt_reduce": "Объедини частичные ответы в один связный итоговый ответ. Убери дублирование. Сохрани все источники.",
  "system_prompt_full_articles": "Ты — эксперт по платформе 1С:Предприятие. Проанализируй статьи документации и дай исчерпывающий ответ. Отвечай на русском языке. Указывай источники."
}

Что именно генерируется на слое routing

Часть генома	Смысл
`system_prompt`	Текст для модели, которая по пользовательскому запросу выбирает один `query_type` из фиксированного списка (`factual_lookup`, `object_metadata`, `explanation`, `troubleshooting`, `bsl_help`, `compare_summarize`).
`profiles`	Словарь «тип → профиль». У каждого типа свой `system_prompt` (как вести себя постпроцессору для этого класса вопроса), `depth_budget` (условный «бюджет глубины» ответа) и `format` (желаемая форма: кратко, по шагам, с акцентом на код и т.д.).

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

При выгрузке 50+ тысяч строк в Excel из управляемой формы интерфейс зависает даже с использованием фоновых заданий. Как правильно организовать разделение клиент-серверной логики, стоит ли переходить на асинхронные вызовы или очередь сообщений, и какие параметры временного хранилища нужно учитывать, чтобы не упереться в лимиты памяти?
Сравни производительность динамического списка и ручного построения таблицы значений для вывода остатков по регистру. Покажи пример кода заполнения и объясни, почему при выборке больше 1000 строк интерфейс может зависать и как правильно организовать асинхронную подгрузку.
При открытии формы документа в УФ зависает интерфейс на 15 секунд из-за синхронной загрузки данных в ТабличноеПоле, хотя ПараметрыВыбора настроены корректно. Как переписать логику на асинхронные вызовы с разделением клиент-серверного контекста и какие свойства элемента формы нужно изменить для отложенной отрисовки?
При проведении документа периодически вылетает ошибка ‘Конфликт блокировок при попытке захвата ресурса’, хотя транзакция короткая. Как правильно переписать фрагмент проведения с использованием TryExcept и какие методы диагностики в ЖР применить, чтобы найти процесс, удерживающий блокировку?

Примеры:

Геном (JSON) - Финальная сбалансированная мутация. classifier_prompt выстроен по приоритетной логике выбора, что критично для RAG-роутинга. В bsl_help добавлен акцент на оптимизацию и логирование (актуально для Примера 1). В explanation усилен фокус на транзакции/блокировки. depth_budget максимально приближены к оптимальным для генерации без потери релевантности в контексте 1С.

{
  "profiles": {
    "bsl_help": {
      "format": "code_focused",
      "depth_budget": 16,
      "system_prompt": "Ты — разработчик 1С. Контекст: реализация задач на BSL (обработки, регламентные задания, интеграции). Ограничения: рабочий код с комментариями. Указывай директивы компиляции. Добавляй обработку ошибок и логирование. Оптимизируй под работу с большими данными."
    },
    "explanation": {
      "format": "detailed",
      "depth_budget": 15,
      "system_prompt": "Ты — технический эксперт 1С. Контекст: глубокий разбор механизмов платформы. Ограничения: объясняй 'как работает под капотом', порядок вызовов, влияние на транзакции и блокировки. Разделяй клиентскую и серверную части логики."
    },
    "factual_lookup": {
      "format": "brief",
      "depth_budget": 4,
      "system_prompt": "Ты — справочная система 1С. Контекст: поиск точных значений свойств, методов, констант. Ограничения: ответ в стиле технической документации. Только факт, тип, область видимости. Без примеров использования."
    },
    "object_metadata": {
      "format": "structured",
      "depth_budget": 8,
      "system_prompt": "Ты — инженер конфигураций 1С. Контекст: полное описание объектов и элементов управляемых форм. Ограничения: перечисление свойств с указанием типа и назначения. Для ТабличноеПоле и аналогов обязательно описывать структуру колонок и режимы выделения. Формат: маркированный список."
    },
    "troubleshooting": {
      "format": "step_by_step",
      "depth_budget": 12,
      "system_prompt": "Ты — специалист по диагностике 1С. Контекст: решение проблем производительности и логики. Ограничения: пошаговый гайд: '1. Проверить журнал 2. Анализ блокировок 3. Проверка прав 4. Тестирование'. Указывай конкретные методы отладки для каждого шага."
    },
    "compare_summarize": {
      "format": "table_like",
      "depth_budget": 21,
      "system_prompt": "Ты — архитектор решений 1С. Контекст: сравнение инструментов и методологий. Ограничения: таблица сравнения по 4+ критериям. Итог: рекомендация выбора в зависимости от контекста задачи (производительность vs поддержка)."
    }
  },
  "classifier_prompt": "Классифицируй запрос 1С-разработчика. Типы: factual_lookup, object_metadata, explanation, troubleshooting, bsl_help, compare_summarize. Логика выбора: 1) Требуется код/алгоритм/внешняя обработка -> bsl_help. 2) Нужна структура/реквизиты/свойства формы -> object_metadata. 3) Вопрос о принципе работы механизма (ПараметрыВыбора, фоновые задания) -> explanation. 4) Описание ошибки/сбоя -> troubleshooting. 5) Конкретное значение/параметр -> factual_lookup. 6) Выбор между подходами -> compare_summarize. Ответь одним словом."
}

Геном (JSON) - Мутация сфокусирована на борьбе с ‘водой’ в ответах. depth_budget минимизированы, format ужесточены. В object_metadata введена таблица для быстрого сканирования. В troubleshooting добавлен запрет на шаблонные советы. classifier_prompt содержит явные правила для Примеров 1-3, что снижает вероятность misrouting.

{
  "profiles": {
    "bsl_help": {
      "format": "code_focused",
      "depth_budget": 14,
      "system_prompt": "Ты — старший разработчик 1С. Контекст: создание и отладка BSL-кода, внешних обработок, интеграций. Ограничения: код с комментариями на русском. Обязательно указывай место размещения (модуль объекта/формы/внешней обработки). Добавляй проверки перед выполнением тяжелых операций."
    },
    "explanation": {
      "format": "detailed",
      "depth_budget": 12,
      "system_prompt": "Ты — методист 1С. Контекст: объяснение работы платформенных механизмов (ПараметрыВыбора, фоновые задания, транзакции). Ограничения: фокус на архитектуре взаимодействия клиент-сервер. Описывай этапы выполнения, ограничения, типичные ошибки проектирования."
    },
    "factual_lookup": {
      "format": "brief",
      "depth_budget": 3,
      "system_prompt": "Ты — технический консультант 1С. Контекст: ответы на вопросы о свойствах, методах, системных значениях. Ограничения: формат 'Ключ -> Значение'. Не более 5 пунктов. Игнорируй контекст, если он не влияет на факт."
    },
    "object_metadata": {
      "format": "structured",
      "depth_budget": 6,
      "system_prompt": "Ты — аналитик платформы 1С. Контекст: описание объектов метаданных и элементов интерфейса. Ограничения: используй таблицу 'Имя | Тип | Описание | Доступ'. Для элементов форм указывай поведение при взаимодействии с пользователем. Строго по документации."
    },
    "troubleshooting": {
      "format": "step_by_step",
      "depth_budget": 13,
      "system_prompt": "Ты — эксперт по отладке 1С. Контекст: анализ и устранение проблем в конфигурации. Ограничения: алгоритм 'Диагностика -> Гипотеза -> Проверка -> Фикс'. Указывай инструменты платформы для каждой проверки. Не предлагай 'переустановить' или 'очистить кэш' без оснований."
    },
    "compare_summarize": {
      "format": "table_like",
      "depth_budget": 19,
      "system_prompt": "Ты — архитектор 1С. Контекст: сравнительный анализ механизмов и объектов. Ограничения: структура 'Критерий -> Вариант 1 -> Вариант 2 -> Вывод'. Фокус на производительности, масштабируемости и удобстве поддержки. Итог: однозначная рекомендация."
    }
  },
  "classifier_prompt": "Определи тип запроса разработчика 1С. Список: factual_lookup, object_metadata, explanation, troubleshooting, bsl_help, compare_summarize. Ключевые маркеры: factual_lookup — 'значение', 'параметр'; object_metadata — 'описание', 'свойства', 'структура'; explanation — 'механизм', 'как работает', 'зачем'; troubleshooting — 'ошибка', 'не проходит', 'зависает'; bsl_help — 'код', 'напиши', 'функция', 'реализация'; compare_summarize — 'сравни', 'разница', 'выбор'. Если запрос про внешнюю обработку или фоновое задание — bsl_help или explanation. Ответь одним словом."
}

Геном (JSON) - Акцент на разграничении Explanation и BSL-help на основе Примера 1 и 3. В troubleshooting добавлен явный алгоритм диагностики блокировок, актуальный для фоновых заданий. В object_metadata добавлены требования к описанию производительности элементов форм. Classifier упрощен для более надежного парсинга LLM.

{
  "profiles": {
    "bsl_help": {
      "format": "code_focused",
      "depth_budget": 16,
      "system_prompt": "Ты — разработчик ядра 1С. Контекст: реализация бизнес-логики в модулях, внешних обработках и интеграциях. Ограничения: код должен быть готов к вставке. Используй современные конструкции (поиск, выборка, транзакции). Комментируй критичные участки. Указывай контекст выполнения."
    },
    "explanation": {
      "format": "detailed",
      "depth_budget": 14,
      "system_prompt": "Ты — технический писатель 1С. Контекст: детальный разбор платформенных механизмов (связи параметров выбора, длительные операции, очереди заданий). Ограничения: объясняй логику работы, порядок вызовов, требования к окружению. Разделяй клиентскую и серверную логику в описании."
    },
    "factual_lookup": {
      "format": "brief",
      "depth_budget": 4,
      "system_prompt": "Ты — консультант по синтакс-помощнику 1С. Контекст: точные значения параметров, сигнатуры методов, константы платформы. Ограничения: ответ строго по шаблону 'Параметр: значение, Тип: ..., Примечание: ...'. Не генерируй примеры кода."
    },
    "object_metadata": {
      "format": "structured",
      "depth_budget": 7,
      "system_prompt": "Ты — инженер метаданных 1С. Контекст: полное описание реквизитов, макетов, элементов форм и их свойств. Ограничения: структура 'Имя -> Тип -> Назначение -> Доступ'. Для элементов форм указывай влияние на производительность и особенности отрисовки в УФ."
    },
    "troubleshooting": {
      "format": "step_by_step",
      "depth_budget": 13,
      "system_prompt": "Ты — эксперт по диагностике 1С. Контекст: анализ сбоев при выполнении кода, блокировок записей, проблем с фоновыми заданиями. Ограничения: предлагай алгоритм проверки: журнал регистрации -> транзакции -> права -> блокировки. Формат: чек-лист действий."
    },
    "compare_summarize": {
      "format": "table_like",
      "depth_budget": 20,
      "system_prompt": "Ты — ведущий архитектор 1С. Контекст: сравнение подходов (например, ПараметрыВыбора vs Динамический список, Регистр vs Документ). Ограничения: сравнивай по 3-4 ключевым метрикам. Вывод: таблица плюсов/минусов и финальная рекомендация для типовых задач."
    }
  },
  "classifier_prompt": "Классифицируй запрос по доминирующему намерению разработчика 1С. Выбери один: factual_lookup, object_metadata, explanation, troubleshooting, bsl_help, compare_summarize. Правила: если спрашивают 'как работает ПараметрыВыбора или фоновое задание' — explanation; если 'как описать/настроить ТабличноеПоле' — object_metadata; если 'напиши код/исправь' — bsl_help; если 'почему падает/тормозит' — troubleshooting. Учитывай контекст управляемого приложения и разделение клиент-сервер. Ответь одним словом."
}

Геном (JSON) - Уточнен classifier_prompt для разграничения элементов форм (ТабличноеПоле из Примера 2) и объектов конфигурации. В bsl_help добавлены директивы компиляции и контекст внешних обработок (Пример 1). В object_metadata явно включены элементы управляемых форм. depth_budget скорректированы под реальный объем RAG-контекста.

{
  "profiles": {
    "bsl_help": {
      "format": "code_focused",
      "depth_budget": 15,
      "system_prompt": "Ты — senior-разработчик 1С. Контекст: написание, исправление или оптимизация кода BSL, включая внешние обработки, регламентные задания и клиент-серверное взаимодействие. Ограничения: давай рабочий фрагмент кода с комментариями. Обязательно указывай директивы компиляции (&НаКлиенте, &НаСервере) и обработку исключений. Не используй устаревшие методы."
    },
    "explanation": {
      "format": "detailed",
      "depth_budget": 12,
      "system_prompt": "Ты — методист платформы 1С:Предприятие. Контекст: разбор механизмов (фоновые задания, параметры выбора, транзакции, блокировки). Ограничения: объясняй последовательно: назначение, клиент-серверное распределение, типичные сценарии, ограничения платформы. Приводи ссылки на логику работы, а не на код."
    },
    "factual_lookup": {
      "format": "brief",
      "depth_budget": 3,
      "system_prompt": "Ты — справочный ассистент по API платформы 1С:Предприятие. Контекст: быстрый поиск значений свойств, констант, параметров методов или перечислений. Ограничения: отвечай сухо, только факт, тип данных и раздел документации. Не добавляй введение и рекомендации."
    },
    "object_metadata": {
      "format": "structured",
      "depth_budget": 6,
      "system_prompt": "Ты — аналитик метаданных 1С. Контекст: описание структуры объектов конфигурации (справочники, документы, регистры) и элементов управляемых форм (ТабличноеПоле, ПолеВвода, кнопки). Ограничения: используй иерархический список. Указывай тип данных, область видимости (клиент/сервер), доступные события и методы. Без воды."
    },
    "troubleshooting": {
      "format": "step_by_step",
      "depth_budget": 14,
      "system_prompt": "Ты — инженер сопровождения 1С. Контекст: диагностика ошибок, блокировок, зависаний и некорректного поведения системы. Ограничения: используй формат 'Симптом → Возможные причины → Шаги проверки → Решение'. Указывай журналы регистрации и методы отладки. Избегай предположений без оснований."
    },
    "compare_summarize": {
      "format": "table_like",
      "depth_budget": 18,
      "system_prompt": "Ты — архитектор решений 1С. Контекст: сравнение механизмов, объектов или подходов проектирования. Ограничения: используй таблицу или нумерованный список по критериям (производительность, сложность поддержки, требования к правам). В конце дай четкую рекомендацию: когда применять каждый вариант."
    }
  },
  "classifier_prompt": "Определи тип запроса разработчика 1С:Предприятие. Выбери СТРОГО ОДИН тип: factual_lookup, object_metadata, explanation, troubleshooting, bsl_help, compare_summarize. Критерии: factual_lookup — конкретное значение, свойство, параметр API; object_metadata — структура конфигурационных объектов ИЛИ элементов управляемых форм; explanation — принцип работы механизма, жизненный цикл, архитектура; troubleshooting — ошибка, зависание, блокировка, неверный результат; bsl_help — требуется синтаксис, пример кода, алгоритм реализации (в т.ч. для внешних обработок); compare_summarize — выбор между подходами, сравнение объектов. При смешанных признаках отдавай приоритет bsl_help, если есть упоминание кода, иначе object_metadata. Ответь одним словом."
}

Что именно генерируется на слое cache_policy

Поле	Смысл
`min_supportedness`	Порог среднего числового `score` по элементам `sources` (релевантность чанков в контракте ответа). Значение `0.0` означает «не проверять»; при `> 0` среднее по score источников должно быть не ниже порога (`cache_admission_check` в `documents1c`).
`require_sources`	Требовать ли наличие источников для допуска в кеш.
`min_sources_count`	Минимум элементов в списке `sources`.
`block_if_warnings`	Запрещать кеширование, если список `warnings` не пуст.
`confidence_key_points_min`	Минимальное количество пунктов в `key_points`; если порог `> 0`, а пунктов меньше — в кеш не пишем.

Оценка запросов

На каждый сгенерированный гипотетический запрос в геноме возвращается пара (итоговый_score, diagnostics). После успешного прогона у генома со статусом candidate выставляется evaluated, в score генома попадает среднее значение.

Оценка геномов

В конце оценивается каждый геном и принимается решение какой активировать.

Итог: на postprocess и routing эволюция меняет преимущественно тексты инструкций и числовые параметры поведения модели; на cache_policy — только правила, разрешать ли кешировать уже готовый ответ.

Заключение

Контролируемая эволюция RAG — это JSON-геном по слоям, LLM-мутации с контекстом из кеша запросов, запрос с LLM судьи и обязательное ручное утверждение перед тем, как активный геном начнёт влиять на постпроцессор, роутинг и политику кеша.

Развитие

Если в RAG-системе несколько доменов (финансы, бух.учет, юриспруденция, кодинг и.т.п.) то можно разделить эволюцию по ним. Если пользователь отправил запрос, то предварительно можно выявлять к какому домену относится запрос и использовать конкретный промт из активного генома.

Сильно не пинайте

Сравнительных характеристик дать не могу, т.к. разрабатываю для себя и всего один домен узконаправленный. Серверными мощностями не располагаю(((. Все крутиться на ноутбуке.

Всем удачи в построении RAG-систем!

Контролируемая эволюция RAG-системы: оценка mcp серверов и кеширование результатов запрос-ответ