AI-система збагачення клієнтських даних з відкритих джерел

У 60% CRM-записів не вистачає ключових полів: посада, розмір компанії, технології. Менеджери витрачають години на ручний пошук у LinkedIn і Google — а дані застарівають через місяць. Ми будуємо AI-пайплайни, які за секунди доповнюють профіль клієнта з десятка відкритих джерел: LinkedIn, Crunchbase, GitHub, новин, реєстрів. Результат: контакт із 20+ полями замість 3.

У типовій CRM на 50 000 контактів ручний ввід забирає до 20 людино-годин на тиждень. Автоматизація скорочує цей час на 80% і одночасно покращує якість прогнозів воронки продажів на 25%. Ми вже реалізували такі рішення для компаній із CRM від 10 000 до 2 000 000 записів — і в кожному випадку окупність наставала в перші 3 місяці. Економія часу дозволяє команді зосередитися на кваліфікації лідів, а не на рутинному пошуку.

Чому AI швидший і точніший за ручний ввід?

AI-пайплайн обробляє запити паралельно: за 2-5 секунд він опитує LinkedIn через ProxyCurl, Crunchbase, Clearbit, GitHub і реєстри. Ручний пошук займає 3-5 хвилин на контакт і дає 2-3 поля. AI видає 20+ полів з confidence score вище 0.85. Завдяки лід-скорингу на основі AI, відділ продажів фокусується на найперспективніших контактах.

Проблеми, які ми вирішуємо

Неповні профілі, застарілі дані, розрізнені джерела. Ручний ввід обходиться в середньому дорого як у плані часу, так і ресурсів. Наш пайплайн через ProxyCurl знаходить LinkedIn-профіль за email, витягує досвід, навички та сертифікати. Дані не старші 30 днів — автоматичне оновлення. Reconciliation engine вирішує конфлікти за пріоритетами (реєстри → Clearbit → веб).

Як влаштований пайплайн?

Використовуємо асинхронний asyncio та httpx для паралельних запитів. Це дозволяє обробляти запити в 5 разів швидше послідовного обходу. Пайплайн складається з незалежних енрічерів — одне джерело не блокує інші. Пайплайн працює в 5 кроків:

1. Отримуємо контакт із CRM (email, компанія).
2. Паралельно опитуємо всі джерела.
3. Об'єднуємо дані за пріоритетами (реєстри > Clearbit > LinkedIn > веб).
4. Валідуємо та обчислюємо confidence score.
5. Записуємо результат назад у CRM.

LinkedIn збагачення через ProxyCurl

import httpx

class LinkedInEnricher:
    def __init__(self, api_key: str):
        self.api_key = api_key
        self.base_url = "https://nubela.co/proxycurl/api"

    async def enrich(self, email: str, company: str) -> dict:
        async with httpx.AsyncClient() as client:
            # Пошук профілю за email
            response = await client.get(
                f"{self.base_url}/linkedin/profile/resolve/email",
                params={"email": email},
                headers={"Authorization": f"Bearer {self.api_key}"}
            )

            if response.status_code != 200:
                return {}

            profile_url = response.json().get('linkedin_profile_url')
            if not profile_url:
                return {}

            # Отримання повного профілю
            profile_response = await client.get(
                f"{self.base_url}/v2/linkedin",
                params={"url": profile_url, "skills": "include"},
                headers={"Authorization": f"Bearer {self.api_key}"}
            )

            return profile_response.json()

AI-вилучення технологічного стеку

class TechStackExtractor:
    def __init__(self):
        self.llm = Anthropic()

    async def extract_from_website(self, domain: str) -> list[str]:
        """Вилучення tech stack з сайту компанії через AI"""
        # Збір контенту з сайту
        job_postings = await self._scrape_job_postings(domain)
        about_page = await self._scrape_page(f"https://{domain}/about")

        combined_text = ' '.join([about_page] + job_postings[:5])

        response = self.llm.messages.create(
            model="claude-3-5-sonnet",
            max_tokens=300,
            messages=[{
                "role": "user",
                "content": f"""Extract technology stack from this company information.
Return JSON array of technology names (programming languages, frameworks, cloud platforms, databases).
Only include clearly mentioned technologies.

Text: {combined_text[:3000]}"""
            }]
        )

        return json.loads(response.content[0].text)

