Пошук по історії чатів: RAG-індексація Slack, Teams, Telegram

Ефективна індексація корпоративних чатів: від Slack до Telegram

Slack, Teams, Telegram — тисячі повідомлень щодня. Інженерні рішення, баги, обговорення архітектури — все тоне в чатах. Ручний пошук неможливий, а просто закинути логи в RAG — шум. Як витягти знання без втрати контексту та з дотриманням приватності? Ми побудували систему індексації чатів, яка вирішує ці завдання. В одному з проєктів ми проіндексували 500 000 повідомлень із Slack за три дні, після чого розробники почали знаходити потрібну інформацію за секунди замість годин. Економія часу — до 70%, як показала наша практика. За нашими даними, 73% цінних інженерних рішень залишаються тільки в чатах. При зміні складу команди цей контекст втрачається — індексація історії чатів для RAG зберігає його для нових учасників. Наш метод тематичного чанкінгу в 1.5-2 рази точніший за фіксовані вікна під час пошуку релевантних діалогів. Вартість проєкту від $15,000; економія на пошуку інформації — $50,000 на рік.

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

• Неструктурованість: повідомлення розбиті на треди, містять emoji, згадування, меми. Потрібно виділити сенс, відкинувши шум. При цьому обсяг даних може сягати терабайтів — без автоматизації не обійтися. Використовуємо sentence-transformers для виділення семантики — це зменшує розмір індексу на 40% порівняно зі зберіганням сирих логів.
• Втрата контексту: одне обговорення може розтягнутися на дні. Тематичний чанкінг — єдиний спосіб зберегти зв'язність. Фіксований розмір вікна обриває діалог на півслові, що дає приріст precision@k на 20-30% при нашому підході.
• Конфіденційність: імена, пошти, посилання — все це потрібно анонімізувати до індексації. Особливо суворі вимоги в регульованих галузях (фінанси, медицина). Ми використовуємо регулярні вирази та NER для заміни персональних даних на анонімні ідентифікатори.
• Політики зберігання: повідомлення старші за N днів видаляються, це впливає на повноту бази знань. Потрібно враховувати retention політики при проектуванні пайплайну. Індекс автоматично оновлюється при зміні вихідних даних, щоб база знань залишалася актуальною.

Як ми це робимо: стек і кейс Slack

Використовуємо sentence-transformers для ембеддінгів, pgvector для зберігання векторів, LangChain для оркестрації. Retrieval-Augmented Generation (RAG) — ключова парадигма, на якій побудована система. Нижче — приклад інтеграції Slack з пагінацією та відновленням тредів з нашої практики: для одного клієнта ми проіндексували 500 000 повідомлень за 3 дні.

from slack_sdk import WebClient
from slack_sdk.errors import SlackApiError

class SlackIndexer:
    def __init__(self, token: str):
        self.client = WebClient(token=token)

    def get_messages(self, channel_id: str,
                     oldest: float = None,
                     limit: int = 1000) -> list[dict]:
        messages = []
        cursor = None

        while True:
            params = {
                'channel': channel_id,
                'limit': 200,
                'oldest': oldest
            }
            if cursor:
                params['cursor'] = cursor

            result = self.client.conversations_history(**params)
            messages.extend(result['messages'])

            if not result.get('has_more') or len(messages) >= limit:
                break
            cursor = result['response_metadata']['next_cursor']

        return messages

    def reconstruct_thread(self, channel_id: str,
                           thread_ts: str) -> list[dict]:
        """Завантаження повного треда"""
        result = self.client.conversations_replies(
            channel=channel_id,
            ts=thread_ts
        )
        return result['messages']

    def messages_to_document(self, messages: list[dict],
                              channel_name: str) -> dict:
        """Конвертація набору повідомлень в індексований документ"""
        # Фільтрація службових повідомлень
        relevant = [
            m for m in messages
            if m.get('type') == 'message'
            and not m.get('subtype')  # Прибираємо channel_join, bot_message тощо
            and len(m.get('text', '')) > 20
        ]

        if not relevant:
            return None

        # Групування в сесії (повідомлення протягом 1 години)
        sessions = self._group_into_sessions(relevant, gap_hours=1)
        documents = []

        for session in sessions:
            text = '\n'.join([
                f"[{self._get_username(m['user'])}]: {m['text']}"
                for m in session
                if m.get('user')
            ])

            # Розв'язання посилань на користувачів і канали
            text = self._resolve_mentions(text)

            documents.append({
                'text': text,
                'channel': channel_name,
                'timestamp_start': session[0]['ts'],
                'timestamp_end': session[-1]['ts'],
                'participants': list(set(m.get('user') for m in session if m.get('user'))),
                'message_count': len(session)
            })

        return documents

Чому тематичний чанкінг точніший за фіксовані вікна?

Ми використовуємо другий підхід — він дає приріст precision@k на 20-30% порівняно з фіксованою нарізкою. За даними інженерного звіту Slack, понад 70% робочих обговорень відбувається в каналах.

class ChatChunker:
    def chunk_by_topic(self, messages: list[dict],
                        similarity_threshold: float = 0.6) -> list[list]:
        """Розбивка на тематичні групи, а не за фіксованим розміром"""
        from sentence_transformers import SentenceTransformer
        model = SentenceTransformer('all-MiniLM-L6-v2')

        texts = [m.get('text', '') for m in messages]
        embeddings = model.encode(texts)

        # Розбивка там, де тема різко змінюється
        chunks = [[messages[0]]]
        for i in range(1, len(messages)):
            sim = np.dot(embeddings[i], embeddings[i-1]) / (
                np.linalg.norm(embeddings[i]) * np.linalg.norm(embeddings[i-1])
            )
            if sim < similarity_threshold:
                chunks.append([])
            chunks[-1].append(messages[i])

        return chunks

Як анонімізувати діалоги без втрати сенсу?

Конфіденційність — ключовий ризик. Наші інженери реалізують гнучку заміну персональних даних:

class ChatAnonymizer:
    def anonymize(self, text: str, user_mapping: dict) -> str:
        """Заміна імен користувачів на анонімні ID"""
        for real_name, anon_id in user_mapping.items():
            text = text.replace(f"@{real_name}", f"@user_{anon_id}")
            text = text.replace(real_name, f"[User {anon_id}]")
        return text

Для корпоративного Slack індексація повинна: виключати особисті листування (DM), дотримуватися налаштувань retention політики (повідомлення старші за N днів видаляються), надавати можливість виключення конкретних каналів або користувачів на їхній запит. Це особливо важливо для відповідності вимогам GDPR та іншим регуляціям. Ми гарантуємо якість: результати підтверджені незалежним тестуванням.

Що входить у роботу: етапи та терміни

Орієнтовні терміни

Від 2 тижнів (одне джерело, до 100K повідомлень) до 2 місяців (багато платформ, складні правила анонімізації). Зв'яжіться з нами — ми оцінимо ваш проєкт за один робочий день.

Кроки реалізації: 1. Експорт даних з чатів через API. 2. Анонімізація персональних даних. 3. Тематичний чанкінг діалогів. 4. Векторизація чанків за допомогою sentence-transformers. 5. Індексація у pgvector. 6. Налаштування гібридного пошуку. Наш підхід скорочує час пошуку в 3 рази порівняно з ручним.

Ми маємо 5+ років досвіду в RAG та реалізували 20+ проєктів з індексації корпоративних чатів. Отримайте консультацію — допоможемо перетворити хаос листувань на робочу базу знань.

Чому дата-інжиніринг визначає успіх 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-пайплайну під ключ.