Как заставить 8B модель работать как 70B: структурированный Chain-of-Thought и сжатие контекста для Graph RAG

Проблема: почему ваша 8B модель тупит на multi-hop вопросах?

Вы поставили Llama 3.1 8B на свой сервер, настроили RAG, и она отлично отвечает на простые вопросы. Но стоит спросить что-то вроде "Как изменилась политика компании после слияния с конкурентами в 2025 году?" - и модель выдаёт откровенную чушь. Вы думаете: "Наверное, retrieval плохой". Добавляете векторы, настраиваете чанкинг, но ничего не меняется.

Потому что проблема не в retrieval. Проблема в reasoning.

Большие модели, такие как Llama 3.3 70B, справляются с multi-hop reasoning благодаря объёму параметров. Они могут держать в контексте несколько фактов и строить логические цепочки. Маленькие модели - нет. Они теряются, забывают, путаются.

Но что, если я скажу, что можно заставить Llama 3.1 8B работать на уровне Llama 3.3 70B на задачах multi-hop QA? Без дообучения. Без апгрейда железа. С помощью двух техник: структурированного Chain-of-Thought и сжатия контекста через графы.

Решение: ломаем reasoning на куски и кормим модель по частям

Идея проста: вместо того, чтобы загружать в контекст все релевантные документы и надеяться, что модель сама разберётся, мы заставляем модель рассуждать шаг за шагом. Каждый шаг - это отдельный запрос к модели с чётко структурированным промптом и минимальным, но точным контекстом.

Как мы получаем этот точный контекст? Через граф знаний. Если вы ещё не знакомы с Graph RAG, рекомендую сначала прочитать практическое руководство по Graph RAG. Вкратце: мы извлекаем из документов сущности и связи, строим граф, и затем используем этот граф для навигации по информации.

Комбинируя граф для сжатия контекста и структурированный Chain-of-Thought для reasoning, мы получаем систему, где малая модель выполняет сложные логические выводы.

1 Подготовка графа знаний: не просто векторы

Первый шаг - построить граф знаний из ваших документов. Это можно сделать с помощью локальных LLM, как описано в этой статье. Используйте, например, Llama 3.1 8B для извлечения сущностей и отношений. Да, эта же модель, которую мы потом будем использовать для QA.

Код для извлечения сущностей:

from llama_cpp import Llama
import json

# Загружаем модель для извлечения сущностей
llm = Llama(
    model_path="./models/llama-3.1-8b-instruct.Q4_K_M.gguf",
    n_ctx=8192,
    n_threads=8,
)

def extract_entities(text):
    prompt = f"""Текст: {text}

    Извлеки все сущности и их отношения в формате JSON. Сущности: люди, организации, даты, события, понятия. Отношения: тип связи между сущностями.

    Формат:
    {{
      "entities": ["сущность1", "сущность2"],
      "relations": [["сущность1", "тип_связи", "сущность2"]]
    }}"""
    
    response = llm(prompt, max_tokens=512)
    # Парсим JSON из ответа
    # ... обработка ...
    return result

# Применяем к каждому документу
documents = ["..."]  # ваши документы
graph = {"nodes": set(), "edges": []}
for doc in documents:
    result = extract_entities(doc)
    graph["nodes"].update(result["entities"])
    graph["edges"].extend(result["relations"])

Теперь у вас есть граф. Но это сырой граф. Его нужно очистить и, возможно, обогатить. Например, объединить синонимы.

2 Структурированный Chain-of-Thought: заставляем модель думать вслух по шаблону

Обычный Chain-of-Thought - это когда модель пишет рассуждение в свободной форме. Но маленькие модели часто сбиваются с пути. Поэтому мы структурируем его.

Мы определяем шаблон, по которому модель должна рассуждать. Например, для multi-hop QA:

1. Разбор вопроса: выделить ключевые сущности и отношения.
2. Поиск в графе: найти соответствующие узлы и пути.
3. Сбор фактов: извлечь связанные утверждения из документов.
4. Логический вывод: объединить факты для ответа.

Каждый шаг - отдельный вызов модели. Промпт для каждого шага чётко определяет задачу и формат ответа.

Пример промпта для шага 1:

def parse_question(question):
    prompt = f"""Вопрос: {question}

    Разбери вопрос на составные части.
    Выдели все упомянутые сущности (имена, организации, даты и т.д.).
    Определи, какие отношения между ними спрашиваются.

    Ответ в формате JSON:
    {{
      "entities": ["...", "..."],
      "relations": ["...", "..."],
      "question_type": "comparison|cause_effect|timeline|..."
    }}"""
    
    response = llm(prompt, max_tokens=256)
    return json.loads(response["choices"][0]["text"])

Таким образом, мы разбиваем сложный reasoning на последовательность простых шагов, каждый из которых посилен для малой модели.

3 Сжатие контекста через обход графа: подаём только нужное

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

После того, как мы извлекли сущности из вопроса, мы ищем их в графе. Затем мы обходим граф от этих узлов, чтобы найти связанные сущности и соответствующий текст.

