Документы - самый очевидный и самый распространённый источник данных для векторизации. Практически у каждой компании есть сотни или тысячи файлов: инструкции, договоры, регламенты, прайс-листы, коммерческие предложения, технические спецификации. Всё это - потенциальная база знаний для ИИ.

PDF-документы

PDF - самый распространённый формат деловых документов, но и самый сложный для обработки. Существуют два принципиально разных типа PDF:

• Текстовые PDF - созданы в Word, PowerPoint или другом редакторе и экспортированы в PDF. Текст из них извлекается напрямую, с сохранением структуры, заголовков и форматирования. Это идеальный случай - парсинг занимает секунды
• Сканированные PDF - это по сути набор изображений страниц. Для извлечения текста требуется OCR (оптическое распознавание символов). Качество OCR зависит от разрешения скана, языка документа, наличия таблиц и рукописных пометок. Для русского языка хорошие результаты показывают Tesseract с русским языковым пакетом и специализированные облачные сервисы

На что обращать внимание при работе с PDF:

• Таблицы - стандартные PDF-парсеры часто «ломают» таблицы, превращая строки и столбцы в беспорядочный набор чисел. Для документов с большим количеством таблиц (прайс-листы, спецификации) нужны специализированные библиотеки, которые понимают табличную структуру
• Колонтитулы и нумерация - повторяющиеся элементы (название компании в шапке, номера страниц, копирайты внизу) создают шум. Их нужно удалять на этапе предобработки, иначе модель будет находить «релевантные» фрагменты, состоящие из одних колонтитулов
• Изображения внутри PDF - графики, схемы, фотографии в PDF-документах содержат ценную информацию, но текстовый парсер их игнорирует. Для полноценной обработки нужно извлекать изображения отдельно и описывать их текстом с помощью мультимодальных моделей

В проектах Промолитики мы выстроили конвейер обработки PDF: извлечение текста, определение структуры (заголовки, списки, таблицы), очистка от мусора, разбиение на фрагменты и создание эмбеддингов. Для одного из клиентов мы обработали более 2000 PDF-документов общим объёмом свыше 8 ГБ - от технических регламентов до маркетинговых исследований.

Word-документы (DOCX)

Word-документы проще в обработке, чем PDF, потому что они хранят структуру в формате XML. Заголовки, списки, таблицы - всё размечено явно. Это позволяет автоматически извлекать иерархию документа и использовать её при разбиении на фрагменты.

Основная проблема Word-файлов - непоследовательное форматирование. Авторы часто имитируют заголовки увеличенным шрифтом вместо стилей, делают отступы пробелами вместо табуляции, создают «таблицы» из символов табуляции. Всё это затрудняет автоматическую обработку. Мы рекомендуем перед массовой загрузкой проверить 20-30 случайных файлов вручную, чтобы оценить консистентность форматирования.

Excel и таблицы (XLSX, CSV)

Табличные данные - особый случай для векторизации. Прямая конвертация строк таблицы в текст часто даёт плохие результаты, потому что отдельная строка без заголовков столбцов лишена контекста.

Правильный подход: преобразовать каждую строку в структурированное текстовое описание. Например, строка таблицы с данными о квартире превращается в: «Квартира: 2-комнатная, площадь 65 кв.м, этаж 8 из 16, район Центральный, цена 7 500 000 руб., сдача Q3 2026». Такое описание содержит всю информацию и хорошо индексируется эмбеддинг-моделью.

Ключевые подводные камни: объединённые ячейки разрушают логику парсинга, скрытые листы могут содержать важные данные или мусор, формулы нужно преобразовать в значения. Мы всегда проверяем, есть ли заголовки столбцов и единообразны ли форматы данных (даты, числа, валюты).

CRM-система - это живое хранилище знаний о ваших клиентах, сделках и коммуникациях. Для ИИ-ассистента по продажам или бота-консультанта данные из CRM - стратегический ресурс. Но работа с ними требует глубокого понимания структуры и качества данных в конкретной CRM.

Что можно извлечь из CRM

