Хочу, чтобы система со временем генерировала контент лучше — без постоянного fine-tuning LLM. Что выбрать?

Строю конвейер на n8n: GPT API генерирует контент, после публикации у каждого результата появляются реальные метрики. Задача в общем виде: есть база — много объектов + текст/описание + числовые метрики результата. Хочу, чтобы модель со временем генерировала более удачные результаты, опираясь на паттерны из прошлого — без переобучения весов самой LLM. Fine-tuning для задачи с постоянно обновляющимися данными не подходит: дорого, долго, и знания быстро устаревают.

Пока рассматриваю несколько подходов: 1. RAG Перед генерацией система превращает прошлые объекты в векторы — по сути, координаты смысла текста — и находит среди них ближайшие к новой задаче. Как будто ищешь в архиве: «Было ли у меня что-то похожее?» Но здесь есть ловушка: похожим по смыслу может оказаться как успешный кейс, так и полный провал. Смысловая близость сама по себе ничего не говорит о результате. Поэтому логично ранжировать не только по чистой похожести, а учитывать ещё и то, насколько хорошо этот пример реально сработал по метрикам. 2. Hybrid Search + Reranking Обычный векторный поиск по смыслу иногда промахивается: находит что-то похожее по теме, но не совсем то. Hybrid Search решает это, добавляя параллельно точный поиск по ключевым словам, категории, формату и другим параметрам — а затем объединяет результаты обоих поисков. После этого в дело вступает reranking: отдельная небольшая модель, которая берёт уже отобранный пул кандидатов и внимательнее сравнивает каждого с новой задачей. Это точнее, чем обычный поиск по похожести, но и медленнее — поэтому reranking применяется не ко всей базе, а только к небольшому числу уже найденных кандидатов. По сути, это более точная двухступенчатая надстройка над обычным RAG, а не отдельный самостоятельный метод. 3. SQL-аналитика Просто анализировать историю и находить закономерности: — какие hooks работают лучше; — какие форматы дают лучший результат; — какая длина эффективнее; — какие структуры контента чаще заходят. А затем передавать эти выводы LLM перед генерацией. 4. ML scoring — отдельная модель-судья, например XGBoost Смысл простой: LLM генерирует не один вариант, а сразу несколько — как черновики. Дальше в дело вступает отдельная небольшая ML-модель. Это не сама LLM, а более лёгкий классический алгоритм машинного обучения. Она работает с числовыми признаками объекта и контента: длина, формат, категория и т.д. Её обучают на исторических данных: «Вот этот вариант получил хороший результат, а вот этот — плохой». Такую модель намного дешевле и быстрее переобучать на свежих данных, чем саму LLM. В итоге получается примерно так: LLM генерирует несколько вариантов → ML-модель оценивает их → выбираем самый перспективный. Минус в том, что для нормальной работы такой модели сначала нужно накопить приличное количество примеров с известным результатом.

Я не планирую внедрять всё это сразу. Сейчас пытаюсь понять, какой подход выбрать первым и есть ли смысл комбинировать 2–3 из них. Например: RAG + метрики? SQL + RAG? Сразу ML scoring? Или вообще начать с простой аналитики и усложнять систему по мере накопления данных? Кто строил что-то похожее с обратной связью по реальным метрикам — с чего бы вы начали и почему? Го обсудим 👇