Автоматичне побудування графа знань із текстів під ключ

Проектуємо та впроваджуємо системи штучного інтелекту: від прототипу до production-ready рішення. Наша команда поєднує експертизу в машинному навчанні, дата-інжинірингу та MLOps, щоб AI працював не в лабораторії, а в реальному бізнесі.
Показано 1 з 1Усі 1564 послуг
Автоматичне побудування графа знань із текстів під ключ
Складний
~1-2 тижні
Часті запитання

Напрямки AI-розробки

Етапи розробки AI-рішення

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1348
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1247
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    949
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1183
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    642
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    921

Вступ

Типове завдання: у вас є тисячі документів — звіти, новини, внутрішні регламенти. Витягти з них усі згадки компаній, персон, продуктів та їх взаємозв'язки вручну — тижні людино-годин. Навіть NER-модель дасть лише список сутностей, але не відповість на запитання «Хто з керівників конкуруючої компанії раніше працював у нашому холдингу?» Для цього потрібен граф знань. Зв'яжіться з нами — ми проаналізуємо ваш корпус і запропонуємо оптимальне рішення.

Ми автоматично будуємо граф знань із корпусу текстів: видобуваємо сутності, відношення та будуємо онтологію. Це перетворює неструктуровані дані на навіговану базу знань для GraphRAG, семантичного пошуку та аналітики. Наш pipeline включає NER, relation extraction, coreference resolution та entity linking — все в єдиному процесі. Отримайте консультацію та дізнайтеся, як граф знань покращить вашу аналітику. Економія часу аналізу — до 80%, зниження витрат на ручну обробку — у 3–5 разів.

Як будується граф знань автоматично?

Процес складається з чотирьох послідовних етапів, кожен з яких вирішує своє завдання.

Entity Extraction

Named Entity Recognition з розширеним набором типів: PERSON, ORGANIZATION, LOCATION, PRODUCT, EVENT, DATE, MONEY, ROLE. Ми використовуємо fine-tuned BERT-large, який досягає F1=0.93 на CoNLL-2003. Для адаптації під домен застосовуємо fine-tuning з LoRA, що знижує вимоги до обчислювальних ресурсів і прискорює навчання.

Relation Extraction

Визначення типу зв'язку між парами сутностей в одному реченні або параграфі. REBEL (Babelscape/rebel-large) — найкращий відкритий інструмент для end-to-end виділення трійок. Він на 15% точніший, ніж pipeline-підхід (NER + класифікатор відношень), і працює швидше: latency p99 становить ~200 мс на одному GPU.

Coreference Resolution

Розв'язання анафор: «Газпром… Компанія… Вона…» — всі вказують на одну сутність. Використовуємо NeuralCoref зі словником промислових найменувань, що знижує кількість дублів на 40%.

Entity Linking

Прив'язка згаданих сутностей до канонічних записів у базі (Wikidata, DBpedia). Наприклад, «ВТБ», «Банк ВТБ» та «VTB Bank» стають одним вузлом графа. Точність лінкування — 88% за TAC KBP (TAC KBP).

Що входить у роботу?

  • Проєктування онтології (типи сутностей, ієрархія відношень)
  • Розробка pipeline виділення під ваш корпус (Python, Transformers, spaCy)
  • Розгортання Neo4j та написання Cypher-запитів для типових аналітик
  • Інтеграція GraphRAG з вашою LLM (OpenAI GPT-4, Claude, LLaMA)
  • Документація, навчання команди, підтримка 3 місяці після запуску

Чому GraphRAG вигідніший за класичний RAG?

Класичний RAG шукає за векторними чанками і втрачає контекст зв'язків. GraphRAG використовує граф знань: обходить вузли по ребрах, збирає підграф і передає його LLM. На тестовому наборі QALD-9 точність відповідей зросла на 30%, а кількість галюцинацій знизилася вдвічі. Додатково, завдяки використанню embeddings з context window до 8192 токенів, GraphRAG обробляє довші ланцюжки міркувань.