• Карточки контактов и компаний - имена, должности, отрасли, история взаимодействий. Это основа для персонализации ответов ИИ
• Сделки и воронки - этапы продаж, суммы, сроки, причины отказов. Анализ успешных сделок помогает ИИ рекомендовать правильные подходы к новым клиентам
• Задачи и комментарии - менеджеры оставляют заметки о звонках, встречах, пожеланиях клиентов. Эта неструктурированная информация часто содержит самые ценные инсайты
• Переписка - многие CRM хранят историю переписки с клиентами (email, мессенджеры). Это отличный источник для обучения ИИ тону общения и типичным вопросам
• Кастомные поля - специфичные для бизнеса атрибуты, которые не вписываются в стандартные карточки. Именно они часто содержат самую ценную информацию

Пример из проекта: Profitbase и 48 кастомных полей

В одном из флагманских проектов Промолитики мы интегрировали ИИ-бота с CRM Profitbase для крупного застройщика. Profitbase - специализированная CRM для недвижимости, и в ней оказалось 48 кастомных полей для каждого объекта: от стандартных (площадь, этаж, количество комнат) до специфичных (вид из окна, наличие террасы, тип отделки, ближайшая школа, время до станции метро).

Из этих 48 полей только 22 заполнялись более чем у 70% объектов. Остальные 26 полей имели заполняемость ниже 30%. Мы приняли решение: для векторизации использовать все 48 полей, но с разной «весомостью». Поля с высокой заполняемостью включались в основное текстовое описание объекта. Поля с низкой заполняемостью добавлялись как дополнительные метаданные - они не попадали в эмбеддинг, но использовались для фильтрации.

Результат: бот корректно отвечал на запросы вроде «Покажи квартиры с террасой рядом с парком до 10 миллионов», комбинируя семантический поиск (близость к парку) с точной фильтрацией (наличие террасы, цена).

Сложности при извлечении данных из CRM

• API-ограничения - большинство CRM имеют лимиты на количество запросов. Bitrix24 ограничивает 50 запросами в секунду, amoCRM - ещё строже. При выгрузке 100 000+ записей нужно учитывать пагинацию, ретраи и потенциальную блокировку аккаунта
• Дубликаты - один клиент может быть записан в CRM 3-5 раз с разными вариациями названия. Перед векторизацией нужна дедупликация, иначе ИИ будет путать данные разных карточек одного клиента
• Кодировки и спецсимволы - данные, мигрированные из старых систем, могут содержать «битую» кодировку, HTML-теги в текстовых полях, служебные символы. Всё это нужно очищать
• Связи между объектами - CRM хранит данные в реляционной модели: контакт привязан к компании, компания - к сделке, сделка - к задачам. При векторизации нужно решить, на каком уровне создавать фрагменты: на уровне контакта, сделки или собрать всё в единый документ

Корпоративная электронная почта - один из самых недооценённых источников данных для ИИ. В переписке за 5-10 лет работы компании содержатся решения, договорённости, контексты проектов, которые невозможно найти ни в одной CRM или wiki. Проблема в том, что email-архивы - это гигабайты неструктурированного текста с высоким уровнем шума.

Форматы и извлечение

• MBOX - стандартный формат для экспорта почтовых ящиков. Один файл содержит все письма - может достигать десятков гигабайт. Парсинг требует потоковой обработки, потому что загрузить 12 ГБ файл в оперативную память целиком невозможно
• EML - одно письмо в одном файле. Удобно для обработки, но при экспорте тысяч писем создаётся огромное количество файлов
• IMAP - прямой доступ к почтовому серверу. Позволяет извлекать письма инкрементально - только новые с момента последней синхронизации. Мы рекомендуем этот подход для живых систем, где данные постоянно обновляются

Пайплайн обработки email в Промолитике

Мы выстроили многоступенчатый конвейер обработки почтовых архивов, который прошёл боевое крещение на реальных проектах. Вот как он работает:

Этап 1: Загрузка и парсинг. mbox-файл разбивается на отдельные письма. Из каждого извлекаются: тема, отправитель, получатели, дата, тело письма (plain text и HTML), вложения. Мы обрабатываем как текстовые версии, так и HTML - иногда они содержат разную информацию.

