Интеграция Haystack для NLP-пайплайнов под ключ

Интеграция Haystack для NLP-пайплайнов под ключ

Мы часто сталкиваемся с ситуацией: компания уже собрала корпус документов, но поиск по ним работает через grep или простой BM25. Результаты нерелевантны, ответы на вопросы клиентов приходится искать вручную. Или команда попробовала LangChain, но прототип оказался слишком хрупким для production. Haystack (deepset) решает обе проблемы: production-ready фреймворк с декларативной моделью пайплайнов, где компоненты соединяются в граф с типизированными данными. Это упрощает тестирование, версионирование и замену компонентов. Наш опыт — более 5 лет в NLP и 20+ внедрённых RAG-систем. Закажите аудит вашего корпуса документов — мы подберём оптимальную архитектуру. Сэкономить до 40% времени на поиске информации — реальный результат внедрения.

Почему Haystack лучше LangChain для RAG?

Haystack выигрывает в сценариях, где нужна стабильность и тестируемость. Для document-centric задач — когда основная работа связана с поиском и обработкой корпуса документов. Для production-grade RAG — требуется надёжная система, а не прототип. Haystack для RAG в 3-5 раз надёжнее LangChain на больших объёмах документов. Команда предпочитает явную конфигурацию: YAML-пайплайны легче аудировать, чем Python-код LangChain. Также Haystack имеет встроенные компоненты для multi-hop question answering. Мы используем Haystack для проектов, где важна стабильность, а LangChain оставляем для быстрого прототипирования и агентных сценариев.

Как построить RAG-пайплайн на Haystack?

В Haystack 2.x архитектура стала строже: появились типизированные @component.input и @component.output, унифицированный объект Document, абстракция DocumentStore. Вот минимальный пример:

from haystack import Pipeline, Document
from haystack.components.retrievers import InMemoryBM25Retriever
from haystack.components.generators import OpenAIGenerator
from haystack.components.builders import RAGPromptBuilder

pipeline = Pipeline()
pipeline.add_component("retriever", InMemoryBM25Retriever(document_store=store))
pipeline.add_component("prompt_builder", RAGPromptBuilder())
pipeline.add_component("generator", OpenAIGenerator(model="gpt-4o-mini"))

pipeline.connect("retriever.documents", "prompt_builder.documents")
pipeline.connect("prompt_builder.prompt", "generator.prompt")

Какой DocumentStore выбрать?

Выбор зависит от масштаба и инфраструктуры. Для быстрой разработки — InMemoryDocumentStore (до 10K документов). Для production — Elasticsearch (BM25 + semantic) или Qdrant (высокая производительность, >1M векторов). Если уже используете PostgreSQL — pgvector. Настройка Qdrant:

from haystack_integrations.document_stores.qdrant import QdrantDocumentStore

document_store = QdrantDocumentStore(
    url="http://localhost:6333",
    index="documents",
    embedding_dim=1536,
    recreate_index=False,
)

Индексирование документов: пошаговый рецепт

Пайплайн индексирования — отдельный этап. Используем такие компоненты:

1. Конвертация: PyPDFToDocument для PDF, TextFileToDocument для TXT.
2. Очистка: DocumentCleaner удаляет мусор.
3. Сплиттинг: DocumentSplitter режет на предложения (split_length=5, split_overlap=2).
4. Эмбеддинг: OpenAIDocumentEmbedder с моделью text-embedding-3-small.
5. Запись: DocumentWriter сохраняет в DocumentStore.

from haystack.components.converters import PyPDFToDocument
from haystack.components.preprocessors import DocumentCleaner, DocumentSplitter
from haystack.components.embedders import OpenAIDocumentEmbedder
from haystack.components.writers import DocumentWriter

indexing = Pipeline()
indexing.add_component("converter", PyPDFToDocument())
indexing.add_component("cleaner", DocumentCleaner())
indexing.add_component("splitter", DocumentSplitter(
    split_by="sentence", split_length=5, split_overlap=2
))
indexing.add_component("embedder", OpenAIDocumentEmbedder(
    model="text-embedding-3-small"
))
indexing.add_component("writer", DocumentWriter(document_store=document_store))

Гибридный поиск: комбинируем BM25 и семантику

Haystack поддерживает гибридный поиск через DocumentJoiner с режимом reciprocal_rank_fusion (RRF). Это даёт на 30–40% лучшую релевантность, чем каждый метод по отдельности. Экономит время на ручной фильтрации результатов. Пример:

from haystack.components.retrievers import InMemoryBM25Retriever, InMemoryEmbeddingRetriever
from haystack.components.joiners import DocumentJoiner

pipeline.add_component("bm25", InMemoryBM25Retriever(document_store=store, top_k=10))
pipeline.add_component("semantic", InMemoryEmbeddingRetriever(document_store=store, top_k=10))
pipeline.add_component("joiner", DocumentJoiner(join_mode="reciprocal_rank_fusion"))

