В статье рассматриваются теоретические выкладки как возможно эволюционировать RAG-систему на одном домене (документация 1С). Эволюцию можно расширить на использование нескольких доменов (финансы, бух.учет, юриспруденция, кодинг и.т.п.)
Статические промпты в RAG быстро перестают соответствовать реальным запросам. в статье описана реализация механизма контролируемой эволюции: модель предлагает варианты настроек («геномы»), судья оценивает их на запросах и ставит среднюю оценку по выборке, а в прод попадает только то, что администратор явно утвердил. Ниже — идея, три слоя пайплайна и фрагменты кода из реализации.
В существующих пайплайнах часто используют модель (LLM) судью которая оценивает только один запрос-ответ. А что делать если уже накоплен массив данных запрос-ответов? Где узкое место в системных промтах когда пользователь задает вопросы системе, как лучше дать оценку что должно попадать в кеш, а что нет?
Эволюция RAG здесь — не автономный агент, а лабораторный контур в админке: генерация кандидатов, оценка.
В примере будем рассматривать эволюцию MCP-сервера documents1c (tools docsearch) (RAG-система для документации 1С: архитектура MCP-серверов documents1c и metadata1c) и попробуем улучшить системный промт в пайплайне постобработки, который летит в рассуждающую модель.
Также рассмотрим как улучшить параметры попадания в кеш запрос-ответов.
Три слоя — три независимых «генома»
Каждый слой хранится отдельной записью в БД с полем layer:
Слой | Роль | Эффект для пользователя |
|---|---|---|
postprocess | Системные инструкции и параметры постобработки | Текст и структура ответа |
routing | Классификатор | Настройка модели под класс вопроса до финальной сборки |
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 | Промпт классификатора и набор профилей по типам запроса ( | Подстройка инструкций модели под тип вопроса до постобработки |
cache_policy | Числовые/логические пороги admission (источники, предупреждения, supportedness, …) | Какие ответы попадают в кеш при повторных запросах; на «живой» текст ответа не влияет |
Цикл эволюции
generate_mutations() → eval_genome() → promote_best() → [ручной approve в UI] → active
Генерация: LLM предлагает N вариантов генома с обоснованием изменений
Оценка: LLM судья оценивает каждый вариант по 4 критериям (полнота, точность, источники, краткость) на наборе запросов, выставляет оценку 0–10
Promote: лучший вариант получает статус
pending_approvalApprove: администратор вручную нажимает «Применить»
Статусы генома
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
Поле | Смысл |
|---|---|
| Главная инструкция рассуждающей модели: как собирать итоговый ответ из чанков (тон, язык, требования к точности и цитированию). |
| Инструкция для режима слияния частичных ответов в один связный текст без дублей. |
| Сколько фрагментов документации подставлять в контекст постобработки. |
| Верхняя граница длины ответа модели. |
| Политика ссылок на источники (в дефолте, например, |
| Предпочтительная детализация ответа (в дефолте |
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
Часть генома | Смысл |
|---|---|
| Текст для модели, которая по пользовательскому запросу выбирает один |
| Словарь «тип → профиль». У каждого типа свой |
Для 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
Поле | Смысл |
|---|---|
| Порог среднего числового |
| Требовать ли наличие источников для допуска в кеш. |
| Минимум элементов в списке |
| Запрещать кеширование, если список |
| Минимальное количество пунктов в |
Оценка запросов
На каждый сгенерированный гипотетический запрос в геноме возвращается пара (итоговый_score, diagnostics). После успешного прогона у генома со статусом candidate выставляется evaluated, в score генома попадает среднее значение.
Оценка геномов
В конце оценивается каждый геном и принимается решение какой активировать.
Итог: на postprocess и routing эволюция меняет преимущественно тексты инструкций и числовые параметры поведения модели; на cache_policy — только правила, разрешать ли кешировать уже готовый ответ.
Заключение
Контролируемая эволюция RAG — это JSON-геном по слоям, LLM-мутации с контекстом из кеша запросов, запрос с LLM судьи и обязательное ручное утверждение перед тем, как активный геном начнёт влиять на постпроцессор, роутинг и политику кеша.
Развитие
Если в RAG-системе несколько доменов (финансы, бух.учет, юриспруденция, кодинг и.т.п.) то можно разделить эволюцию по ним. Если пользователь отправил запрос, то предварительно можно выявлять к какому домену относится запрос и использовать конкретный промт из активного генома.
Сильно не пинайте
Сравнительных характеристик дать не могу, т.к. разрабатываю для себя и всего один домен узконаправленный. Серверными мощностями не располагаю(((. Все крутиться на ноутбуке.
Всем удачи в построении RAG-систем!
