Назад в ленту

Zillow раскрыла секрет успешного AI: Контекст, когортный анализ и Langchain

Инженеры Zillow поделились ключевыми уроками внедрения искусственного интеллекта в enterprise, подчеркнув важность постоянного контекста, анализа пользовательских когорт и роли человека в цикле обучения.

VB Transform 2026 собрал в одной комнате инженеров Zillow, Glean, LangChain, Conviva и CoreWeave, и за два дня они успели перевернуть привычные представления о том, как строить и оценивать ИИ-агентов в enterprise. Главный вывод? Данные — не проблема, контекст — да. А ещё — ни одна, даже самая идеальная оценка отдельного разговора не спасёт, если продукт сломан на уровне когорт. И финальный аккорд: человек в контуре никуда не денется, пока ИИ не научится брать на себя юридическую ответственность. Вот три ключевых урока с конференции.

Контекст и данные: ключевые принципы построения AI-архитектуры

Представьте: ваш клиент ищет дом через Zillow. Месяц он листает объявления в телефоне, потом украдкой заглядывает с работы, затем звонит кредитному специалисту, встречается с риелтором — и ожидает, что вся история поиска, предпочтения и отфильтрованные варианты плавно перетекут за ним в каждый следующий шаг. Хотите чат-бота, который удержит эту нить диалога? Ха, не выйдет. Любой отдельный болванчик сломается уже на второй неделе.

Именно это поняли в Zillow, когда взялись за AI-архитектуру. Тоби Робертс, SVP инженерии, на VB Transform 2026 признался: «Мы довольно быстро определили, что нам понадобится слой постоянного контекста, который будет сопровождать наших клиентов и профессионалов, где бы они ни находились». И вот ирония судьбы — подготовка данных, вся эта возня с data mesh, lineage и правами доступа оказалась не сложной. Трудность номер один — заставить систему помнить, кто вы и где остановились месяц назад, на каком бы устройстве ни включились сегодня.

Zillow не стал играть в «одну модель, чтобы править всеми». Команда оперлась на 20-летний опыт машинного обучения (Zestimate всё-таки не пальцем делан), но пошла другим путём: россыпь мелких, узко заточенных моделей вместо монстра-универсала. Внутренняя обвязка работает в паре с Glean. Как рассказал Арвинд Джайн, CEO Glean, у них уже «тысячи агентов в продакшене, выполняющие десятки тысяч операций по всей компании». Вся их магия — централизовать одноразовые интеграции, чтобы юристы, финансисты и маркетологи не строили каждый свой велосипед для одних и тех же корпоративных систем.

Но самое сольное — это контроль стоимости. Джайн назвал два рычага, о которых многие забывают: маршрутизация моделей (не гонять каждую мелочь через топовый Claude, а слать на маленькие дешёвые модели) и предварительно вычисленный контекст. Его цитата — чистый перл: «Claude очень медленный, потому что первая фаза сборки контекста занимает вечность. Маршрутизация через Glean может сократить потребление токенов вдвое». Вдумайтесь: можно уполовинить счёт за API просто умным управлением контекстом, а не добавлением очередной нейросетки.

Робертс добавил типично инженерную мудрость: «40% увеличение поставленного кода, которое мы связываем с внедрением AI, стало возможным только потому, что мы годами собирали baseline по DORA-метрикам до начала AI-толчка». То есть сначала меряй, потом — строй. Никакого хайпа, только байтодрочерство с выдержкой.

Вывод на этом этапе прост: не пытайтесь скормить LLM всю историю клиента в один промпт. Вам нужен persistent context layer, свои fine-tuned модельки под каждую задачу и жёсткий контроль того, на какой модели что считать. Иначе деньги утекут на токены быстрее, чем вы скажете «Zestimate».

Оценка AI-агентов: от отдельных трасс когортному анализу

Когда отдельная трасса AI-агента выглядит безупречно, а продукт всё равно сыпется — начинается самое интересное. Индустрия медленно, но верно отказывается от оценки изолированных диалогов в пользу сравнения целых когорт пользователей с базовым уровнем. Метод, который Хуэй Чжан из Conviva называет контрастным анализом — что-то вроде contrastive analysis of English and Russian, только вместо языков тут пользовательские сессии и скрытые аномалии.

Харрисон Чейз из LangChain высказался жёстко: «Eval'ы — это новый PRD». Иными словами, тесты превратились не в чек-лист перед релизом, а в живую спецификацию продукта, которая определяет, чего агент должен делать, а чего — нет. Проблема в том, что 100% покрытие не спасает. Эммануэль Тюрле из CoreWeave признался: «Я пытался добиться полного покрытия тестов, а баги всё равно вылезали в продакшене». Знакомая боль, да?

Дилемма судьи: человек или машина?