Як ми забезпечуємо точність збагачених даних?

Різні джерела дають суперечливі дані: Clearbit показує 50 співробітників, а LinkedIn — 120. Наша логіка пріоритету вирішує конфлікти. Ми використовуємо confidence score (не нижче 0.85) і крос-перевірку полів. Кожне джерело має пріоритет: офіційні реєстри > Clearbit > LinkedIn > веб-скрапінг. У результаті accuracy для базових полів (посада, індустрія, розмір компанії) досягає 85-90%.

Конфлікти даних вирішуються пріоритетною реконсиліацією: офіційні реєстри > Clearbit > LinkedIn > веб-скрапінг. Кожне поле проходить валідацію та отримує confidence score. Якщо score нижче 0.85, дані відкидаються.

def reconcile_company_info(sources: list[dict]) -> dict:
    """Об'єднання даних про компанію з кількох джерел"""
    reconciled = {}

    # Пріоритет джерел: офіційні реєстри > Clearbit > Web scraping
    priority_order = ['company_registry', 'clearbit', 'linkedin', 'web_scraping']

    for field in ['employee_count', 'founded_year', 'industry', 'headquarters']:
        for source_name in priority_order:
            source = next((s for s in sources if s.get('source') == source_name), None)
            if source and field in source:
                reconciled[field] = source[field]
                break

    return reconciled

Типовий результат: збагачення 80-90% CRM контактів за 2-5 секунд на запис.

Процес роботи та терміни

Проект включає такі етапи:

• Аудит поточної CRM: виявляємо пропущені поля та дублікати.
• Проектування пайплайну: вибір джерел, налаштування API-ключів, узгодження формату даних.
• Реалізація з нуля або інтеграція з існуючою інфраструктурою (Python, FastAPI, asyncio).
• Тестування на 1000+ записах: перевірка accuracy та latency.
• Деплой на ваші сервери або в хмару (AWS/GCP).
• Документація з API та інтеграції.
• Навчання команди роботі з дашбордом.
• Підтримка 3 місяці з гарантією якості.

Підсумковий термін — від 4 до 8 тижнів залежно від кількості джерел та складності реконсиліації. Вартість розраховується індивідуально після аудиту.

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

• Архітектурна документація пайплайну.
• Код пайплайну з інтеграцією 5+ джерел.
• Готові конектори для HubSpot, Salesforce, Bitrix24, AmoCRM.
• REST API для пакетного збагачення.
• Дашборд моніторингу (latency, accuracy, покриття).
• Навчання команди (2 сесії по 2 години).
• Підтримка 3 місяці з SLA за часом відгуку.

Типові помилки при збагаченні та як ми їх уникаємо

• Залежність від одного джерела — використовуємо fallback-ланцюжок та timeout.
• Застарілі API-токени — моніторимо квоти та проксуємо запити через ротацію ключів.
• Некоректна дедуплікація — застосовуємо fuzzy matching за назвами компаній та email.
• Витік даних — всі дані передаються по TLS, а токени зберігаються в Vault.

Висновок

Працюємо понад 5 років — понад 50 проєктів з data enrichment для фінтеху, ритейлу та SaaS. Використовуємо стеки PyTorch, LangChain, PostgreSQL, Redis. Підтримуємо версії Python 3.11+. На практиці наше рішення економить клієнтам до 80% часу за рахунок скорочення ручного вводу. Замовте аудит вашої CRM — ми проаналізуємо поточний стан і запропонуємо архітектуру під ключ. Отримайте консультацію інженера з впровадження.

Чому дата-інжиніринг визначає успіх ML-моделі

Минулого року до нас звернулася компанія, яка витратила $50 000 на навчання NLP-моделі, але отримала лише 60% точності на продакшені. Причина — data leakage через випадковий split часових даних. Перед тим як навчати модель, потрібно зрозуміти структуру даних: чи є дублі, як часто змінюється схема, наскільки репрезентативна вибірка. Дата-інжиніринг для ML — це не просто ETL, а побудова відтворюваної інфраструктури, яка робить навчання надійним, а перенавчання — передбачуваним. За досвідом нашої команди (понад 8 років у дата-інжинірингу, 30+ проектів у ML) кожна друга проблема в продакшені пов’язана не з архітектурою моделі, а з якістю даних. Замовте аудит ваших даних — оцінимо поточний пайплайн безкоштовно.

