В каких случаях Lakehouse может стать лучшим решением для бизнеса, каким функциональным и техническим требованиям должно удовлетворять решение, чтобы считаться полноценной Lakehouse-платформой, как выглядит типовой путь внедрения и за счет чего достигается снижение совокупной стоимости владения данными — рассказывает Владислав Подречнев, директор направления инженерии данных компании «Синимекс».
— Какие вы могли бы отметить предпосылки для появления решения класса Lakehouse на российском рынке? Как его появление повлияло на рынок больших данных?
В. Подречнев: Появление Lakehouse — закономерный результат эволюции мира данных. Классические DWH отлично справлялись с регламентированной отчетностью и построением витрин в условиях, когда данные были хорошо структурированы и более предсказуемы. По мере роста числа источников (событийные логи, потоковые, полу- и неструктурированные данные), ускорения бизнес-процессов и ужесточения требований к self-service аналитике DWH оказался экономически тяжелым и операционно «жестким». Высокая стоимость лицензий в сочетании с необходимостью дублировать данные вынуждала дата-инженеров искать более дешевые и гибкие подходы к хранению информации.
Так возник параллельный мир Data Lake, который обеспечил гибкость хранения любых типов данных, но без транзакционности, строгой управляемости и гарантированной повторяемости результатов. Неаккуратная эксплуатация и неидеальные архитектурные практики нередко превращали озера данных в «болота».
На этом фоне стали появляться открытые табличные форматы (Iceberg, Delta, Hudi, Paimon), которые привнесли в файловые хранилища «поведение» управляемых таблиц: ACID-операции, версионирование, time travel, эволюцию схем. По сути, файлы в Data Lake получили свойства управляемых DWH-таблиц — это и стало «техническим» триггером для появления Lakehouse.
В числе драйверов со стороны бизнеса я бы выделил экспоненциальный рост объемов и типов данных, выход аналитики за пределы ИТ — в бизнес-подразделения, стремительный рост ИИ и LLM как потребителей данных.
Таким образом, Lakehouse снимает болевые точки обоих лагерей: «дорого и жестко» в DWH, «гибко, но без гарантий» в Data Lake. В результате мы получаем единый масштабируемый фундамент под расширяющуюся воронку аналитических и продуктовых сценариев.
— Как появление Lakehouse повлияло на практики команд?
В. Подречнев: С внедрением Lakehouse данные проходят значительно более короткий путь и быстрее становятся доступными конечным пользователям. Если раньше бизнесу приходилось ждать прохождения долгих и трудоемких этапов обработки, то теперь данные можно получать и использовать из единого «источника правды». В результате они становятся точнее и доступнее, а потребители получают их существенно быстрее.
— Каким функциональным и техническим требованиям должно удовлетворять решение, чтобы считаться полноценной Lakehouse-платформой?
В. Подречнев: Lakehouse базируется на трех ключевых «китах». В основе зрелой Lakehouse‑платформы лежит единый слой хранения данных в открытых колоночных форматах (чаще всего в Parquet), поверх которого реализуется транзакционный табличный слой. Этот слой — будь то Delta Lake, Apache Iceberg, Hudi или Paimon — обеспечивает ACID‑гарантии, версионирование, time travel и эволюцию схем, что позволяет поддерживать согласованность и воспроизводимость данных без их копирования между разными контурами. Физически эти данные находятся в объектных хранилищах, например в MinIO.
Второй обязательный элемент Lakehouse — вычислительный слой с поддержкой классического SQL, способный работать напрямую по таблицам в объектном хранилище. На практике применяются разные SQL‑движки под разные задачи: Apache Spark, Trino, Dremio, StarRocks, Flink, Hive, Impala и др. У каждой технологии есть свои сильные стороны и ограничения: одни лучше подходят для массовых пакетных обработок, другие — для интерактивных запросов с низкой задержкой, третьи — для потоковой обработки или интеграции со сложными open source экосистемами. Конкретный выбор зависит от профиля задач, нагрузки и инфраструктуры.
Третий «кит», который совершенно напрасно не всегда включают в число обязательных, — это слой Data Governance, который позволяет навести порядок в обращении с данными. Его ключевые компоненты — каталоги данных и метаданных, которые позволяют видеть весь путь данных, понимать зону ответственности на каждом этапе, когда и для чего данные появились в системе и как они структурированы. Это помогает не только предотвратить превращение озер данных в «болота», но и повысить эффективность работы с данными.
Важно помнить: технологии работают только при наличии культуры работы с данными и выстроенных организационных процессах. На практике лишь сочетание технологической базы и зрелого Data Governance позволяет построить полноценную и эффективную Lakehouse‑платформу.
— Как вы позиционируете свою платформу?
В. Подречнев: Наш подход: мы «шьем» высококачественные «костюмы» на заказ и не стремимся выйти в масс-маркет. Иначе говоря, мы фокусируемся на проектировании и сборке архитектуры под конкретные задачи, отрасль и инфраструктуру заказчика. Отличия Lakehouse для крупного банка, промышленного холдинга, фармкомпании и ритейлера будут кардинальными: от набора инструментов с акцентом на потоковую обработку до платформы, полностью оптимизированной под обучение ИИ-моделей. Мы всегда начинаем с анализа текущего ландшафта данных, бизнес-процессов, болевых точек, а затем подбираем оптимальный стек технологий, тем самым обеспечивая совместимость, открытый формат и защиту от vendor lock-in.
В отличие от подходов, где клиенту навязывают фиксированный продукт с ограниченным функционалом, мы всегда строим решение на открытых стандартах и интегрируем как мировые open source платформы, так и проверенные коммерческие компоненты. Это позволяет нам быстро реагировать на изменение требований, подключать новые источники, масштабировать инфраструктуру и адаптировать ее без дорогостоящих миграций.
Если же заказчик уже внедрил дорогостоящее проприетарное ПО и удовлетворен этим решением, мы будем рассматривать его как часть целевой системы, чтобы сохранить его инвестиции и тем самым снизить риски.
Как интегратор готовы внедрять и сторонние коробочные платформы, обеспечивая полное сопровождение — от сбора требований на старте до ввода в эксплуатацию и поддержки.
— Что представляет собой архитектура вашей Lakehouse-платформы?
В. Подречнев: В основе нашей платформы — единый физический слой хранения в открытых колоночных форматах (прежде всего Parquet) с транзакционными таблицами поверх него (используем Delta Lake, Apache Iceberg, Hudi и Paimon).
Вычислительный слой подбирается под задачи заказчика, используем конкретные SQL-движки, работающие напрямую по этим таблицам.
Управление осуществляется через инструменты Data Governance.
Платформа строится модульно и развивается как набор заменяемых сервисов вокруг единого контура данных. Мы используем микросервисы, CI/CD и инструменты контейнеризации (Docker, Kubernetes), чтобы независимо масштабировать компоненты, обновлять их без простоя и быстро подключать новые сценарии.
Безопасность и доступность закладываются с самого начала: предусмотрены многоуровневый контроль доступа, аудит, отказоустойчивые развертывания и стандартные протоколы подключения.
Благодаря опоре на открытые форматы и стандартные протоколы архитектура остается независимой от вендоров: компоненты можно менять без пересборки данных и с сохранением их управляемости.
Важный элемент — портал как единая точка входа в систему. Через него администраторы и владельцы данных получают удобный интерфейс как для мониторинга процесса, так и для управления доступами, а также для работы с каталогом данных и метаданными и запуска аналитических и интеграционных сценариев.
В совокупности все это делает Lakehouse-платформу надежной и удобной для повседневной работы команд.
— Какие ключевые проблемы бизнеса закрывает ваша платформа?
В. Подречнев: В числе решаемых платформой задач:
— снижение совокупной стоимости владения данными;
— сокращение времени от появления запроса до получения аналитического результата;
— повышение прозрачности и управляемости информационных потоков;
— подготовка данных в формате ML-Ready для построения ИИ-сценариев.
Такой подход обеспечивает нашим заказчикам не просто современную платформу, которая «пылится на полке», а полноценную рабочую экосистему данных, в которую органически вписаны процессы, люди и технологии.
— Как выглядит типичный путь внедрения: с чем к вам приходят заказчики, с какого минимально жизнеспособного шага вы рекомендуете стартовать?
В. Подречнев: Как правило, заказчики приходят к нам не с запросом «соберите нам Lakehouse», а с конкретным бизнес‑проектом, под который эта архитектура подходит лучше всего. Это могут быть Customer 360, построение корпоративной платформы данных для отдельных подразделений, рекомендательные системы, импортозамещение зарубежных решений или, например, оптимизация регуляторной отчетности. Сценариев масса, формулировки задач различаются, но объединяет их одно: в каждом случае нужно быстрее и эффективнее работать с данными при понятной и устойчивой экономике.
Ограничения тоже почти всегда одинаковые: максимально использовать текущий технологический стек без «капремонта» инфраструктуры, уложиться в бюджет и сроки, чтобы первые ощутимые результаты появились в течение нескольких месяцев и оправдали инвестиции. Важно встроиться в существующие процессы так, чтобы они ни в коем случае не останавливались на время «ремонта».
Обозначенные выше «киты» служат фундаментом для запуска минимально жизнеспособного сценария: заказчик быстро получает ценность и видит, как платформа будет масштабироваться.
Дальнейший маршрут понятен: короткий пилот на приоритетном кейсе, параллельное развертывание каркаса платформы, поэтапное подключение новых доменов и источников с ограниченным периодом сосуществования старого и нового контуров. После этого планируются переключение и вывод из эксплуатации прежних решений.
Больше всего времени уходит не на технику, а на изменение практик работы специалистов. Нужно обосновывать архитектуру перед бизнесом, объяснять экономику и риски привычных подходов, снижать тревожность перед переходом на Lakehouse. Здесь критически важна поддержка руководства: топ‑менеджмент должен зафиксировать стратегический приоритет и цели проекта — тогда у него появляется единый вектор.
Помогает и «безболезненный» режим перехода: обучение ролям (включая владельца данных) и понятные правила в формате «нет данных в каталоге — нет потребления этих данных». Тогда команда видит пользу и понимает, что возврата к прежним процессам, например ручным выгрузкам, уже не будет.
Успех всегда обеспечивают три компонента: быстрый и осмысленный старт на одном сценарии; прозрачная архитектура на открытых форматах с базовым governance; готовность организации к изменениям. Тогда Lakehouse перестает быть очередным ИТ-проектом, «пылящимся на полке», и становится удобным инструментом работы с данными для заказчика.
— Психологическую и технологическую помощь сотрудникам вы полностью берете на себя?
В. Подречнев: Да, мы как интегратор, ориентированный на заказную разработку, всегда берем на себя развитие культуры данных у заказчиков, а также обучение и сопровождение.
— Давайте проведем краткий «разбор полетов» — кейса, где внедрение шло тяжело. В чем был корень проблемы, какие коррективы внесли и какой урок извлекли?
В. Подречнев: Один из самых сложных проектов — оптимизация регуляторной отчетности в крупной финансовой организации. Мы быстро поняли, что главная проблема кроется не в технологическом стеке, а в организационной части. Подготовка данных была распределена между разными командами, ключевые шаги при этом выполнялись вручную, формализации правил на бумаге было крайне мало. Пользователи привыкли работать по устоявшемуся лекалу и не были готовы переходить на новый формат, а политической воли для быстрых изменений на старте не хватало.
Еще один фактор риска — высокая текучесть, вместе с людьми менялись приоритеты и трактовка требований.
В итоге мы выстроили план коррекции, который фокусировался не на коде, а на архитектуре и процессах. Мы детально проработали текущие цепочки данных, зафиксировали каждое ручное преобразование и выстроили сквозной data lineage, чтобы всем было видно, откуда берется показатель и как он трансформируется.
Параллельно согласовали роли и ответственность за домены данных, ввели прозрачные правила публикации наборов данных и окно управления изменениями, чтобы перезагрузить эти требования и снизить уровень хаоса. После этого мы запустили пилот на одном приоритетном отчете, с очень ограниченным кругом потребителей и коротким периодом параллельного режима. Старые и новые контуры работали рядом до формального переключения.
Компромисс заключался в том, что мы существенно сузили первый релиз и перенесли часть запросов на последующие итерации. Взамен мы получили стабильную платформу и предсказуемый процесс изменений.
Главный урок в итоге оказался простым: даже лучшая Lakehouse-архитектура не обеспечивает эффекта без управляемых процессов и поддержки руководства. Когда есть собственники данных, каталоги данных, четкие правила доступа и та самая политическая воля, технология начинает работать в полную силу. Но без этого платформа превращается просто в набор разрозненных инструментов.
— Приведите 2–3 практических кейса из разных отраслей, где Lakehouse дал ощутимую бизнес-ценность.
В. Подречнев: Важно понимать, что архитектура Lakehouse применима в абсолютно разных доменах и отраслях бизнеса. Приведу примеры из принципиально разных областей.
Наше первое знакомство с этой архитектурной концепцией состоялось в 2022 году, во время реализации ML-проекта для страховой компании. Данных и систем было настолько много, а SLA обработки данных были настолько суровыми, что мы быстро поняли: нам нужно делать существенный акцент на эффективном обращении с данными. В итоге мы провели огромное количество экспериментов с разными форматами данных и протестировали множество compute-engines, пока наконец не вышли на необходимый перформанс.
После всех изысканий проект был удостоен награды «Лучшая модель машинного обучения для страховой компании» в конкурсе «Проект года» от Global CIO.
Второй интересный кейс — автоматизация обработки дистрибьюторской отчетности в фармацевтической компании. Данные поступали по почте, через SFTP и API в самых разных форматах, а обработка шла через несколько уровней внутри СУБД: от сырых данных к очищенным и затем к витринам данных. Прохождение такого (до сих пор классического) пути занимало много времени и ресурсов.
Мы решили использовать современный подход и внедрить архитектуру Lakehouse. После этого путь данных стал значительно короче и быстрее, а совокупная стоимость владения снизилась. Конечные потребители этих данных — BI — смогли формировать отчеты на актуальных данных с минимальной задержкой. Также отпала необходимость постоянного физического копирования данных между слоями СУБД.
Третий пример — проект Customer 360 для маркетинга в медицинской компании. Цель — своевременное предложение пациентам персонализированных услуг для повышения их lifetime value. До внедрения Lakehouse команды аналитиков и датасайентистов тратили массу времени на подготовку данных из медицинской информационной системы (МИС) на базе Firebird, которая унаследована и имела значительное ограничение по интеграции.
Мы создали для них единый управляемый слой, интегрировали его с МИС, с каталогом данных, дали этому слою версионирование и возможность публикации готовых наборов данных для аналитики и машинного обучения. Тем самым мы смогли кардинально ускорить итерации в этом ML-проекте и вывести модель в продуктив в существенно меньшие сроки.
Еще один пример — компания из экосистемы крупного банка. В этом кейсе сам заказчик пришел с запросом на внедрение Lakehouse. Задача заключалась в создании виртуального рабочего места для аналитиков, дата-инженеров и датасайентистов. Важным условием были использование корпоративного файлового хранилища и предоставление пользователям возможности подписываться на наборы данных и самостоятельно запрашивать доступы к ним.
В итоге мы внедрили полноценную Lakehouse-платформу, органично встроившуюся в существующую инфраструктуру и обеспечившую безопасность, управляемость и, главное, удобный доступ к данным. Сейчас новые сценарии работы подключаются без переработки хранилища, а процесс получения доступа стал прозрачным и предсказуемым.
— Какими показателями «до/после» можете поделиться?
В. Подречнев: В кейсе страховой компании в результате экспериментов разные подходы показывали десятикратную разницу в перформансе: при неудачной реализации на одной технологии и при качественной на той, что дала лучшие результаты.
При работе с наборами данных в Customer 360 датасайентисты и аналитики сократили время на подготовку витрин с нескольких дней до примерно 1–2 часов — чтобы разобраться с данными и выдать результат.
— Для каких типов нагрузок ваша платформа особенно «сильна»?
В. Подречнев: Lakehouse наиболее эффективен там, где нужно совмещать гибкость Data Lake с управляемостью и предсказуемостью DWH. В первую очередь это аналитика на больших объемах разнородных данных: от классического BI до предиктивных моделей. Если требуется обрабатывать данные в реальном времени, совмещая потоковую и пакетную обработку, Lakehouse позволяет это сделать без громоздких ETL-конвейеров и лишнего дублирования хранилищ.
Второе направление — это проекты, где критична скорость вывода новых сценариев в продуктив: антифрод, персонализированные предложения, мониторинг событий, анализ клиентского поведения. Платформа обеспечивает короткий путь от источника данных до витрины или модели, тем самым сохраняя прозрачность, контроль версий и качество данных.
Отдельно стоит выделить подготовку данных для AI- и ML-треков. Слой ML-Ready — это не просто дополнение к платформе, а часть ее ДНК, встроенная особенность архитектуры. Он обеспечивает чистые и согласованные массивы с версионированием и доступом через стандартные инструменты. Это особенно важно для проектов с LLM или рекомендательными системами, где качество данных напрямую влияет на результат.
Третье направление — задачи банков по построению регуляторной отчетности и интеграции разных подразделений через единую платформу данных. Здесь ценятся не только производительность, но и встроенные механизмы управления доступом, аудит и соответствие требованиям регулятора, что позволяет работать с чувствительными данными без каких-либо компромиссов по безопасности.
— На одном из наших форумов прозвучала идея, что Lakehouse не является панацеей от всех бед. Вы согласны?
В. Подречнев: Полностью поддерживаю такую позицию: Lakehouse — не «серебряная пуля», он не решает всех проблем. В работе с данными сложности, как правило, лежат в плоскости организационных процессов и культуры на стороне заказчика. Эту культуру нужно выстраивать и поддерживать.
Роль технологий — сделать доступ к данным, управление ими и получение аналитических инсайтов максимально удобными. Но технология — лишь инструмент: она помогает, но не даст ответов человеку, который не готов ей пользоваться.
Так что это не панацея, а разумная эволюция технических подходов — очередной виток изменений. Ключ к успеху остается за рамками собственно технологий: в организационных решениях и в том числе в политической воле, которая делает работу с данными стратегией, целью проекта и нормой для всех сотрудников компании.
— Есть ли направления, которые пока еще не «созрели» для использования Lakehouse?
В. Подречнев: Я бы говорил здесь не столько о направлениях, сколько об антипаттернах — случаях, когда Lakehouse не нужен. Любая технология и архитектура уместна лишь в своих сценариях.
Если объем данных исчисляется гигабайтами, а не терабайтами, то есть это не большие данные, Lakehouse не принесет пользы — это стрельба из пушки по воробьям и ошибочный архитектурный выбор.
Если данные строго структурированы, крайне редко меняются и уже построен Data Warehouse, смысла переходить на Lakehouse нет: это будет замена одного на другое без выигрыша.
Если организация не готова менять подходы к работе с данными, выстраивать культуру и процессы Data Governance, то Lakehouse также неприменим. Governance — это ДНК системы: без каталога данных и метаданных Lakehouse быстро превратится в «болото».
Но если все эти условия соблюдены: данных действительно много, компания готова меняться и поддерживать порядок в данных, — тогда Lakehouse оправдан. Спектр решаемых задач при этом колоссален: от дата-инженерии и аналитики до BI- и ML-сценариев.
— Как в платформе обеспечиваются требования безопасности? И есть ли в этом вопросе «грабли», на которые нежелательно наступать?
В. Подречнев: Поскольку мы реализуем не коробочное решение, во всех наших проектах безопасность — это часть архитектуры Lakehouse, которую мы закладываем на самом старте, а не опция «сверху». Мы всегда начинаем с классификации данных и назначения владельца доменов, после чего описываем политики доступа централизованно и применяем их ко всем способам обращения к данным. Как правило, используется ролевая и атрибутивная модель доступа, которая обеспечивает разграничение вплоть до уровня колонок и строк, а также маскирование чувствительных полей. Шифрование включается как на хранении, так и на транзите. Ключи и секреты управляются через корпоративные средства хранения секретов, так чтобы они не попадали в код и тем более в пайплайны.
Важная часть — сам процесс. Заявки на доступ к данным проходят через портал с согласованием, сроками действия прав и обязательным аудитом. Комплаенс-контроль выстраиваем совместно с ИБ банка или другого заказчика либо с его privacy-командой. Конечно же, учитываем локальные требования к персональным данным, журналированию и размещению информации.
Еще один важный аспект — централизованный аудит. Мы фиксируем, кто к каким данным обращался, какие преобразования выполнялись и на основании каких наборов формировалась отчетность. Это поддерживается каталогом данных и data lineage — т.е., по сути, историей происхождения этих показателей.
Также мы используем изоляцию различных сред (dev, test и prod), сетевую сегментацию и раздельные сервисные учетные записи. Для высокой доступности применяем отказоустойчивое развертывание и проверяемые процедуры резервного копирования и восстановления.
«Грабли» в вопросах безопасности, как правило, не технического, а организационного характера. Это могут быть, например, дублирование политик в разных инструментах, серые выгрузки в обход каталогов, избыточные права, которые сотрудники запрашивают «на всякий случай», использование реальных персональных данных в тестовых средах, а также права доступа без сроков и регулярной ревизии. Чек-лист здесь простой: классифицируем данные, выявляем такого рода случаи и искореняем их, чтобы качественно работать как с персональными данными, так и с любой другой чувствительной информацией.
— Как обеспечиваете переносимость и отсутствие vendor lock-in на практике?
В. Подречнев: Как я говорил, мы изначально строим Lakehouse на open source технологиях или проприетарных решениях заказчика. Это классические форматы физического хранения данных — Parquet с транзакционными слоями. Это означает, что сами данные не «заперты» в проприетарной системе и могут быть прочтены любыми совместимыми инструментами (Spark, Trino, Dremio, StarRocks и пр.) в зависимости от потребностей заказчика.
В архитектуре мы закладываем возможность замены компонентов без пересборки и миграции самих данных. Если заказчик внезапно решит перейти на другой SQL-движок или инструмент Data Governance, достаточно просто сменить вычислительный или сервисный слой, оставив хранилище и форматы прежними. Такой подход работает как в локальных, on-premises решениях, так и в гибридных и мультиоблачных инфраструктурах.
Отмечу, что у наших облачных партнеров (Yandex Cloud, MTS Web Services и VK Cloud) используется аналогичная парадигма взаимозаменяемости компонентов под конкретные задачи. Это облегчает переносимость решений между различными средами и расширяет выбор инструментов для заказчика, а в наших проектах мы активно используем эту совместимость для ускорения внедрений и снижения рисков миграции.
Мы также всегда стандартизируем точки интеграции через открытые API и все доступные протоколы, а не через частные узкие коннекторы, которые могут превратиться в «бутылочное горлышко». Это позволяет нам быстро подключать новые источники данных и их потребителей без привязки к конкретному вендору. Для бизнеса это означает снижение долгосрочных рисков и свободу развивать архитектуру под задачи будущего без каких-либо дорогостоящих и затяжных миграций.
— За счет чего достигается снижение совокупной стоимости владения?
В. Подречнев: Lakehouse в первую очередь экономит за счет объединения возможностей классического DWH и Data Lake в одной архитектуре. Мы избегаем дублирования данных в разных контурах, что сокращает расходы на хранение и администрирование. Вместо поддержки двух параллельных платформ появляется возможность использовать единую платформу, которая обеспечивает строгие транзакционные сценарии и одновременно позволяет работать с сырыми данными.
С точки зрения затрат Lakehouse обычно дешевле классического DWH: во-первых, за счет отказа от дорогостоящих лицензий, во-вторых, благодаря снижению расходов на дублирование инфраструктуры. При этом он, как правило, дороже простого Data Lake, поскольку изначально включает транзакционные гарантии, механизмы управления и инструменты воспроизводимости аналитики. Именно этот баланс функциональности и стоимости дает бизнесу максимальную отдачу от инвестиций.
Есть и операционные преимущества: путь данных становится короче, техпроцессы упрощаются, уменьшается количество ручных операций и узких мест. Это ускоряет цикл от запроса до результата и позволяет ИТ-командам фокусироваться на ценности для бизнеса, а не на поддержке сложной инфраструктуры. В итоге бизнес получает прямую выгоду: быстрее выводятся новые продукты, быстрее принимаются решения, а экономия на инфраструктуре не оборачивается потерей функциональности.
Резюмирую: Lakehouse обеспечивает оптимальное соотношение стоимости, гибкости и скорости.
— Что вы считаете следующим этапом эволюции Lakehouse?
В. Подречнев: Lakehouse, несмотря на интерес и хайп вокруг него, только выходит на свое плато эффективности и стадию широкого промышленного применения. Сегодня многие компании находятся на этапе пилотов и первых внедрений, а впереди — массовый переход к полноценной эксплуатации. Важно не просто идти в ногу со временем, но и закладывать архитектуру так, чтобы она оставалась актуальной и через пять, и через десять лет.
Если раньше главной задачей было собрать и структурировать данные, то сейчас мы умеем знать о них все — от происхождения до качества. Следующий этап — формирование зрелой культуры работы с данными внутри компаний и резкое снижение порога входа. Считаю, что работа с информацией должна быть такой же нативной и удобной, как пользование смартфоном: понятные интерфейсы, минимум технических барьеров, уверенность в корректности результатов.
Вероятность ошибочных выводов при работе с данными будет снижаться за счет встроенных проверок, автоматизированного контроля качества и появления нативного языка общения с данными, когда запрос можно сформулировать обычным человеческим языком. Архитектурно это приведет к новому витку демократизации доступа — данные перестанут быть прерогативой узкого круга специалистов и станут органичной частью повседневной работы каждого сотрудника и каждого подразделения.
— Можете поделиться своими идеями развития этого направления?
В. Подречнев: Все это уже активно тестируется, и не только нами: в этом направлении работают многие крупные компании и вендоры. Если вы зададите ChatGPT или другой LLM вопрос по загруженному файлу, модель обязательно сформулирует ответ. Однако далеко не все решения, позволяющие вести диалог с данными на нативном языке, сегодня доступны в on-premises сценариях. Кроме того, требования комплаенса и корпоративных стандартов часто не позволяют загружать в такие сервисы чувствительную информацию.
Поэтому многие организации разворачивают крупные языковые модели на внутренних серверах: это уже сейчас дает возможность общаться с данными привычным человеческим языком. Рынок движется именно в эту сторону — идут пилоты и первые эксперименты, но эволюция займет время. Нас ожидает очень интересный виток демократизации данных и развития data-вселенной.
Источник: http://futurebanking.ru/post/4180
Вам также может понравиться