Этап 2: Очистка. Это самый критичный этап. Типичное деловое письмо содержит: подпись отправителя (часто с логотипом, юридической информацией и дисклеймером на 10 строк), цитирование предыдущей переписки (иногда 15-20 уровней вложенности), стандартные шаблоны («С уважением», «Sent from my iPhone»), HTML-мусор (теги форматирования, скрытые стили). Всё это нужно удалить, оставив только полезный текст.

Этап 3: Реструктуризация. Очищенный текст пропускается через языковую модель, которая преобразует неструктурированное письмо в структурированный формат: краткое содержание, ключевые решения, упомянутые лица, даты и суммы. Это значительно повышает качество поиска - вместо «сырого» текста с «эээ, ну давайте так, я позвоню в среду и обсудим» получается «Договорённость: звонок в среду для обсуждения условий поставки».

Этап 4: Генерация эмбеддингов. Каждый обработанный фрагмент превращается в вектор с помощью Voyage AI и сохраняется в Turbopuffer вместе с метаданными: дата, отправитель, тема, ID цепочки. Метаданные позволяют фильтровать результаты поиска по времени, участникам и темам.

Реальный кейс: 12 ГБ переписки

В одном из проектов мы обрабатывали mbox-архив размером 12 ГБ - корпоративную переписку сервисной компании за 4 года. Архив содержал более 180 000 писем. Из них после фильтрации спама, автоматических уведомлений и пустых ответов осталось около 62 000 полезных писем. После очистки и реструктуризации объём текста сократился в 4 раза - с учётом удаления подписей, цитирования и шаблонов. Итоговая база знаний содержит более 95 000 фрагментов, и менеджеры могут задавать вопросы вроде «Какие условия мы согласовали с компанией N по проекту X в прошлом году?» и получать точные ответы за секунды.

Логи чатов и тикеты техподдержки - это золотая жила для построения ИИ-ассистентов. В отличие от формальных документов, они содержат реальные вопросы клиентов - с реальными формулировками, ошибками и контекстом. Именно на этих данных ИИ учится понимать, как люди на самом деле формулируют проблемы.

Что извлекать из тикетов

• Пары «вопрос-ответ» - самый ценный тип данных. Клиент задаёт вопрос, агент поддержки отвечает. Из тысяч таких пар ИИ извлекает типичные сценарии и паттерны решений
• Классификация обращений - если тикеты размечены по категориям (технические проблемы, вопросы по оплате, запросы функционала), эта разметка становится ценным источником для обучения ИИ автоматической маршрутизации
• Решения и workaround-ы - внутренние заметки агентов часто содержат нестандартные решения проблем, которых нет в официальной документации. Это знание критически важно для ИИ-ассистента
• Частотность проблем - анализ тикетов позволяет выявить самые частые проблемы и приоритизировать наполнение базы знаний

Пример: реструктуризация тикетов поддержки

В одном из проектов мы обрабатывали выгрузку из Zendesk - более 15 000 тикетов за 2 года. Сырые тикеты содержали шум: автоматические ответы («Ваше обращение принято, номер 12345»), дублирование email-уведомлений, служебные метки.

После очистки мы применили реструктуризацию: языковая модель извлекала из каждого тикета суть проблемы, шаги решения и итоговый результат. Из «сырого» тикета с 20 сообщениями и 3000 символов получался структурированный фрагмент на 300-400 символов с чёткой формулировкой проблемы и решения. Эти фрагменты индексировались в векторную базу и использовались ИИ-ботом для ответов на новые обращения.

Результат: ИИ-бот корректно отвечал на 73% типовых обращений без привлечения оператора. При этом ответы были точнее, чем у скриптового бота, потому что ИИ понимал перефразированные вопросы и комбинировал информацию из нескольких похожих тикетов.

Для e-commerce, застройщиков и любых компаний с большим ассортиментом товаров или услуг каталог - это основной источник данных для ИИ-консультанта. Векторизация каталога позволяет клиентам описывать потребности своими словами, а не подбирать точные фильтры.