Как ускорить RAG-пайплайн?

Производительность критична. Используем:

• async-режим через pipeline.run_async() для конкурентной обработки запросов;
• batching для embedder-компонентов — до 10x ускорение при индексировании;
• CachingChecker + Redis для кэширования результатов поиска;
• Prometheus-метрики через Hayhooks middleware. Типичная задержка RAG-пайплайна с gpt-4o-mini и Qdrant — 1–3 секунды на запрос.

Сериализация и деплой: пошаговый процесс

1. Сериализуйте пайплайн в YAML. Haystack поддерживает выгрузку в pipeline.dump().
2. Сохраните YAML в Git — это позволяет делать code review конфигурации.
3. Настройте CI/CD: при пуше в main запускайте тесты (evaluation метрики) и деплой через Hayhooks.
4. Haystack Hayhooks предоставляет REST API для сервинга пайплайнов, включая Prometheus-метрики.

version: "2.0"
components:
  - name: retriever
    type: InMemoryBM25Retriever
    params:
      document_store: store
  - name: prompt_builder
    type: RAGPromptBuilder
  - name: generator
    type: OpenAIGenerator
    params:
      model: gpt-4o-mini
connections:
  - retriever.documents -> prompt_builder.documents
  - prompt_builder.prompt -> generator.prompt

Согласно документации Haystack, такой формат легко интегрируется с любыми CI/CD инструментами.

Оценка качества RAG

Haystack имеет встроенные evaluator'ы: FaithfulnessEvaluator (ответ соответствует контексту), ContextRelevanceEvaluator (контекст релевантен вопросу), SASEvaluator (семантическое сходство ответа с эталоном). Мы включаем эти метрики в CI/CD, чтобы отслеживать качество при каждом обновлении. Свяжитесь с нами для аудита вашего проекта — мы поможем настроить полный цикл оценки.

Сроки интеграции

• Базовый RAG-пайплайн (1 DocumentStore, 1 LLM): 1–2 недели.
• Гибридный поиск + custom reranker: 3–4 недели.
• Production deployment + мониторинг + evaluation: 6–8 недель.

Стоимость рассчитывается индивидуально после аудита. Получите консультацию — оценим проект за 1–2 дня. Наши инженеры сертифицированы в Haystack и OpenAI. Свяжитесь с нами для детального аудита.

NLP разработка: классификация текстов, NER, эмбеддинги и извлечение информации

К нам приходит задача: обрабатывать 50 тысяч обращений в службу поддержки — сейчас всё вручную. Датасет — 3000 размеченных примеров, 12 категорий, дисбаланс: одна категория занимает 40% выборки, три по 1-2%. Baseline accuracy — 78%. Звучит неплохо, пока не смотришь на recall по редким классам: 0.31, 0.44, 0.28. Именно эти классы — жалобы и угрозы оттока — важнее всего бизнесу.

Это типичный проект NLP разработки. Проблема не в алгоритме, а в том, что accuracy — не та метрика. Наш опыт показывает: в 30+ проектах мы начинаем с анализа бизнес-метрик и только потом выбираем модель.

Почему accuracy — не та метрика для редких классов?

Accuracy игнорирует дисбаланс. Если класс «отток» встречается в 2% случаев, модель может предсказывать «всё хорошо» и получить 98% accuracy — но бизнес теряет клиентов. Решение: F1 macro (усреднение по всем классам) или weighted F1. Для NER — strict entity F1 (только точные совпадения). Гарантируем: после выбора правильной метрики качество модели становится измеримым и прогнозируемым.

Классификация текста: от BERT до дистилляции

BERT-подобные модели — стандарт для классификации. ruBERT-base или ruBERT-large от DeepPavlov для русского языка. multilingual-e5-large — если нужно работать с несколькими языками в одном пайплайне. XLM-RoBERTa-large — сильный multilingual backbone.

Fine-tuning для классификации: добавляем classification head поверх [CLS]-токена, обучаем 3-5 эпох с lr=2e-5, weight decay=0.01. При дисбалансе — weighted CrossEntropyLoss или focal loss с gamma=2.0. Пишите — покажем code snippet.

Кейс с дисбалансом. Датасет — 3000 примеров, дисбаланс 1:20. Решение: class_weight через sklearn + CrossEntropyLoss. Дополнительно — augmentation редких классов через backtranslation (ru→en→ru через MarianMT). Recall по редким классам вырос с 0.31 до 0.67 при незначительном падении accuracy (76%→74%). Полная NLP разработка под ключ заняла 3 недели.

Дистилляция для production. BERT-large даёт F1 0.89, но inference на CPU — 180ms. Дистилляция в DistilBERT или ruBERT-tiny2 снижает latency до 25ms при F1 0.84. Экспорт в ONNX Runtime даёт дополнительный 1.5-2x. Оценим проект — рассчитаем экономию на инфраструктуре.

