Дедупликация данных в масштабе триллионов: как решить главное узкое место обучения LLM
Гонка масштабирования LLM — и ее невидимая цена
LLM преобразили почти все аспекты современного ИИ, открыв новые горизонты в генерации контента, разработке программного обеспечения, рассуждении и автономном использовании инструментов. И их возможности не показывают признаков замедления.
Возьмем самые недавние анонсы: Grok 4 от X.ai и Kimi K2 от Moonshot представляют более сильные способности к рассуждению, лучшее использование инструментов и более связную генерацию — все это обеспечивается значительно более крупными и разнообразными корпусами для обучения.
Тенденция очевидна: передний край возможностей продвигается вперед благодаря обучению в беспрецедентном масштабе. Рассмотрим объемы данных недавних моделей:
| Модель | Релиз | Параметры | Обучающие данные |
|---|---|---|---|
| Kimi K2 | 2025 | 1T | 15,5 триллиона токенов |
| Grok 4 | 2025 | ~175B | в 100 раз больше, чем Grok 2, вероятно, триллионный масштаб |
| GPT-4 | 2023 | 1.8T (оцен.) | 13 триллионов токенов |
| LLaMA 3.1 | 2024 | 405B | 15 триллионов токенов |
Kimi K2, например, утроила размер своего набора данных всего за шесть месяцев — темп роста, который почти опережает расширение интернета. При 15,5 триллиона токенов он во много раз больше совокупного содержимого всех крупнейших библиотек мира.
Но внутри этого роста скрыто предположение, что больше данных всегда означает лучшую производительность. На практике предельная отдача от простого добавления большего количества токенов уменьшается и все больше ограничивается качеством данных.
Это подводит нас к первому — и, возможно, наиболее недооцененному — узкому месту в современном обучении LLM: дублированию данных.
Дедупликация данных: почему это важно для обучения LLM
Современные наборы данных для предварительного обучения LLM в основном собираются из крупномасштабных веб-обходов, открытых репозиториев, публичных корпусов и доменно-специфичных документов, извлеченных из интернета. По мере роста этих конвейеров избыточность становится не просто распространенной, а системной.
Документы с незначительными вариациями (например, изменениями форматирования, футерами, шаблонными заголовками) снова появляются в разных доменах. Популярные страницы зеркалируются, переводятся или перепубликовываются на других сайтах. Кодовые базы и статьи знаний дублируются на форумах, в вики и архивных снимках. Даже структурированные источники, такие как Wikipedia, демонстрируют повторяемость в цепочках ссылок и зеркалах.
Когда такой дублированный контент бесконтрольно попадает в обучающие наборы, последствия оказываются значительными:
Неэффективность вычислений: Повторяющиеся примеры не несут новой информации, но потребляют те же вычислительные ресурсы.
Риск переобучения: LLM, сталкивающиеся с повторяющимися формулировками, структурой или паттернами контента, могут стать чрезмерно зависимыми от этих паттернов, тем самым снижая свои способности к обобщению.
Дословное запоминание: Высокий уровень дублирования увеличивает риск того, что модели будут запоминать конкретные последовательности, вызывая опасения в отношении безопасности, конфиденциальности и интеллектуальной собственности.
Утечка в оценке: Если дубликаты присутствуют как в обучающей, так и в валидационной/тестовой выборках, результаты бенчмарков могут быть искусственно завышены, создавая вводящее в заблуждение впечатление о качестве модели.
Короче говоря, дублирование — это не просто неудобство. Это экзистенциальная проблема для крупномасштабных и дорогостоящих обучающих запусков.
Один из наших корпоративных клиентов — провайдер LLM высшего уровня — столкнулся именно с этой проблемой. Им нужно было дедуплицировать десятки миллиардов документов до их загрузки. Инструменты точного сопоставления хешей пропускали почти-дубликаты. Семантические модели были слишком дорогими для запуска в таком масштабе. А традиционные стеки очистки данных просто не могли уложиться в их ограничения по времени и ресурсам.
Именно в этом контексте дедупликация стала критически важной инфраструктурой, а не второстепенным этапом предварительной обработки.
Обзор методов дедупликации
Существуют три доминирующие стратегии дедупликации в масштабе, каждая с компромиссами с точки зрения точности, стоимости и реализуемости.
Точное совпадение: Использует криптографическое хеширование для поиска идентичных документов. Быстро и точно, но пропускает почти дубликаты с незначительными различиями в форматировании.
Семантическое сопоставление: Использует модели векторных эмбеддингов для поиска концептуально похожего контента. Высокая точность, но вычислительно дорого в масштабе.
Приближенное сопоставление: Находит почти дубликаты с помощью вероятностных алгоритмов, таких как MinHash LSH и сходство Жаккара. Балансирует точность и вычислительную эффективность — идеально для наборов данных триллионного масштаба токенов.
Поскольку корпуса для предварительного обучения достигают терабайтов или даже петабайтов, традиционные методы точного сопоставления, такие как попарные сравнения, становятся вычислительно неосуществимыми. Семантическая дедупликация добавляет значительные накладные расходы, используя модели эмбеддингов для генерации векторов.
Нам нужны более инновационные приближенные методы — такие как MinHash LSH, — которые балансируют полноту и точность, сохраняя затраты управляемыми и делая крупномасштабную дедупликацию практичной.
MinHash LSH: обнаружение почти дубликатов в наборах данных триллионного масштаба
В контексте крупномасштабного обучения LLM эффективная дедупликация требует алгоритма сопоставления, который не только точен, но и вычислительно реализуем в масштабе десятков миллиардов документов. MinHash LSH (Locality Sensitive Hashing) специально создан именно для такого сценария.
MinHash: масштабируемая оценка сходства
MinHash — это вероятностная техника, предназначенная для оценки сходства Жаккара между множествами без вычисления явных попарных пересечений. В контексте дедупликации документов она действует как механизм сжатия с потерями, который сохраняет структуру сходства в огромных корпусах.
Процесс работает следующим образом:
Каждый документ разбивается на множество шинглов, обычно фиксированной длины символьных или словесных n-грамм.
К этим множествам применяется серия независимых хеш-функций.
Для каждой хеш-функции сохраняется минимальное полученное значение по множеству шинглов.
Это создает фиксированной длины MinHash-сигнатуру для каждого документа. Ключевое свойство заключается в следующем: для любых двух документов вероятность того, что конкретное хеш-значение совпадает в одной и той же позиции их сигнатур, приближенно соответствует их сходству Жаккара.
Это резко снижает вычислительную нагрузку при обнаружении сходства в крупном масштабе. Вместо сравнения полных документов мы сравниваем короткие векторы сигнатур. Но есть проблема масштабирования. Даже с этой оптимизацией сравнение каждой пары документов остается вычислительно неосуществимым в веб-масштабе.
Locality Sensitive Hashing: ускорение поиска сходства
Чтобы сделать MinHash практичным для корпусов миллиардного масштаба, мы применяем Locality Sensitive Hashing (LSH) поверх векторов сигнатур. Основная идея LSH — повысить вероятность того, что похожие документы попадут хотя бы в один и тот же хеш-бакет, без необходимости исчерпывающего сравнения.
Вот как это работает:
Каждая MinHash-сигнатура делится на несколько полос, каждая из которых содержит подмножество измерений сигнатуры.
Каждая полоса независимо хешируется в бакет.
Если два документа имеют хотя бы одну общую полосу, которая хешируется в один и тот же бакет, они считаются кандидатами на потенциальное дублирование.
Эта стратегия разбиения на полосы гарантирует, что документы с высоким сходством (т. е. с большим числом общих значений MinHash) имеют гораздо более высокую вероятность столкновения. Настраивая количество полос и строк на полосу, мы можем выбирать компромисс между полнотой (количеством найденных настоящих дубликатов), точностью (количеством избегнутых ложных срабатываний) и производительностью.
В результате получается масштабируемая система приближенной дедупликации, которая остается вычислительно приемлемой даже при применении к корпусам, содержащим десятки миллиардов документов.
Интеграция MinHash LSH с Milvus и Zilliz Cloud
Традиционно дедупликация выполняется отдельными конвейерами предварительной обработки, отключенными от основной инфраструктуры поиска или хранения. Это приводит к целому ряду неэффективностей:
Затратная передача данных между компонентами дедупликации и векторного индексирования.
Дублирование логики нормализации данных и шинглинга.
Сложность совместного масштабирования конвейеров дедупликации и поиска.
Мы подошли к проблеме иначе. Осознавая сильную сторону Milvus как высокопроизводительной векторной базы данных, мы задались вопросом: Что, если MinHash LSH станет полноправным, нативно интегрированным индексирующим примитивом?
Это привело к нативной интеграции MinHash LSH в Milvus 2.6 и Zilliz Cloud (управляемый Milvus), превратив приблизительную дедупликацию в ключевую часть рабочего процесса векторного индексирования и поиска.
Что дает эта интеграция
Сквозной рабочий процесс: От приема данных и генерации сигнатур MinHash до обнаружения приблизительных дубликатов и последующего семантического поиска — все внутри Milvus.
Распределенное масштабирование: Построенное на облачно-нативной архитектуре Milvus, индексирование LSH горизонтально масштабируется на терабайты или даже петабайты данных.
Единые API: Тот же API, который используется для поиска по семантическим эмбеддингам, теперь также может поддерживать запросы дедупликации на основе MinHash, делая рабочие процессы MLOps более чистыми и удобными в сопровождении.
В нашей текущей реализации:
Пользователи генерируют сигнатуры MinHash извне (например, используя предпочитаемые ими стратегии шинглинга и хеширования).
Эти векторы сигнатур (обычно массивы
uint32) вставляются в Milvus.Индексирование LSH сужает пространство кандидатов для обнаружения приблизительных дубликатов с использованием описанной выше стратегии разбиения на полосы.
Эта конструкция позволяет командам дедуплицировать обучающие корпуса в огромном масштабе без введения дополнительных уровней хранения или разобщенной логики предварительной обработки.
Мы также расширили базовый API для поддержки таких рабочих процессов, как гибридная вставка (семантические векторы и векторы MinHash), динамическое построение индекса и пакетные запросы дедупликации. Эти возможности все еще развиваются, и мы будем рады отзывам от команд, внедряющих это в production.
Инженерные сложности дедупликации десятков миллиардов документов с помощью MinHash LSH
Заставить MinHash LSH работать в production было «белым китом» индустрии на протяжении многих лет.
Сложность сводится к двум жестким требованиям:
Нужна глубокая экспертиза как в алгоритмах MinHash и LSH, так и инженерные навыки для их бесшовной интеграции.
Любой реальный сценарий использования MinHash LSH предполагает дедупликацию десятков миллиардов, сотен миллиардов или даже триллионов точек данных. Это создает колоссальные требования к производительности и инженерным возможностям, которым большинство команд не может соответствовать.
Вот показательный пример: около года назад к нам обратилась ведущая AI-компания с, казалось бы, простой просьбой. Им нужно было дедуплицировать десятки миллиардов точек данных (в формате int32 размерности 780) с возможностью быстро поднимать сервисы и оперативно обрабатывать данные для дедупликации и вставки.
Мы сразу столкнулись с критическим препятствием: большинство векторных баз данных по умолчанию используют форматы данных float32, но векторы MinHash — это наборы хеш-значений uint32.
На первый взгляд это кажется не проблемой — float32 ведь в большинстве случаев может представлять значения uint32, верно?
Неверно.
Вот в чем подвох: float32 может точно представлять только беззнаковые целые числа в диапазоне от 0 до 16,777,216, тогда как uint32 охватывает диапазон от 0 до 4,294,967,295. Если любое хеш-значение превышает 16,777,216, float32 начинает терять точность в младших значащих битах.
К счастью, поддержка бинарных векторов в Milvus и Zilliz Cloud элегантно решает эту проблему.
Это может показаться незначительной технической деталью, но она подчеркивает важный момент: вам нужна база данных, изначально спроектированная для работы с разнообразными форматами данных, огромными масштабами и различными корпоративными требованиями. Если вы с самого начала не ориентируетесь на сценарии enterprise-grade, даже такие крошечные проблемы совместимости могут со временем обернуться катастрофами для клиентского опыта.
Но проблема формата данных была только началом — наши клиенты также требовали экстремальной производительности. В процессе интеграции клиент сказал прямо: "Мне нужно быстро развернуть сервисы Zilliz Cloud, которые смогут сразу выполнять высокоточную векторную дедупликацию. Каждый импорт включает файлы по 30GB с 780-мерными сигнатурными данными int32, и весь процесс импорта должен завершаться менее чем за 15 минут."
На первый взгляд это выглядит как невыполнимая миссия, но мы быстро дали свой ответ: забудьте про 15 минут — мы справимся за 4.
Этот прорыв в производительности стал возможен благодаря двум ключевым оптимизациям Milvus:
Во-первых, мы реализовали параллельную обработку нескольких файлов, которая разрушила традиционное узкое место последовательного импорта. Теперь система может одновременно обрабатывать несколько файлов данных, резко повышая общую пропускную способность и скорость импорта.
Во-вторых, мы интегрировали динамическое распределение ресурсов, которое интеллектуально планирует вычислительные ресурсы на основе сложности и объема задач. Это устраняет напрасное расходование ресурсов и конкуренцию за них, одновременно максимизируя их использование. Вместе эти оптимизации позволяют Milvus полностью задействовать возможности современного оборудования и характеристики параллельного чтения-записи облачного хранилища, обеспечивая опыт импорта данных, близкий к реальному времени.
Решение проблемы импорта было лишь первым шагом — как обеспечить быстрое развертывание и вычисления в огромном масштабе?
Сценарии обучения больших AI-моделей создают идеальный шторм из жестких требований. Вы имеете дело с огромными объемами поступающих данных, массивными существующими базами данных и пиковыми нагрузками, которые могут достигать 44 000 векторных поисковых запросов в секунду — такой экстремальной конкурентностью, которая сокрушает большинство систем. По мере того как данные продолжают поступать, а ваша база данных растет экспоненциально, вычислительные требования соответственно возрастают, оказывая непрерывное давление на производительность системы.
Для решения требуется серьезная мощь распределенных вычислений. Облачная нативная архитектура Zilliz Cloud была специально разработана для решения этих задач с помощью интеллектуального распределения рабочих нагрузок и эластичного масштабирования.
Секретное оружие: интеграция Cardinal Engine
Заглядывая вперед, MinHash LSH представляет собой лишь начало. Мы интегрируем эту возможность в проприетарный Cardinal engine от Zilliz Cloud, что еще больше ускорит обработку неструктурированных данных по всем направлениям.
Cardinal — это наш векторный поисковый движок нового поколения на базе AI, созданный с нуля на современном C++ и с использованием передовых алгоритмов поиска приближенных ближайших соседей (ANNS). Цель проста: обрабатывать больше пользовательских запросов при тех же аппаратных ресурсах.
Оптимизации на уровне алгоритмов: Cardinal обеспечивает глубокую настройку производительности для ключевых алгоритмов, таких как IVF и графовая индексация, достигая оптимального баланса между скоростью и эффективностью использования памяти.
Инновации на инженерном уровне: Движок включает пользовательские аллокаторы памяти и интеллектуальный пул памяти, а также модульную архитектуру компонентов, которая обеспечивает гибкую композицию поискового pipeline. Каждый pipeline можно тонко настроить под конкретные, критически важные для миссии сценарии использования.
Оптимизация под конкретное оборудование: Cardinal включает несколько специализированных вычислительных kernels, каждый из которых вручную оптимизирован под определенные аппаратные платформы и шаблоны рабочей нагрузки.
Эти комплексные оптимизации позволяют Cardinal работать с максимальной эффективностью круглосуточно, обеспечивая лучшую в отрасли производительность векторного поиска. Благодаря Cardinal, лежащему в основе Zilliz Cloud, мы добились 10-кратного повышения производительности по сравнению с open-source Milvus в сочетании со сверхбыстрой скоростью запросов и высокими показателями recall. Обрабатываете ли вы массивные наборы данных или создаете приложения, которым требуется молниеносное время отклика, Cardinal обеспечивает производительную основу для превосходного пользовательского опыта и конкурентоспособных AI-приложений.
Будущее — за неструктурированными данными, и мы к нему готовы
Дедупликация данных для обучения LLM — это лишь вступительный акт в гораздо более масштабной истории трансформации. IDC прогнозирует, что к 2027 году объем неструктурированных данных во всем мире вырастет почти до 250 ЗБ, что составит 86,8% всех существующих данных. Хотя обработка и хранение таких данных обходятся значительно дороже, чем структурированных, невозможно игнорировать ценность, скрытую в текстах, изображениях, аудио, видео, журналах датчиков, контенте социальных сетей, PDF-файлах, веб-страницах, репозиториях кода, медицинских изображениях и спутниковых снимках.
Это создает определяющий вызов нашей эпохи: как эффективно извлекать ценность из экспоненциально растущих неструктурированных данных, не разоряясь?
Возможности дедупликации, которые мы создали для обучения AI, представляют собой лишь одну часть этой более крупной головоломки. По мере того как неструктурированные данные продолжают взрывной рост, те же принципы — интеллектуальные алгоритмы, инженерия корпоративного масштаба и cloud-native производительность — станут критически важной инфраструктурой для каждой организации, работающей на основе данных.
Будущее принадлежит компаниям, которые смогут превратить хаос неструктурированных данных в структурированное конкурентное преимущество. Мы строим это будущее — по одному алгоритму за раз. Готовы присоединиться к нам?
Готовы изучить крупномасштабную дедупликацию для вашего пайплайна обучения AI? Узнайте больше о возможностях MinHash LSH в Milvus 2.6 в нашей подробной документации, попробуйте Zilliz Cloud (управляемый Milvus) для production-нагрузок или свяжитесь с нашей инженерной командой в Discord чтобы обсудить ваш конкретный сценарий использования.
Читать далее
The AWS Outage Was a Wake-Up Call for Vector Database Cross-Region Disaster Recovery
Zilliz Cloud Had the Answer Before the Crisis. Zilliz Cloud is the world's first vector database with native cross-region disaster recovery.
Introducing Business Critical Plan: Enterprise-Grade Security and Compliance for Mission-Critical AI Applications
Discover Zilliz Cloud’s Business Critical Plan—offering advanced security, compliance, and uptime for mission-critical AI and vector database workloads.
1 Table = 1000 Words? Foundation Models for Tabular Data
TableGPT2 automates tabular data insights, overcoming schema variability, while Milvus accelerates vector search for efficient, scalable decision-making.