Основанное на фактах рассуждение LLM: новые подходы к обучению моделей

Я — Денис Шохирев, Enterprise AI architect из Эрлангена, Германия. В DennisCraft AI Studio я вывожу в продакшн B2B-агентов на стеке Claude, Supabase, n8n, Doppler, Postgres. За последние полгода поставил в прод 14 AI-агентов для DACH-клиентов. Почти каждый релиз — борьба не с инфраструктурой, а с тем, чтобы LLM действовал по фактам, а не "галлюцинировал".

Проблема: LLM не умеют обосновывать выводы

В продакшн-среде, особенно в логистике и финтехе, ошибки LLM из-за нестыковок с реальными данными приводят к штрафам, аудиторским отказам или прямым убыткам. В одной из последних поставок агент на базе Claude Code дважды неверно рассчитал маршруты из-за устаревших представлений об инфраструктуре — хотя свежие данные были в Postgres. В результате я внедрил отдельный слой проверки обоснованности: агент обязан ссылаться на конкретные строки из БД или API-ответы.

Почему классический fine-tuning не решает задачу

Обычное дообучение LLM по домену (fine-tuning) помогает только частично. Модель начинает "говорить в терминах клиента", но не перестает выдумывать детали или строить выводы на устаревших паттернах. Это подтверждается не только практикой: в отчёте Anthropic "Red Teaming Language Models with Language Models" (2023, arxiv.org/abs/2306.10014) отмечалось, что даже после дообучения на специализированных датасетах частота "галлюцинаций" упала лишь на 17%.

В моём опыте, даже с дообучением на 15 000+ строках логистических кейсов, Claude продолжал делать выводы, не опираясь на явные данные.

Новые подходы: обучение на цепочках обоснования

Step-wise reasoning (обучение по шагам)

Чтобы агент не просто отвечал, а показывал путь к выводу, я стал использовать цепочки: в качестве таргета при обучении — не только ответ, но и подробная последовательность шагов ("reasoning traces"). Пример:

# Пример входа для обучения
{
  "query": "Может ли грузовик X проехать по маршруту A-B-C?",
  "context": "...данные о дорогах...",
  "reasoning_steps": [
    "Шаг 1: Проверить разрешённую массу на участке A-B — 35 т.",
    "Шаг 2: Масса грузовика X — 32 т, прохождение разрешено.",
    "Шаг 3: Проверить ограничения по высоте на B-C — 4.2 м.",
    "Шаг 4: Высота X — 4.1 м, прохождение разрешено."
  ],
  "final_answer": "Да, маршрут проходим для X."
}

Такие цепочки я формирую вручную для наиболее частых сценариев и использую их для обучения или RAG (retrieval augmented generation). В n8n легко интегрировать отдельный шаг, который требует от LLM явно выписывать reasoning_steps, а затем валидировать их с помощью Python-скрипта.

Контроль ссылок на источники

В продакшне я ввожу жёсткое правило: каждое утверждение агента должно быть связано с конкретным источником — строкой в БД, API ответом, документом. Это реализую через шаблоны prompt-ов и валидацию на этапе postprocessing:

def validate_sources(response, db_records):
    for step in response["reasoning_steps"]:
        if not any(record in step for record in db_records):
            return False
    return True

В одном из кейсов с финтех-агентом процент "необоснованных" ответов снизился с 24% до 6% после такой доработки pipeline.

RAG и верификация: реальный прирост качества

Retrieval Augmented Generation (RAG) позволяет LLM отвечать только на основе "подсунутых" данных. Я строю пайплайн: агент получает query, через n8n или Supabase вытягивает актуальные данные, затем prompt явно требует ссылаться на них. После — второй слой верификации: скрипт на Python сверяет, что все упомянутые факты реально присутствуют в исходном payload.

Ограничения: даже в RAG возможны "галлюцинации", если prompt не требует явно выписывать источники. В одном из тестов на 500 запросах к промышленному агенту Claude Code допустил 18 ложных "фактов" даже при корректном retrieval, если не был включен шаблон с обязательной ссылкой ("cite the source for each claim").

Сравнение подходов в обучении "обоснованных" LLM

Подход	Плюсы	Минусы
Fine-tuning на доменных данных	Быстро, дешево, частично снижает ошибки	Не гарантирует ссылку на факты, "галлюцинации" остаются
Обучение на цепочках reasoning	Требует LLM показывать шаги, повышает прозрачность	Дороже по сбору данных, сложнее для редких кейсов
RAG + валидация источников	Максимальная связь с актуальными данными, снижает риски в проде	Усложняет pipeline, требует контроля шаблонов и постобработки

FAQ

Можно ли полностью избавиться от "галлюцинаций"?

На практике — нет. Но можно резко снизить их частоту комбинацией RAG, шаблонов и валидации.

Стоит ли дообучать LLM на своих кейсах?

Да, если ваши данные уникальны. Но без контроля reasoning это только частичное решение.

Какие инструменты для пост-валидации наиболее удобны?

В моём опыте — Python-скрипты с semgrep для кода, SQL-запросы для проверки ссылок, bandit/gitleaks для аудита конфигов.

Сколько времени занимает внедрение цепочек reasoning?

Для типовых сценариев сбор и разметка — 1–2 недели. Для сложных кейсов — до месяца.

Как контролировать обновление источников данных?

Я использую Supabase triggers и расписания в n8n для автоматической актуализации информации.

На каком этапе вашего пайплайна LLM чаще всего "теряет связь" с базой — при генерации, retrieval или валидации? Откровенно интересно. Провожу бесплатный 30-мин аудит стека для DACH-компаний, выводящих AI в продакшн. Пишите в LinkedIn или на @ger_dennis_ai.