Как вы проектируете feature engineering для контекста RAG (кроме текста)?

Краткий тезис

Feature engineering для контекста RAG — это процесс извлечения и структурирования не-текстовых атрибутов документов (метаданных) и добавления их в промпт LLM в виде префиксов или структурированных блоков. Такие фичи, как длина документа, источник, свежесть, авторитетность и тип, помогают LLM лучше интерпретировать релевантность и достоверность контекста, повышая качество ответа. Проектирование включает выбор релевантных метаданных, их нормализацию, форматирование и интеграцию в контекстное окно.

1. Термин: Feature Engineering для контекста RAG

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

Зачем это нужно

• LLM не видит метаданные документа, если их явно не добавить в контекст.
• Фичи помогают модели оценить достоверность (свежий источник из Wikipedia vs старый пост на форуме), релевантность (документ из нужного домена) и специфику (FAQ vs научная статья).
• Без фичей LLM может одинаково интерпретировать документы разного качества, что снижает faithfulness (точность ответа по контексту).

2. Категории не-текстовых фичей

Все фичи можно разделить на три группы: документные, метаданные источника и вычисляемые.

Длина документа важна, потому что LLM может по-разному обрабатывать короткие и длинные чанки. Например, короткий чанк из FAQ — высокая плотность ответа, длинный чанк из учебника — может содержать лишнюю информацию.

Domain/источник позволяет LLM понять стиль и достоверность. Если документ с Wikipedia (обычно нейтральный), а другой с Reddit (субъективный), модель может учесть это при взвешивании.

Recency критична для вопросов о текущих событиях. Документ 2024 года более релевантен, чем 2019.

Authority score — rating|числовая оценка надёжности источника. Может быть основана на PageRank, цитированиях или внутреннем рейтинге (например, для корпоративной базы знаний).

Тип документа (manual, FAQ, legal, academic) помогает LLM выбрать правильный тон и формат ответа. Для юридического документа требуется точность цитирования]], для FAQ — краткость.

3. Как добавлять фичи в контекст LLM

Самый распространённый способ — префикс перед текстом документа в виде структурированной строки. Пример:

[Source: Wikipedia, Date: 2024-03-15, Authority: 0.9, Type: encyclopedia]
Текст документа...

Такой префикс помещается в контекст перед каждым чанком. LLM видит его и может использовать при генерации.

Варианты форматирования

• Plain text: Source: {domain}, Date: {date}, Type: {type}]
• JSON-like: {"source": "wikipedia", "date": "2024", "authority": 0.9}
• XML tags: <metadata><source>wikipedia</source><date>2024</date></metadata>

Выбор формата зависит от модели. Некоторые LLM (например, GPT-4) лучше понимают JSON, другие — простой текст. Рекомендуется тестировать на небольшом датасете.

Где размещать префикс

• Перед каждым чанком — наиболее надёжно, но увеличивает длину контекста.
• В начале всего контекста (например, Контекст состоит из документов: [документ1 с метаданными], [документ2...]) — экономит токены, но может быть менее точным.

4. Feature engineering для retrieval (до LLM)

Фичи можно использовать не только в контексте LLM, но и на этапе поиска (retrieval). Например:

• Гибридный поиск: комбинировать векторную близость с булевыми фильтрами по метаданным (только документы за последний год, только из Wikipedia).
• Реранжирование: после получения top-k кандидатов пересортировать их с учётом authority score или recency.
• Weighted scoring: при поиске умножать косинусную близость на вес свежести или авторитетности.

Пример кода для реранжирования:

def rerank(docs, query, weights):
    # docs: список объектов с полями text, metadata
    # weights: dict с весами для метаданных
    scored = []
    for doc in docs:
        text_score = cosine_similarity(query_embedding, doc.embedding)
        meta_score = (
            weights.get('recency', 0) * doc.metadata['recency'] +
            weights.get('authority', 0) * doc.metadata['authority']
        )
        scored.append((text_score + meta_score, doc))
    scored.sort(reverse=True)
    return [doc for _, doc in scored]

