Невидимая работа в AI-продуктах: что съедает 80% времени разработки
Прототип — за неделю. Production — за четыре месяца. Разбираю айсберг под ватерлинией AI-продуктов: парсинг реальных PDF, чанкинг, мультитенантный поиск, стриминг и безопасность данных.
Знакомый запускал RAG-продукт для юридических фирм. Загрузи документы — получи ассистента, который отвечает на вопросы. Прототип показали инвесторам через неделю: промпт, OpenAI API, красивый интерфейс. Все в восторге, закрыли раунд.
Через четыре месяца — ни одного платящего клиента. Не потому что идея плохая. А потому что первый же юрист загрузил 340-страничный договор в PDF, сгенерированный из сканов 2014 года, с водяными знаками, двухколоночной вёрсткой и таблицами. Парсер вернул месиво из обрывков текста. RAG выдал галлюцинацию. Юрист закрыл вкладку и больше не вернулся.
Четыре месяца ушли не на модель — с моделью было готово на первой неделе. Четыре месяца ушли на то, чтобы научиться извлекать текст из реальных документов реальных клиентов. Это и есть невидимая работа, о которой молчат конференции и туториалы.
Что видят снаружи и что происходит внутри
На конференции: «Мы используем GPT-4o с RAG. Вот промпт. Вот результат.» Три слайда.
В реальности — айсберг. 87% работы — под ватерлинией. Невидимо, неинтересно, необходимо. И каждый процент — это дни инженерного времени, которые стартап не заложил в план.
Парсинг: один формат — одна неделя
«Пользователь загружает документ» — одна строка в спецификации. За ней — болото.
PDF — не текстовый формат. Это набор инструкций для рендеринга: «нарисуй глиф A в точке (142, 587)». Структуры текста — абзацев, заголовков, таблиц — в PDF нет. Есть пиксели и координаты.
Что ломает парсеры:
Сканы. PDF из отсканированных страниц. Внутри — изображения, не текст. PyPDF2 вернёт пустую строку. Нужен OCR — Tesseract, или облачный (Google Vision, AWS Textract). OCR ошибается: «О» и «0», «l» и «1», «rn» и «m». Каждая ошибка — потенциальная галлюцинация в ответе RAG.
Таблицы. Парсер извлекает текст построчно. Таблица из трёх колонок превращается в «Январь 100 Февраль 200 Март 300». Какие числа к какому месяцу? Утрачено. Нужен специализированный table extractor (Camelot, Tabula) — который тоже не справляется с объединёнными ячейками.
Двухколоночная вёрстка. Парсер читает слева направо: первая строка левой колонки, первая строка правой, вторая строка левой... Получается бессмыслица. Нужна layout-детекция — определить зоны колонок до извлечения текста.
Водяные знаки и колонтитулы. «КОНФИДЕНЦИАЛЬНО» по диагонали каждой страницы. Парсер извлекает всё вместе с основным текстом. Нужна фильтрация повторяющихся элементов.
На каждый формат — 3-5 дней работы для базовой поддержки. 2-3 недели для production-уровня с обработкой edge cases.
Чанкинг: простая задача, которая простой не бывает
Текст извлечён. Теперь его нужно нарезать на куски для embedding и поиска. Звучит тривиально.
Где резать? По количеству токенов (500, 1000) — режет предложения и таблицы пополам. По абзацам — абзацы бывают 50 токенов и 5 000. По заголовкам — у сканированных PDF заголовков нет.
Контекст. Чанк «рост составил 23% по сравнению с прошлым годом» бессмысленен без контекста: рост чего? Какого года? В каком документе? Нужен parent-чанк или метаданные, которые сопровождают каждый фрагмент.
Таблицы. Таблица из 30 строк при чанкинге по 500 токенов — строки 1-10 в одном чанке (с заголовками), строки 11-20 в другом (без заголовков), 21-30 в третьем (без заголовков). Два из трёх чанков — числа без подписей.
Recursive character text splitter из LangChain — стартовая точка. Для production — 2-4 недели доработки под конкретные типы документов.
Хранение и поиск: не «просто база»
Мультитенантность. Главная головная боль. Клиент A и клиент B загрузили документы в один продукт. Запрос клиента A не должен вернуть чанки клиента B. Один пропущенный фильтр tenant_id — утечка данных.
Обновление индекса. Клиент загрузил новую версию документа. Старые чанки → удалить. Новые → добавить. Атомарно: между удалением и добавлением не должно быть момента, когда пользователь получит пустой ответ.
Масштаб. 500 клиентов × 200 документов × 40 чанков = 4 миллиона векторов. Поиск <100 мс при параллельных запросах от сотни пользователей.
Стриминг: UX, о котором забывают
Пользователь задал вопрос. Без стриминга: 3-8 секунд белого экрана, потом текст целиком. Со стримингом — масса нюансов: два этапа (retrieval + генерация), Markdown в потоке, ошибки в середине ответа, ссылки на источники.
Каждый из этих вопросов — день-два работы. Совокупно — две недели на «просто показать ответ пользователю».
Безопасность данных: невидимая и обязательная
Клиент загружает конфиденциальные документы. Шифрование at rest и in transit. GDPR right to erasure. Аудит доступа. И главный вопрос — передача данных в LLM. «Куда уходят мои данные?» — вопрос, на который нужен ответ до первого enterprise-клиента.
Почему это убивает стартапы
Фаундер считает: промпт (неделя) + API (неделя) + фронтенд (две недели) + запуск = 6 недель. Реальность: 6 недель на видимую часть + 10-14 недель на невидимую. Бюджет — на 6 недель. Мотивация команды — на 6 недель.
На неделе 10, когда инженер третий день бьётся с парсингом PDF-таблиц, а фаундер объясняет инвестору, почему ещё не запустились, — стартап начинает умирать. Не от плохой идеи. От неправильной оценки того, что на самом деле нужно построить.
Что с этим делать
Умножайте оценки на три. Если команда говорит «6 недель» — это 18.
Используйте готовую инфраструктуру. Unstructured.io для парсинга. LlamaIndex / LangChain для чанкинга как базу. Managed vector store на старте.
Ограничивайте scope. «Загрузи любой документ» — приговор для стартапа. «Загрузи PDF до 50 страниц» — реалистичный MVP.
Нанимайте backend-инженеров. 80% AI-продукта — backend. ML-специалист настроит промпт за день. Без backend-инженера этот промпт будет работать на демо, а не в продакшне.
Невидимая работа определяет, будет ли AI-продукт работать с реальными данными реальных клиентов. Промпт — верхушка айсберга. Красивая, заметная, на которую все смотрят. Но плывёт айсберг туда, куда его несёт масса под водой. И если этой массы нет — верхушка просто тонет.