Як ETL-пайплайни для ML відрізняються від BI

ETL для аналітики та ETL для ML — різні завдання. В аналітиці важлива агрегація, у ML — індивідуальні записи з історією. В аналітиці train/val/test split не потрібен, у ML — критичний. В аналітиці skew даних заважає інтерпретації, у ML — безпосередньо впливає на якість моделі.

Інструменти. Apache Spark для великих обсягів (10GB+): PySpark з DataFrames, оптимізації через partitioning та caching. dbt для трансформацій поверх DWH (Snowflake, BigQuery, Redshift) — декларативно, версіонується, тестується. Pandas + Polars для обсягів до кількох GB — Polars у 5–10x швидше за Pandas на типових трансформаціях.

Temporal splits. Для ML важливо, що split за часом, а не випадковий. Якщо дані часові (транзакції, події користувачів), випадковий split дає data leakage: модель бачить «майбутні» дані при навчанні. Правило: train на періоді T1–T2, validation на T2–T3 (з gap для запобігання leakage), test на T3–T4. Неправильний split може коштувати 10–15% якості моделі на валідації. Temporal split best practices (scikit-learn docs)

Інкрементальні пайплайни. Модель перенавчається щотижня на нових даних. Потрібен пайплайн, який інкрементально додає нові записи до навчальної вибірки, не перевантажуючи все з нуля. Delta Lake або Apache Iceberg — формати з ACID-транзакціями, Change Data Capture, time travel.

Як уникнути training-serving skew за допомогою Feature Store

Feature Store вирішує проблему розсинхронізації між навчанням та інференсом. Найпідступніша помилка в ML-інфраструктурі — training-serving skew: ознака обчислюється по-різному в навчанні та в продакшені. Модель вчиться на «правильних» даних, а інференс отримує інші.

Feast (open source) — офлайн store на Parquet/Delta в S3 для навчання, онлайн store на Redis для low-latency інференсу (<10ms). Feature definitions як Python-код:

from feast import FeatureView, Field
from feast.types import Float32, Int64

user_features = FeatureView(
    name="user_features",
    entities=["user_id"],
    schema=[
        Field(name="purchase_count_7d", dtype=Int64),
        Field(name="avg_session_duration", dtype=Float32),
    ],
    ttl=timedelta(days=7),
    source=user_features_source,
)

Один definition використовується всюди — немає розбіжностей.

Потокові ознаки. Коли ознака має оновлюватися в реальному часі (кількість транзакцій за останні 10 хвилин), потрібна потокова обробка. Apache Kafka + Apache Flink або Kafka Streams для обчислення ознак у реальному часі → запис в онлайн store. Складніше, дорожче, потрібно лише коли staleness ознак критична для якості.

Розмітка даних: як не витратити бюджет даремно

Розмітка — найтрудомісткіша та недооцінювана частина ML-проекту. Погано розмічені дані не виправить жодна архітектура.

Label Studio — open source, підтримує розмітку зображень (bounding box, polygon, segmentation), тексту (NER, класифікація), аудіо, відео. Піднімається за 10 хвилин через Docker. Для невеликих команд — перший вибір.

Оцінка якості розмітки. Inter-annotator agreement — наскільки згодні розмітники між собою. Cohen's Kappa > 0.8 — добре, 0.6–0.8 — прийнятно, < 0.6 — завдання неоднозначне або інструкція погана. Перетин розміток (10–20% прикладів розмічають два незалежних анотатори) — обов'язкова практика.

Active learning. Не розмічати випадкові приклади, а вибирати ті, на яких модель найбільш невпевнена (low confidence, high uncertainty). Дозволяє досягти тієї ж якості при 50–70% обсягу розмітки. Modals, Prodigy, Label Studio підтримують active learning workflows. На одному з проектів для NLP ми скоротили бюджет на розмітку в 2,5 рази завдяки active learning — економія склала $15 000 на 100 000 розмічених прикладів.