5. Примеры для разных доменов

В agentic RAG агент может динамически выбирать, какие фичи использовать, в зависимости от запроса. Например, для вопроса о последних изменениях в законе агент запросит документы с высоким recency и типом "legal".

6. Проблемы и компромиссы

• Увеличение длины контекста: каждый префикс добавляет 20–50 токенов на документ. При 10 документах это 200–500 токенов, что может превысить лимит модели.
• Шум: если фичи нерелевантны запросу, они отвлекают LLM. Например, authority score не важен для вопроса о факте из учебника.
• Доминирование метаданных: LLM может переоценить документ с высоким authority, игнорируя более точный, но менее авторитетный источник.
• Нормализация: фичи должны быть приведены к единому масштабу (например, recency в днях, authority от 0 до 1), чтобы LLM могла их интерпретировать.

Как смягчить

• Использовать ранжирование фичей — добавлять только те, которые релевантны типу запроса (определяется классификатором).
• Применять adaptive prompting: для вопросов о фактах — authority, для временных — recency.
• Тестировать на валидационном наборе с метриками faithfulness и answer relevance.

7. Инструменты и библиотеки

• LangChain: Document класс поддерживает metadata словарь, который можно передавать в промпт через PromptTemplate.
• LlamaIndex: имеет встроенную поддержку метаданных и фильтрации, а также MetadataReplacementNodePostprocessor для добавления фичей в контекст.
• Haystack: Document с полями meta, возможность кастомных ранжировщиков.
• Собственный пайплайн: на Python с использованием pandas для обработки метаданных и jinja2 для шаблонов промптов.

Пример на LangChain:

from langchain.schema import Document
from langchain.prompts import PromptTemplate

doc = Document(
    page_content="Текст документа...",
    metadata={"source": "wikipedia", "date": "2024", "authority": 0.9}
)

prompt = PromptTemplate.from_template(
    "[Source: {source}, Date: {date}, Authority: {authority}]\n{text}"
)
formatted = prompt.format(**doc.metadata, text=doc.page_content)

8. Оценка влияния фичей

Чтобы понять, улучшают ли фичи качество, нужно провести A/B тест:

1. Базовая версия: RAG без фичей (только текст).
2. Экспериментальная версия: RAG с добавлением метаданных.
3. Метрики: faithfulness (оценка соответствия ответа контексту), answer relevance, пользовательские оценки.
4. Инструменты: RAGAS, DeepEval, ручная разметка.

Ожидаемый результат: faithfulness повышается на 5–15% для вопросов, где важна достоверность (например, "какой источник?"), но может незначительно упасть для простых фактологических запросов из-за шума.

Пет-проект для закрепления

Задача Создать RAG-систему для новостного агрегатора, которая добавляет метаданные (источник, дата, рейтинг доверия) в контекст и оценить улучшение faithfulness.

Инструменты Python, LangChain, ChromaDB, OpenAI API, RAGAS.

Шаги:

1. Собрать 200 новостных статей из 4 источников (Reuters, BBC, блог, Twitter) с разными датами.
2. Разбить на чанки, сохранить в ChromaDB с метаданными: source, date, trust_score (0–1).
3. Реализовать два пайплайна:
   • Базовый: только текст чанка.
   • С фичами: префикс [Source: {source}, Date: {date}, Trust: {trust_score}].
4. Подготовить 50 вопросов, требующих учёта источника (например, "Что сказал Reuters о ...?").
5. С помощью RAGAS вычислить faithfulness для обоих пайплайнов.
6. Сравнить результаты, визуализировать.

Ожидаемый результат faithfulness для пайплайна с фичами выше на 10–20%, особенно для вопросов, где важно различать источники.

Связь с другими вопросами

Навигация

• Предыдущий: 528
• Следующий: 530
• Индекс: 00. Индекс разборов