Что векторизировать в каталоге

• Текстовые описания - название товара, описание, характеристики в свободной форме. Это основа для семантического поиска: запрос «ноутбук для видеомонтажа» найдёт модели с мощными GPU, даже если в описании нет слова «видеомонтаж»
• Характеристики - технические параметры (вес, размер, цвет, мощность) преобразуются в текстовую форму. Строка «Процессор: Intel i7-13700H, RAM: 32 ГБ, SSD: 1 ТБ, GPU: RTX 4060» превращается в осмысленное текстовое описание, которое эмбеддинг-модель может связать с запросом «мощный ноутбук для тяжёлых задач»
• Отзывы и рейтинги - клиентские отзывы содержат реальный опыт использования. Запрос «надёжный чайник, который не ломается» может найти товар с отзывом «пользуемся третий год, работает как новый»
• Категории и теги - иерархия каталога добавляется как метаданные, позволяя комбинировать семантический поиск с фильтрацией

Особенности каталога недвижимости

Каталог недвижимости - пример сложного каталога, где каждый объект описывается десятками параметров. В проекте для застройщика мы векторизировали более 3900 объектов из Profitbase. Каждый объект преобразовывался в текстовое описание, которое включало: жилой комплекс, корпус, секция, этаж, количество комнат, площадь, цена, статус (свободна/забронирована/продана), тип отделки, вид из окна, наличие балкона или лоджии, срок сдачи.

Важная деталь: каталог обновляется в реальном времени. Когда квартира продаётся или бронируется в CRM, её статус обновляется в векторной базе в течение минут. Это критически важно для корректной работы бота - нельзя предлагать клиенту уже проданные объекты.

Внутренние базы знаний (Confluence, Notion, Wiki, SharePoint) - один из самых «готовых к ИИ» типов данных, потому что они уже структурированы. Статьи имеют заголовки, разделы, списки. Но даже здесь есть серьёзные проблемы, которые нужно решить до векторизации.

Типичные проблемы вики

• Устаревший контент - в типичной корпоративной wiki 40-60% статей не обновлялись более 2 лет. Инструкция по настройке интеграции с версией продукта, которая давно снята с поддержки, принесёт больше вреда, чем пользы. Перед загрузкой нужно провести аудит свежести контента
• Противоречия - нередко одна и та же тема описана в 3-4 статьях, написанных разными авторами в разное время. Инструкции могут противоречить друг другу. ИИ не сможет самостоятельно определить, какая версия актуальна
• Вложенная структура - wiki могут содержать десятки уровней вложенности. Статья на 5 экранов, в которой 80% текста - ссылки на другие статьи, плохо подходит для векторизации. Нужно «развернуть» ссылки и собрать контент в автономные фрагменты
• Медиа-контент - скриншоты, видеоинструкции, диаграммы. Текстовый парсер их пропустит, а в них может быть ключевая информация. Для полноценной обработки нужно описывать изображения текстом

Рекомендации по подготовке вики к векторизации

Мы рекомендуем трёхшаговый процесс. Сначала аудит: выгрузите список всех статей с датами последнего обновления и пометьте устаревшие. Затем актуализация: обновите или удалите устаревшие статьи. Бизнес часто сопротивляется этому шагу («а вдруг пригодится?»), но загрузка мусора в ИИ-систему обходится дороже. Наконец, нормализация: приведите структуру статей к единообразному формату - заголовки H2 для разделов, списки для пошаговых инструкций, единый стиль.

Аудио- и видеозаписи - мощный, но часто игнорируемый источник данных. Записи звонков с клиентами, обучающие видео, подкасты, совещания - всё это содержит ценную информацию, которая не существует ни в каком другом формате.

Процесс транскрибации

Прежде чем векторизировать аудио или видео, их нужно преобразовать в текст - транскрибировать. Современные модели распознавания речи (Whisper, Yandex SpeechKit) дают высокое качество транскрибации для русского языка - точность выше 90% для качественных записей.