Чжан сформулировал выбор, от которого волосы встают дыбом: «Автоматическая оценка масштабируема, но необоснованна. Человеческая — обоснованна, но не масштабируется». Вся отрасль сейчас выбирает, от какого яда умереть. Но контрастный анализ даёт лазейку: вместо того чтобы гадать, хороша ли каждая отдельная трасса, можно сравнить когорты пользователей с базой. Пример из ритейла: когда покупатель просит кроссовки для полумарафона, агент задаёт уточняющие вопросы. Каждый такой диалог по отдельности — огонь. Но если посмотреть на всю категорию, коэффициент уточняющих вопросов оказался в три раза выше базового, а доля покупок вне диалога — в пять раз. Ни один единичный трейс этого не покажет.

Цена судьи: от гигантов до Qwen и регулярных выражений

Тюрле советует начинать с самой мощной модели, чтобы доказать, что задача вообще решаема. А потом — уменьшаться. Если топ-модель не справляется, мелкая подавно ляжет. Когда решение найдено, можно сэмплировать только часть трафика, а простые задачи (вроде бинарной классификации) отдавать маленьким open-source моделям. LangChain пошёл дальше: дообучил модель Qwen (из семейства Alibaba) распознавать, когда пользователь считает, что агент ошибся. Результат — на уровне Claude Sonnet, но с затратами в 10–100 раз ниже. Чейз добавляет, что не всякий гардрейл требует модели: «В Claude Code половина защит — это просто регулярные выражения». Иногда самый дешёвый судья — это regex.

Человек в контуре: доверие и ответственность

Автоматизация автоматизацией, но кто ответит, если агент наворотит дел? Судя по дискуссии на VB Transform 2026, эта ответственность пока что прочно лежит на человеке. Эммануэль Тюрле из CoreWeave, вспоминая работу над беспилотниками, привёл железобетонный аргумент: даже при двухнедельном цикле обновления модели — от сбора данных до поставки в автомобиль — финальное «добро» всегда ставил человек. «Я был готов от имени компании заявить: эта модель должна поехать в машину», — объяснил он. И это правило напрямую переносится на юридические, финансовые и медицинские сценарии. Пока агент не может сказать «я несу за это юридическую ответственность», человек остаётся незаменимым звеном.

Доверие строится на взаимодействии

Харрисон Чейз из LangChain добавил к этому ещё один важный штрих: человек в контуре нужен не только как страховка, но и как источник обучения. «Человек в цикле невероятно важен для построения доверия к этим агентным системам, а также для запоминания и обучения системы, — подчеркнул он. — Должны быть взаимодействия, чтобы система могла учиться». Хуэй Чжан из Conviva согласился: человек обязан оставаться стражем на граничных случаях, даже если автоматизация на массовых сценариях превосходит индивидуальную точность — машины видят больше паттернов.

Не все guardrails требуют нейросетей

Любопытно, что Чейз обратил внимание и на обратную сторону вопроса: не каждый защитный механизм должен быть «умным». Он привёл в пример Claude Code, где значительная часть guardrails — это просто регулярные выражения. «И это не маленькие LLM, а просто regex'ы», — заметил он. Простой, но эффективный подход, который лишний раз напоминает: иногда для контроля над агентами не нужна сложная модель — достаточно хорошо написанного правила.

Путь к продуктивному ИИ в бизнесе — это не гонка за самой большой моделью. Zillow, Glean и их коллеги показали, что настоящий прорыв лежит в трёх плоскостях: контекст, который тянется через весь путь пользователя; оценка, которая смотрит не на отдельные трассы, а на когорты; и, наконец, человек, который остаётся и стражем, и учителем для системы. Без любого из этих элементов enterprise-агенты рискуют остаться дорогой игрушкой, а не рабочим инструментом.

Справка по теме (FAQ)
Что такое "persistent context layer" и зачем он нужен?
В статье говорится, что "persistent context layer" (постоянный слой контекста) необходим для того, чтобы система могла помнить информацию о клиенте и его взаимодействиях на протяжении длительного времени и на разных устройствах. Zillow столкнулась с проблемой сохранения контекста пользователя при переходе между разными платформами и каналами, и этот слой помог решить эту задачу.
Как оценить работу AI-агента, если отдельные диалоги выглядят хорошо, но продукт в целом не справляется?
Вместо оценки отдельных диалогов, рекомендуется использовать когортный анализ, сравнивая поведение групп пользователей с базовым уровнем. Этот подход, названный "контрастным анализом", позволяет выявить скрытые аномалии и проблемы, которые не видны при анализе отдельных трасс. Например, если процент запросов на уточнение информации у пользователей, взаимодействующих с агентом, значительно выше базового, это может указывать на проблему.
Какие модели использовать для оценки AI-агентов и как оптимизировать затраты?
Начинать стоит с самой мощной модели, чтобы определить, вообще ли решаема задача. Затем можно уменьшать размер модели, пока не будет найдено решение. Для простых задач, таких как бинарная классификация, можно использовать небольшие open-source модели. Также, для защиты от нежелательного поведения можно использовать простые регулярные выражения, как это делается в Claude Code.
Почему человек остаётся важным звеном в работе с AI-агентами?
Несмотря на автоматизацию, человек необходим для обеспечения юридической ответственности за действия агента. Пока AI не сможет самостоятельно нести ответственность, окончательное решение всегда должно оставаться за человеком. Кроме того, человек важен для обучения системы и построения доверия к ней, особенно в сложных и граничных случаях.