Настоящий разрыв в enterprise AI — не в доступе к моделям, а в умении выстраивать retrieval, evaluation, memory и governance в скучные, воспроизводимые системы.
На этой неделе в Нью-Йорке моя команда Oracle провела для enterprise-разработчиков воркшопы по retrieval-augmented generation и agentic applications. Интерес был настолько высоким, что нам пришлось срочно думать, как удвоить вместимость зала — к явному неудовольствию пожарного инспектора. Интерес к ИИ был зашкаливающим. Но AI fluency — нет. И аудитория, и атмосфера заметно отличались от того, что мы видели на курсе, который мы сделали вместе с DeepLearning.ai и который привлекает более продвинутую аудиторию, готовую строить memory-aware agents.
Я недавно утверждал, что enterprise AI внедряется неравномерно — между компаниями и даже между командами внутри одной компании. Но после того как я увидел, как разработчики проходят через эти разные воркшопы, я пришел к выводу, что эта неравномерность говорит о еще более важной вещи: о неравномерной engineering capability.
Иными словами, реальный разрыв в enterprise AI — не просто между компаниями, которые движутся быстро, и компаниями, которые двигаются медленно. Он между командами, которые воспринимают AI как prompt-driven demo, и командами, которые болезненно учатся тому, что production AI — это в основном data engineering и software engineering задача. Enterprise AI пока не в agent era. Мы все еще в prerequisite era.
Building the building blocks
Что я имею в виду под engineering capability? Я точно не имею в виду доступ к модели. Он есть почти у всех — или скоро будет. Нет, я имею в виду практические дисциплины, которые превращают модель в систему: data modeling, retrieval, evaluation, permissions, observability и memory. То есть все то неприглядное, «скучное» и неэффектное, благодаря чему enterprise-проекты, особенно enterprise AI-проекты, вообще могут взлететь.
Именно это повлияло на то, как моя команда строила воркшопы. Мы не начали с «вот как построить автономного сотрудника». Мы начали с AI data layer: heterogeneous data, multiple representations, embeddings, vector indexes, hybrid retrieval и с компромиссами между разными типами данных — relational, document и так далее. Иными словами, мы начали с того, что большинство AI-маркетинга старается пропустить. Похоже, значительная часть AI-мира думает, что AI начинается с prompt, хотя на деле все начинается с таких вещей, как multimodel schema design, vector generation, indexing и hybrid retrieval.
Это важно, потому что enterprise data не бывает аккуратным. Она живет в tables, PDFs, tickets, dashboards, row-level policies и в 20 годах организационной импровизации. Если вы не умеете моделировать этот хаос для retrieval, у вас не будет enterprise AI. Вы просто получите отполированный autocomplete system. Как я уже отмечал, трудность не в том, чтобы заставить модель звучать умно. Трудность в том, чтобы заставить ее работать внутри странной, специфичной для компании реальности, где принимаются настоящие решения.
Например, индустрия говорит о retrieval-augmented generation так, будто это просто feature. Это не feature. Это engineering discipline. Chunking strategy, metadata design, retrieval quality, context packing, precision and recall, correctness and relevance — это не детали реализации, которые можно доделать потом. Это и есть суть. Если retriever слабый, модель будет уверенно развивать плохой контекст. Если chunking сделан небрежно, качество ответа ухудшится еще до того, как модель начнет рассуждать. Если metadata слишком бедная, ломается filtering. А если у вас нет evaluation loop, вы не узнаете ни об одном из этих проблем, пока пользователь не скажет, что система ошибается.
Именно здесь permissions и observability становятся критически важными. В демо никто не задает неприятные вопросы вроде того, откуда взялся ответ или к чему агент вообще имел право прикасаться. Но в production такие вопросы и составляют всю игру. Enterprise-agent с расплывчатым tool access — это не sophistication, а огромная security problem. Если коротко: пользоваться AI tools — не то же самое, что уметь строить AI systems. Многие команды умеют prompt, но гораздо меньше команд умеют измерять retrieval quality, отлаживать context assembly, задавать границы инструментов или строить feedback loops, которые действительно улучшают систему.
Catching up with the enterprise
Здесь полезно сравнение с недавним коротким курсом DeepLearning.AI по agent memory. Этот курс явно рассчитан на разработчиков, которые хотят выйти за пределы single-session interactions, и предполагает знакомство с Python и базовыми концепциями large language models. Иными словами, эта аудитория уже находится выше по кривой обучения и рассматривает memory-aware agents как следующий шаг. В отличие от нее, моя нью-йоркская, сильно enterprise-ориентированная аудитория в целом была на более раннем этапе пути. Это не критика enterprise-разработчиков. Это подсказка. Значительная часть «AI gap» в enterprise связана не с нежеланием, а с тем, сколько явного обучения командам еще нужно пройти, прежде чем инструменты станут мышечной памятью.
Именно поэтому я снова и снова возвращаюсь к более старому аргументу, который я уже высказывал о MLops. Тогда я писал, что machine learning становится сложным в тот момент, когда выходит из notebook и попадает в мир tools, integration и operations. Это было верно в 2022 году, и сейчас это верно еще больше. Agentic AI не отменил базовый закон enterprise software. Он просто добавил больше moving parts и расширил blast radius. Демо, возможно, стало проще, чем когда-либо, но система — определенно нет.
Я бы также предостерег от того, чтобы говорить enterprise-компаниям, что они «отстают» только потому, что еще не приняли multi-agent architectures или какую бы то ни было очередную модную схему. Во многих случаях они как раз учатся тому, что им действительно нужно знать: как структурировать данные для retrieval, как оценивать outputs, как ограничивать tools, как разбирать failures и как управлять state. Это, возможно, не годится для эффектных конференционных докладов. Зато это подозрительно похоже на то, как строятся реальные платформы. Как я уже писал, большинству команд нужно не больше архитектурной хитрости, а гораздо больше engineering discipline.
Так что да, неравномерное внедрение по-прежнему реально. Но, на мой взгляд, более глубокая и полезная история выглядит так: неравномерное внедрение — это в основном поверхностное проявление неравномерной AI engineering literacy. Настоящие победители в AI — это те, кто научит свои команды привязывать модели к business data, оценивать то, что эти модели возвращают, ограничивать то, что agents могут делать, и запоминать только то, что действительно важно. Иными словами, победителями станут те, кто умеет делать AI скучным.
Прямо сейчас скучное распределено очень неравномерно.
Материал — перевод статьи с английского.
Оригинал: AI has to be dull before it can be sexy