Реализация обхода графа:

import networkx as nx

# Создаем граф из наших данных
G = nx.Graph()
G.add_nodes_from(graph["nodes"])
for edge in graph["edges"]:
    G.add_edge(edge[0], edge[1], relation=edge[2])

def get_relevant_texts(entities, max_hops=2):
    relevant_nodes = set()
    for entity in entities:
        if entity in G:
            # Обходим граф на глубину max_hops
            for _, neighbor in nx.bfs_edges(G, source=entity, depth_limit=max_hops):
                relevant_nodes.add(neighbor)
    
    # Теперь находим текстовые фрагменты, связанные с этими узлами
    # Предположим, у нас есть обратный индекс: узел -> список текстовых чанков
    texts = []
    for node in relevant_nodes:
        if node in index:
            texts.extend(index[node])
    return texts[:5]  # Ограничиваем количество

Таким образом, для каждого шага Chain-of-Thought мы подаём только небольшой, но релевантный контекст. Это снижает нагрузку на модель и уменьшает шум.

Этот подход похож на KET-RAG и LightRAG. Если хотите глубже, посмотрите сравнение Graph RAG с векторным поиском.

4 Интеграция в RAG-систему: собираем всё вместе

Теперь объединим все части в единый пайплайн.

1. Пользователь задаёт вопрос.
2. Парсим вопрос с помощью структурированного CoT (шаг 1).
3. Используем извлечённые сущности для поиска в графе и получения релевантных текстов.
4. Для каждого следующего шага Chain-of-Thought используем предыдущие результаты и новый контекст из графа.
5. В конце, модель формирует окончательный ответ.

Код интеграции:

def answer_question(question):
    # Шаг 1: Разбор вопроса
    parsed = parse_question(question)
    
    # Шаг 2: Поиск начального контекста
    context_texts = get_relevant_texts(parsed["entities"])
    
    # Шаг 3: Chain-of-Thought шаги
    # Шаг 3.1: Уточнение фактов
    facts = []
    for text in context_texts:
        prompt = f"""Контекст: {text}
        Вопрос: {question}
        Выдели факты, которые относятся к вопросу.
        """
        response = llm(prompt, max_tokens=128)
        facts.append(response["choices"][0]["text"])
    
    # Шаг 3.2: Логический вывод
    reasoning_prompt = f"""Вопрос: {question}
    Факты:
    {chr(10).join(facts)}
    
    На основе этих фактов, ответь на вопрос. Объясни рассуждение.
    """
    final_response = llm(reasoning_prompt, max_tokens=512)
    
    return final_response["choices"][0]["text"]

Это упрощённый пример. В реальности шагов может быть больше, и нужно обрабатывать ошибки.

Почему это работает: теория и практика

Структурированный Chain-of-Thought решает проблему reasoning, разбивая её на подзадачи, которые малая модель может решить. Сжатие контекста через граф решает проблему перегруженности контекста - модель получает только нужную информацию.

На практике, этот подход может улучшить точность multi-hop QA на 30-40% для моделей размером 8B, приближая их к показателям 70B моделей. И всё это без дообучения.

Данные приблизительные, но показывают потенциал. Вы экономите в 12 раз на ресурсах (8B vs 70B), а точность почти такая же.

Ошибки, которые всё испортят

• Слишком сложный граф. Если граф огромный, обход может быть медленным. Ограничивайте глубину обхода и используйте эвристики для выбора путей.
• Неточное извлечение сущностей. Если граф построен плохо, весь пайплайн рухнет. Проверяйте качество извлечения на подмножестве документов.
• Жёсткие шаблоны Chain-of-Thought. Если шаблон не подходит для типа вопроса, модель может дать сбой. Добавьте классификатор типа вопроса, чтобы выбирать подходящий шаблон.
• Игнорирование ограничений контекста. Даже с сжатием, если текст слишком длинный, модель может его не обработать. Используйте суммаризацию для длинных фрагментов. Как бороться с длинными документами, читайте в статье про анализ длинных документов.

И помните: этот метод не панацея. Он особенно хорош для multi-hop QA, где требуется reasoning. Для простых фактологических вопросов обычный RAG может работать лучше.

Что дальше? Эксперименты и оптимизации

Попробуйте разные стратегии обхода графа. Например, обратный обход, как в Dreaming Engine, может улучшить покрытие контекста.

Экспериментируйте с шаблонами Chain-of-Thought. Иногда добавление шага "проверка согласованности фактов" может повысить точность.

И если вы хотите масштабировать такую систему, изучите гайд по масштабированию RAG.

Мой прогноз: к 2027 году такие гибридные методы станут стандартом для production RAG-систем. Потому что они дают точность больших моделей по цене малых.

И последнее: если вам нужно запустить такую систему на слабом железе, например, на GTX 1650, смотрите голосовой агент с RAG на GTX 1650. Там есть трюки для оптимизации памяти.

Удачи в экспериментах! И помните: малые модели - не игрушки. При правильном подходе они могут соперничать с гигантами.

Подписаться на канал