Параметр Класичний RAG GraphRAG
Пошук за контекстом Векторні чанки Обхід графа
Точність 65% (базовий) 85% (з графом)
Галюцинації Високі Низькі
Пояснюваність Низька Висока (ланцюги зв'язків)

Як підтримується актуальність графа?

Граф знань застаріває: компанії змінюють власників, люди — посади. Ми використовуємо детекцію суперечностей із версіонуванням ребер. Якщо нова трійка «А працює_в Б» суперечить існуючій «А працює_в В», ребро отримує дату актуальності. Зв'язки старші за поріг автоматично деактивуються. Це гарантує свіжість даних без ручної модерації.

Процес роботи

  1. Аналіз корпусу та онтологія (1 місяць): визначаємо типи сутностей та відношень, релевантні для вашої предметної області.
  2. Pipeline виділення (2–3 місяці): налаштовуємо NER, relation extraction, coreference resolution, entity linking під ваш корпус. Для зниження latency використовуємо ONNX Runtime та FP16 inference.
  3. Завантаження в Neo4j та GraphRAG (1 місяць): розгортаємо графову БД, пишемо Cypher-запити, інтегруємо з LLM.
  4. Інкрементальне оновлення (1–2 місяці): налаштовуємо автоматичну обробку нових документів та деактивацію застарілих зв'язків.

Технічний стек

# REBEL для виділення трійок
from transformers import AutoModelForSeq2SeqLM, AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("Babelscape/rebel-large")
model = AutoModelForSeq2SeqLM.from_pretrained("Babelscape/rebel-large")

def extract_triplets(text: str) -> list[tuple]:
    inputs = tokenizer(text, return_tensors="pt", max_length=512, truncation=True)
    outputs = model.generate(**inputs, max_length=256)
    decoded = tokenizer.batch_decode(outputs, skip_special_tokens=False)[0]
    return parse_rebel_output(decoded)
# Завантаження трійок у Neo4j
from neo4j import GraphDatabase

driver = GraphDatabase.driver("bolt://localhost:7687", auth=("neo4j", "password"))

def add_triplet(tx, subject, predicate, obj, source_doc):
    tx.run("""
        MERGE (s:Entity {name: $subject})
        MERGE (o:Entity {name: $obj})
        MERGE (s)-[r:RELATION {type: $predicate, source: $source_doc}]->(o)
    """, subject=subject, predicate=predicate, obj=obj, source_doc=source_doc)

Приклад запиту на Cypher:

// Всі колеги Івана Петрова
MATCH (p:Entity {name: "Іван Петров"})-[:RELATION {type: "працює_в"}]->
      (org:Entity)<-[:RELATION {type: "працює_в"}]-(colleague:Entity)
WHERE colleague <> p
RETURN colleague.name

Строки реалізації

Етап Тривалість Результат
Онтологія 1 місяць Словник типів сутностей і відношень
Pipeline виділення 2–3 місяці Граф на історичному корпусі
Neo4j + GraphRAG 1 місяць API для запитів
Інкрементальне оновлення 1–2 місяці Автоматична деактивація старих зв'язків

Приклад кейсу: побудова графа для новинного агрегатора. Клієнт — медіа-платформа з 1 млн новинних статей. Після побудови графа знань команда аналітиків почала отримувати відповіді на складні запити «Які компанії згадуються разом із технологією AI у контексті інвестицій?» за секунди замість годин пошуку по Elasticsearch.

Багаторічний досвід у NLP, 50+ завершених проєктів з Knowledge Graph. Зв'яжіться з нами для попереднього аналізу вашого проєкту — оцінимо обсяг і складність безкоштовно. Отримайте консультацію з автоматичного побудування графа знань для ваших даних.

NLP розробка: чому accuracy не підходить для рідкісних класів?

До нас приходить задача: обробляти 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. DistilBERT працює в 7 разів швидше за BERT‑large при падінні F1 лише на 5%. Експорт в ONNX Runtime з int8 quantization дає додатковий 1.5‑2x. Оцінимо проект — розрахуємо економію на інфраструктурі.

Модель F1 macro Latency (CPU) Розмір
BERT-large 0.89 180 ms 1.3 GB
DistilBERT 0.84 25 ms 250 MB
ruBERT-tiny2 0.81 12 ms 120 MB
DistilBERT + ONNX 0.84 14 ms 150 MB

Як вибрати модель класифікації під ваш датасет?

Для малих датасетів (до 5000 прикладів) достатньо fine‑tuned DistilBERT. Якщо потрібна багатомовність — XLM‑RoBERTa. При жорстких обмеженнях latency — дистильована модель з ONNX Runtime. Ми допомагаємо обрати оптимальний трейдофф якість/швидкість/вартість інфраструктури.

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) — часто найкращий трейдофф вартість/якість/швидкість. Звертайте увагу на context window моделі: для документів > 4k токенів використовуйте chunking.

Ембеддинги: векторні представлення тексту

Ембеддинги — основа семантичного пошуку, дедуплікації, кластеризації, 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 quantization знижує до 10GB. FAISS IVF_PQ — ще компактніше, але з втратами. Входить у наші рекомендації по деплою.

Вилучення інформації

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

  1. Regex + rule-based. Для ІПН, ЄДРПОУ, сум, дат — надійніше нейромережі. Не потребує даних.
  2. NER + постобробка. Для варіативних форматів.
  3. LLM з structured output. GPT‑4 / Claude з JSON schema — для складних документів. Вартість: залежить від обсягу документів. Для 10k+ документів/день — рахуємо економіку.

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

Етапи роботи

Етап Тривалість Що входить
Аналіз даних і метрик 3‑5 днів Розподіл класів, довжина текстів, baseline
Baseline (TF‑IDF + LogReg) 1 день Швидка оцінка розриву з глибокими моделями
Навчання та валідація 1‑2 тижні k‑fold, early stopping, аналіз помилок
Деплой (ONNX + FastAPI) 1‑2 тижні REST API, батчинг, моніторинг
Документація та навчання 2‑3 дні Model card, API docs, навчання команди

Прототип на існуючих даних — 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 дні.