Ключевые факторы, влияющие на качество транскрибации:

• Качество записи - фоновый шум, эхо, плохой микрофон значительно снижают точность. Записи с телефонных звонков (8 кГц, моно) распознаются хуже, чем качественные аудиозаписи (44.1 кГц, стерео)
• Количество говорящих - диалог двух человек распознаётся лучше, чем совещание на 10 участников, где люди перебивают друг друга. Для многоголосных записей нужна диаризация - определение, кто говорит в каждый момент
• Специальная лексика - профессиональные термины, названия продуктов, аббревиатуры часто распознаются неправильно. Для повышения качества можно использовать пользовательские словари
• Длительность - один час видеозаписи после транскрибации превращается в 8 000-12 000 слов текста. Это 15-20 страниц. Совещания на 3 часа генерируют огромные объёмы текста, которые нужно структурировать

Постобработка транскриптов

Сырой транскрипт - это поток слов без пунктуации, с повторами и словами-паразитами. Для качественной векторизации транскрипт нужно обработать: добавить пунктуацию, разбить на смысловые блоки, удалить «ээ», «мм», незаконченные фразы. Мы используем языковую модель для реструктуризации транскриптов - она превращает поток речи в структурированный текст с ключевыми тезисами, решениями и задачами.

Пример: часовая запись звонка с клиентом после обработки превращается в документ на 2 страницы с разделами «Запрос клиента», «Обсуждённые варианты», «Договорённости», «Следующие шаги». Такой документ отлично индексируется и легко находится поиском.

Многие деловые документы содержат изображения, которые несут критически важную информацию: схемы процессов, архитектурные чертежи, графики, скриншоты интерфейсов, фотографии объектов. Стандартные текстовые парсеры эти изображения игнорируют.

Как извлекать и обрабатывать изображения

• Извлечение из PDF - специализированные библиотеки позволяют извлечь все изображения из PDF с сохранением их позиции на странице. Это важно для понимания контекста: изображение между абзацами о «структуре отдела продаж» скорее всего является организационной схемой
• Описание изображений - мультимодальные языковые модели могут создать текстовое описание изображения. Схема процесса превращается в текст: «Блок-схема процесса обработки заявки: клиент подаёт заявку, менеджер проверяет данные, система отправляет подтверждение...» Это описание векторизируется и становится доступным для поиска
• Графики и диаграммы - модели могут извлечь данные из графиков: «Гистограмма: продажи в Q1 - 2.3 млн, Q2 - 3.1 млн, Q3 - 2.8 млн, Q4 - 4.2 млн». Эта информация недоступна для текстового парсера, но ценна для ИИ-аналитика
• Таблицы из сканов - для сканированных документов OCR-системы извлекают таблицы с переменным успехом. Сложные таблицы с объединёнными ячейками и мелким шрифтом требуют ручной проверки

Мультимодальные эмбеддинги

Помимо описания изображений текстом, существует подход с использованием мультимодальных эмбеддингов - моделей, которые создают векторы как для текста, так и для изображений в одном пространстве. Это позволяет искать по изображениям текстовым запросом: «план квартиры с двумя спальнями и большой кухней» найдёт соответствующие планировки, даже если они хранятся только как картинки без текстового описания.

На практике мы чаще используем комбинированный подход: мультимодальная модель создаёт текстовое описание изображения, которое затем векторизируется стандартной моделью эмбеддингов. Это проще в реализации и даёт более предсказуемые результаты.

Данные из социальных сетей и мессенджеров - ценный, но деликатный источник. Комментарии клиентов, обсуждения в группах, обратная связь в мессенджерах содержат реальное мнение аудитории. Но работа с ними требует особого внимания к правовым вопросам и качеству данных.