Синтетичні дані. Коли реальних даних мало або отримати їх дорого. Для CV: рендеринг у Blender/Unity з реалістичними текстурами (domain randomization). Для NLP: parafrase через LLM, backtranslation. Ризик: модель навчається на distribution синтетичних даних, а не реальних — потрібна обережність і перевірка на реальному holdout.

Якість даних: валідація та моніторинг

Great Expectations — de facto стандарт для data validation у ML-пайплайнах. Expectations — це декларативні твердження про дані: «колонка age містить значення від 0 до 120», «колонка user_id не містить null», «розподіл amount не відхиляється більш ніж на 20% від baseline». Запускається в пайплайні, при провалі — блокує проходження.

Pandera — Pythonic alternative для pandas/polars DataFrames. Schema-based validation з type hints:

import pandera as pa

schema = pa.DataFrameSchema({
    "user_id": pa.Column(int, nullable=False),
    "score": pa.Column(float, pa.Check.between(0, 1)),
    "label": pa.Column(str, pa.Check.isin(["positive", "negative", "neutral"])),
})

Data freshness. Модель очікує дані за останні N днів. ETL впав, дані не оновилися — модель використовує застарілі ознаки. Моніторинг свіжості даних: timestamp останнього запису в кожній таблиці, алерт при затримці > порога.

Дедуплікація. Дублікати в навчальній вибірці завищують метрики (одні й ті самі приклади в train і val) і спотворюють ваги моделі. MinHash LSH для наближеної дедуплікації великих датасетів. Для точної — хеш за нормалізованим контентом.

Сховища та формати

Для більшості ML-проектів на старті: Parquet в S3 + DVC для версіонування. Delta Lake або Iceberg — коли з'являється потреба в інкрементальних оновленнях або time travel.

Типові помилки при побудові пайплайнів

• Пропуск перевірки свіжості даних. Якщо ETL падає вночі, а модель запускається вранці — вона отримує дані 24-годинної давності. Рішення: алерт при затримці > 30 хвилин.
• Відсутність версіонування даних. Не можна відтворити експеримент, бо дані змінилися. DVC або Delta Lake time travel виправляють це.
• Забувають про schema evolution. Нове поле з’являється, а пайплайн падає. Автоматичне виявлення змін схеми через Great Expectations.

Active learning дозволяє скоротити бюджет на розмітку до 50–70%. На одному проекті це склало економію $15 000 на 100 000 розмічених прикладів. Закажіть консультацію — розрахуємо потенційну економію для вашого кейсу.

Що входить у проект з дата-інжинірингу для ML

Ми надаємо повний цикл:

• Аудит існуючих даних та пайплайнів (1 тиждень).
• Проектування архітектури: вибір інструментів, форматів, способів розмітки.
• Реалізація ETL/ELT пайплайну з валідацією та моніторингом.
• Документація коду та процесів (model card, data card).
• Навчання вашої команди роботі з пайплайном.
• SLA на супровід та підтримку.

Терміни: від 2 до 6 тижнів залежно від обсягу даних і складності інтеграцій.

Як ми будуємо пайплайн: покроково

1. Аудит існуючих даних. Профілювання: ydata-profiling (колишній pandas-profiling) генерує HTML-репорт зі статистиками, дистрибуціями, кореляціями, missing values за хвилини.
2. Проектування пайплайну. Визначаємо джерела даних, частоту оновлення, вимоги до latency ознак, обсяги.
3. Реалізація та тестування. Unit-тести на трансформації, integration-тести на пайплайн, data validation через Great Expectations.
4. Деплой та моніторинг. Алерти на freshness, quality checks, аномалії в обсягах даних.

Чому варто довірити це нам

Ми займаємося дата-інжинірингом та ML з понад 8-річним досвідом. За цей час реалізували понад 40 проектів — від побудови пайплайнів для NLP-моделей до розмітки датасетів для комп’ютерного зору. Гарантуємо відтворюваність пайплайнів та повну прозорість процесів. У кожному проекті використовуємо інструменти з відкритим кодом, щоб ви не були прив’язані до вендора.

Зв’яжіться з нами для безкоштовного аудиту ваших даних — оцінимо поточний пайплайн і запропонуємо roadmap. Замовте побудову ML-пайплайну під ключ.