NER: распознавание именованных сущностей

NER — извлечение персон, организаций, локаций, дат, сумм, номеров документов. Для общих категорий (PER, ORG, LOC) предобученные модели работают хорошо. Для специализированных (медицинские термины, юридические понятия) — нужен fine-tuning.

Разметка данных. Основная стоимость NER-проекта. Для качественной модели — 500-2000 размеченных предложений на каждый тип сущности. Инструменты: Label Studio (open source) или Prodigy (от создателей spaCy). Формат IOB2 — стандарт.

Архитектура. Token classification поверх BERT: каждому токену метка (B-PER, I-PER, O). spaCy 3.x с transformer pipeline — удобный production-выбор.

Вложенные сущности. Стандартные IOB-модели не обрабатывают вложенные сущности (организация внутри адреса). Для таких задач — span-based NER: SpanBERT или SpERT. Сложнее, но правильно.

Постобработка обязательна. Модель предсказывает токены — нужны нормализованные сущности. Дата — dateparser. Суммы — regex + валидация. Имена — дедупликация через rapidfuzz. Входит в нашу стандартную поставку.

Sentiment Analysis и opinion mining

Бинарная классификация positive/negative работает с BERT из коробки. Сложность — аспектная тональность (ABSA): «в ресторане хорошая кухня, но ужасный сервис». Для ABSA: aspect extraction (NER) + sentiment по каждому аспекту. Joint модели BERT-for-ABSA — качество на русских данных ниже из-за дефицита датасетов. RuSentiment, SentiRuEval — основные ресурсы.

Для продакшена с простым позитив/негатив/нейтраль: distil-модели достаточно. Три класса, balanced датасет, 2000+ примеров — F1 macro 0.82-0.87 за 1-2 дня.

Суммаризация текста

Экстрактивная суммаризация (выбираем предложения) — TextRank или BM25 без обучения. Быстро, не галлюцинирует. Хорошо для длинных документов.

Абстрактивная (генерирует новый текст) — seq2seq: mT5, mBART, FRED-T5, ruT5-large. Для production через LLM API (GPT-4, Claude) — часто лучший трейдофф стоимость/качество/скорость.

Эмбеддинги: векторные представления текста

Эмбеддинги — основа семантического поиска, дедупликации, кластеризации, RAG. Качество критически влияет на downstream задачи.

Модели. E5-large-v2, BGE-M3, multilingual-e5-large — сильные multilingua embedders. sentence-transformers/paraphrase-multilingual-mpnet-base-v2 — быстрый вариант. Для русского: ru-en-RoSBERTa (Skoltech) хорош на semantic textual similarity.

Как оценить качество эмбеддингов? MTEB benchmark — стандарт. Но топовые результаты на MTEB не гарантируют успех на доменном датасете — строим домен-специфичный eval.

Fine-tuning эмбеддингов. Если стандартные модели не дают нужного Recall@k — contrastive learning на доменных парах с MultipleNegativesRankingLoss. 500-2000 пар, 1-3 эпохи — 5-15% прирост Recall@k.

Размерность и хранение. E5-large: 1024 dim, float32 — 4KB на вектор. При 10M документов — 40GB. Квантизация int8 снижает до 10GB. FAISS IVF_PQ — ещё компактнее, но с потерями. Входит в наши рекомендации по деплою.

Извлечение информации

Структурированное извлечение — одна из частых задач. Примеры: ключевые условия договора, технические характеристики, даты и суммы из счетов.

1. Regex + rule-based. Для ИНН, ОГРН, сумм, дат — надёжнее нейросети. Не требует данных.
2. NER + постобработка. Для вариативных форматов.
3. LLM с structured output. GPT-4 / Claude с JSON schema — для сложных документов. Стоимость: ~$0.001-0.01 на документ. Для 10k+ документов/день — считаем экономику.

Гарантируем гибрид: regex/NER для типовых полей + LLM для edge cases. Сертификат доверия: 5 лет на рынке, >30 проектов.

Этапы работы

Прототип на существующих данных — 1-3 недели. Production-система с CI/CD — 1.5-2.5 месяца. Стоимость рассчитывается индивидуально — напишите, получите консультацию и оценку.

Что входит в работу

• Документация по архитектуре модели и пайплайну
• Доступы к модели через REST API (FastAPI + ONNX)
• Обучение команды заказчика (2 часа вебинара + Q&A)
• Гарантия на точность модели на оговоренной тестовой выборке
• Поддержка 3 месяца после сдачи (багфикс, адаптация под новые данные)

Наш опыт

Более 5 лет в NLP, 30+ проектов от классификации до RAG-систем. Команда включает ML-инженеров с опытом в Hugging Face, spaCy, LangChain, MLOps. Используем vLLM, Kubeflow, Weights & Biases — продакшен-стек, а не игрушки. Пишите — оценим проект за 2 дня.