• Комментарии и отзывы - данные из публичных страниц компании в социальных сетях можно использовать для понимания типичных вопросов и проблем клиентов. Частые жалобы на конкретную функцию - сигнал для расширения базы знаний
• Чат-логи из мессенджеров - если компания ведёт переписку с клиентами через Telegram, WhatsApp или другие мессенджеры, эти логи можно использовать аналогично тикетам поддержки. Нужно извлечь пары «вопрос-ответ», очистить от мусора и векторизировать
• Приватность - персональные данные клиентов (имена, телефоны, адреса) необходимо удалить или анонимизировать перед загрузкой в ИИ-систему. Это не только юридическое требование, но и техническая необходимость: ИИ не должен цитировать персональные данные одного клиента в ответе другому

Подведём итог по всем рассмотренным источникам данных.

• PDF (текстовые) - сложность извлечения: низкая, качество данных: высокое, типичный объём: от сотен до тысяч файлов. Основная проблема: колонтитулы и таблицы
• PDF (сканы) - сложность: высокая, качество: зависит от OCR, объём: обычно сотни файлов. Проблема: ошибки распознавания, особенно в таблицах
• Word/Excel - сложность: низкая, качество: среднее (зависит от форматирования), объём: сотни-тысячи файлов. Проблема: непоследовательная структура
• CRM-данные - сложность: средняя (API), качество: среднее (дубликаты, пустые поля), объём: десятки-сотни тысяч записей. Проблема: API-лимиты, связи между объектами
• Email-архивы - сложность: высокая, качество: низкое без обработки, объём: десятки-сотни тысяч писем. Проблема: шум, цитирование, подписи
• Тикеты поддержки - сложность: средняя, качество: высокое после обработки, объём: тысячи-десятки тысяч тикетов. Проблема: автоматические ответы, дубли
• Товарные каталоги - сложность: низкая, качество: высокое, объём: сотни-тысячи позиций. Проблема: необходимость актуализации в реальном времени
• Базы знаний - сложность: низкая, качество: среднее (устаревший контент), объём: десятки-сотни статей. Проблема: противоречия, устаревание
• Аудио/видео - сложность: высокая (транскрибация), качество: зависит от записи, объём: часы-десятки часов. Проблема: качество записи, специальная лексика
• Изображения - сложность: высокая, качество: зависит от модели описания, объём: сотни-тысячи файлов. Проблема: описание сложных схем и графиков

Не пытайтесь векторизировать всё и сразу. Мы рекомендуем начинать с источников, которые дают максимальный эффект при минимальных усилиях. Вот матрица приоритизации, которую мы используем в проектах:

• Приоритет 1: структурированные данные с немедленной ценностью - товарные каталоги, базы знаний, FAQ, документация по продуктам. Эти данные обычно чистые, структурированные и дают быстрый результат. Начните с них
• Приоритет 2: полуструктурированные данные - CRM-данные, тикеты поддержки, PDF-документы с хорошей структурой. Требуют умеренной обработки, но содержат уникальные знания
• Приоритет 3: неструктурированные данные - email-архивы, аудиозаписи, сканированные PDF. Требуют значительных ресурсов на обработку, но могут содержать информацию, недоступную из других источников

Начните с первого приоритета, запустите ИИ-ассистента, соберите обратную связь от пользователей. Если они спрашивают вещи, ответы на которые есть только в email-архиве - переходите к третьему приоритету. Итеративный подход позволяет получить результат быстро и наращивать охват данных по мере необходимости.

Практически любые данные можно векторизировать и сделать доступными для ИИ-поиска. PDF-документы, CRM-записи, email-архивы, тикеты поддержки, товарные каталоги, базы знаний, аудиозаписи, изображения - каждый источник требует своего подхода к извлечению и обработке. Ключ к успеху - не в количестве данных, а в их качестве: чистые, актуальные, хорошо структурированные данные дают на порядок лучшие результаты, чем гигабайты необработанного мусора.

В Промолитике мы выстроили конвейеры обработки для каждого типа данных - от парсинга mbox-архивов до реструктуризации тикетов и транскрибации аудио. Мы используем Voyage AI для создания эмбеддингов, Turbopuffer и pgvector для хранения, и собственные RAG-пайплайны для построения интеллектуальных систем. Если вы хотите векторизировать данные своей компании и запустить ИИ-ассистента - свяжитесь с нами для бесплатной консультации.