Scribd класифікував 400 млн документів через Gemini
Scribd (сюди ж входять Slideshare, Everand, Fable) за кілька місяців перевірив на порушення правил понад 400 млн завантажених документів — 12+ млрд сторінок. Використали Gemini Enterprise batch prediction з нативним читанням PDF: Gemini 2.5 Flash Lite — основна модель, Gemini 2.5 Pro — другий прохід перевірки якості. Понад 99% корпусу оброблено без OCR і рендерингу.
Раніше кожна категорія порушень вимагала окремої моделі — роки розробки або дорогі вендорські рішення. Batch-режим Gemini Enterprise коштує вдвічі дешевше за інтерактивний, що зробило класифікацію такого обсягу фінансово виправданою.
Чому одна модель замінила окремі рішення для кожного типу порушень
Раніше кожна категорія порушень — від дублікатів до забороненого контенту — вимагала окремого спеціалізованого детектора: текст, зображення, макет сторінки оцінювалися різними системами. Це або роки внутрішньої розробки, або дорогі вендорські рішення, економіка яких не витримує обсягу 400 млн документів. Команда Scribd тестувала готові інструменти модерації та відкриті моделі — жоден не давав потрібної якості на такому масштабі.
Переломним моментом стало те, що Gemini читає PDF так, як він фактично існує: текст, макет і зображення в одному проході. У тестах Scribd мультимодальне розуміння ловило візуальні сигнали порушень, які текстові модерувальні системи регулярно пропускали — наприклад, порушення, помітні лише на зображенні чи в компонуванні сторінки, а не в самому тексті.
Як влаштований конвеєр без OCR та рендерингу
Документи зберігалися в Cloud Storage, звідти напряму подавались у Gemini Enterprise batch prediction, а результати потрапляли в аналітичну платформу команди. Жодної інфраструктури обслуговування запитів, ручного контролю лімітів чи керування GPU-потужностями — весь процес зведений до трьох кроків.
Класифікацію виконувала Gemini 2.5 Flash Lite, а Gemini 2.5 Pro проходила другим шаром як суддя — повторна перевірка всього корпусу для контролю якості результатів першої моделі. Оскільки кожна сторінка PDF обробляється як фіксована кількість токенів, вартість зростає лінійно і залишається передбачуваною навіть на 12 мільярдах сторінок.
Оптимізація вартості: batch і кешування промптів
Батч-режим із знижкою 50% від інтерактивних цін — це те, що зробило LLM-класифікацію фінансово життєздатною саме на масштабі всього корпусу, а не пілотного проєкту. Пізніше команда додала неявне кешування префіксів: промпти перебудували так, щоб статичний текст політики (незмінна частина запиту) потрапляв у кеш, а не пересилався й обраховувався щоразу заново. Це додатково знизило витрати без втрати якості класифікації.
Партнерство і що далі
Обробка 400 мільйонів документів — це передусім задача пропускної здатності. Google Cloud напряму підключився до планування бекфілу: стратегія регіонів, забезпечення потужностей заздалегідь. У результаті батч-завдання завершувались швидше за прогноз, і на значній частині проєкту вузьким місцем була вже не модель, а власний конвеєр підготовки даних Scribd.
Бекфіл став основою постійного процесу: новий контент тепер проходить через той самий конвеєр класифікації безперервно, а не періодичними чистками. Ту саму схему — PDF у Cloud Storage, batch prediction, результати в аналітичному сховищі — команда переносить на інші задачі розуміння контенту на своїх платформах.
Конкретних категорій порушень і вартості обробки в доларах матеріал не наводить.