14 терабайт из-за пустой даты: внедрение ИИ ломается не на модели

В 2013 году Palantir поставила в банк хранилище транзакций Phoenix. По словам Виноо Ганеша, проектировали его одни из лучших инженеров, с которыми он работал, и в каждой среде, которую команда контролировала, система вела себя ровно по спецификации. В боевых данных банка нашлась пустая отметка времени. Пустоту система прочитала как 1 января 1970 года, и логика хранения честно запросила десятиминутный блок на каждый интервал с той даты по сегодня: около 2,3 миллиона пространств ключей, при том что Cassandra под ними требовала примерно пять мегабайт на каждый файловый дескриптор. Сервер лёг с нехваткой памяти; чтобы поднять его снова, понадобилось бы 14 терабайт оперативки.

Ганеш сейчас руководит Kepler, до этого работал в Palantir и Citadel и трижды строил функцию «инженер внутри клиента» — forward deployed engineer, FDE; через его ротацию Project Frontline в Palantir прошло около 250 человек. История с Phoenix в его тексте для Latent Space не про плохую модель данных. Она про то, что никто со стороны продукта не стоял в здании банка, пока система работала на настоящих данных.

Спецификация была, не было никого внутри здания

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

Эту сцену я узнаю без перевода. У нас вместо Cassandra — 1С, а вместо пустой отметки времени — контрагент, заведённый тремя карточками, или остатки, которые «на самом деле» лежат в Excel у кладовщика. В проектах с ИИ и автоматизацией языковая модель ломается последней. Раньше неё ломаются справочники и неписаное правило, чьей цифре верят, когда 1С и CRM расходятся.

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

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

Такое не выясняют на созвоне. Для этого надо сидеть рядом.

Год уговоров против одного вечера наблюдения

Самый полезный эпизод в тексте — маленький. В одном из прошлых стартапов Ганеша почти год не могли перевести клиента с CSV на Parquet, более компактный формат хранения. Блокировала одна инженер по качеству данных, и причина каждый раз звучала иначе: «Parquet хуже», «так не работает», «мне это непонятно».

Потом к ней отправили инженера просто посмотреть, как она работает. Она скачивала CSV из S3 на ноутбук с Windows, открывала двойным кликом и глазами просматривала строки. Это и была проверка качества данных. У Parquet тогда не было просмотрщика, то есть команда год предлагала забрать у человека единственный инструмент и ничего не дать взамен. Просмотрщик написали за вечер, через два дня она согласовала миграцию, обработка ускорилась примерно с семнадцати часов до двух.

Сопротивление внедрению почти никогда не про страх нового — оно про инструмент, который у человека отбирают. Пока вы не увидели, что именно он открывает двойным кликом перед тем, как подтвердить цифру, вы не знаете, что внедряете. По моим прикидкам, в компаниях на 50–300 человек такой «двойной клик» есть в каждом втором процессе — от сверки остатков до счёта, который бухгалтер глазами проверяет перед оплатой. Это ощущение от проектов, не цифра из исследования.

Скрипт на полдня прожил годы и получил имя автора

Вторая история неприятнее. Одному клиенту понадобилась задача по срокам хранения данных, и Ганеш за полдня набросал скрипт vinoo.groovy, которому полагалось не дожить до конца недели. Через год скрипт крутился у клиента почти на сто тысяч человек, с именем автора в названии; команда так и прозвала самого Ганеша. Дыру закрыли, починку в продукт не вернули и годами обслуживали костыль.

Отсюда развилка, которую я бы повесил на стену любому подрядчику по автоматизации. Без платформы под работой ты изучил модель одной компании, собрал под неё решение и потерял всё, когда проект закрылся; следующий клиент начинается с нуля. Это консалтинг: он хорошо оплачивается и не накапливается. С платформой каждая изученная компания делает следующее внедрение быстрее. Самая злая фраза текста: по наблюдению Ганеша, большинство участников нынешней золотой лихорадки строят первое, а совету директоров описывают второе.

Подрядчик, который только закрыл дыру, оставил вам свой vinoo.groovy

Оговорка про маркетинг: Ганеш продаёт Kepler, платформу, где у каждой цифры есть происхождение, и рассуждение о «рве» заодно обосновывает его продукт; сам я Kepler не трогал. Развилка от этого не перестаёт быть правдой, и собственника она касается с другой стороны стола.

Вы покупаете внедрение. Подрядчик, который только закрывает дыру, оставляет вам обработку в 1С или сценарий в Bitrix24, которые живут, пока не уволился автор и не поменялся справочник. Подрядчик, который возвращает найденное в свой шаблон, во второй отдел и во второй проект приходит уже с правильными вопросами, и это выходит вам дешевле. Ганеш об этом пишет жёстко: когда три фирмы просят одну фичу, это стоит мало; ценный сигнал — когда три фирмы упираются в одно и то же ограничение платформы.

Я бы требовал от подрядчика двух вещей до разговора о моделях. Первая — письменный словарь существительных и глаголов вашего процесса: как одну сущность называют в 1С, в CRM и у бухгалтерии, где стоит проверка глазами и кто её делает. Вторая — список его костылей у вас с датой смерти каждого. У нас в проектах слово FDE никто не произносит, но работа та же: сначала сесть рядом с человеком, который сверяет глазами, и только потом обсуждать, чем это автоматизировать.

Шаг на неделю: попросите подрядчика или своего внутреннего внедренца собрать за день перечень временных обработок и ручных обходов, которые стоят у вас сейчас, с именем автора и датой, когда каждый должен умереть. Если список не появился за день, vinoo.groovy у вас уже есть, просто пока без имени.