25 августа LinkedIn раскрыла, как устроена память ИИ-агента в ее hiring-ассистенте для рекрутеров: вместо модного GraphRAG компания собрала четырехслойную систему памяти и уложила ее в жесткий бюджет по задержке. Для русскоязычной IT-аудитории это важный кейс не про красивое демо, а про то, как агенту дают долговременное состояние, не превращая каждую пользовательскую сессию в дорогое и медленное шоу с LLM.
О подходе рассказал Praveen Bodigutla, Principal AI Researcher в LinkedIn, в разговоре с Ryan Donovan, сообщает Stack Overflow Blog. По его словам, отправной точкой стал уже запущенный hiring assistant: рекрутеры в диалоге с агентом формулируют требования к вакансии, уточняют навыки, меняют локацию, отбрасывают одних кандидатов и возвращаются к другим. Эти сигналы не исчезают после закрытия вкладки. Наоборот, у них есть «липкость»: если рекрутер нанимает на похожие роли, предпочтения часто переносятся дальше. Из этого и выросла идея дать агенту не просто контекст текущего чата, а устойчивое персонализированное состояние.
LinkedIn разбила эту систему на четыре слоя. Первый слой — разговорная память: что пользователь сказал прямо сейчас и в ближайшем контексте. Второй — эпизодическая память: недавние релевантные действия с временной привязкой и возможностью понять, откуда именно взялся тот или иной вывод. Третий — процедурная память: как конкретный рекрутер принимает решения и какие компромиссы обычно выбирает, например что для него важнее — локация, seniority или сочетание навыков. Четвертый — семантическая память: агрегированные предпочтения пользователя, собранные уже не только из одного диалога, но и из взаимодействий на разных поверхностях LinkedIn, включая поиск кандидатов. В сумме память ИИ-агента перестает быть просто логом переписки и становится отдельным уровнем персонализации.
Самая практичная часть этой истории — не слои как таковые, а инженерные компромиссы под капотом. В LinkedIn прямо говорят, что пробовали строить долгосрочную память через GraphRAG, но отказались: подход оказался медленным и дорогим, потому что требовал много вызовов LLM для поиска связей между узлами и фактически заставлял заново перестраивать индекс памяти. Для системы масштаба LinkedIn такая роскошь быстро превращается в счет за облако и в лишние секунды ожидания. Вместо этого команда перешла к древовидной иерархии. В кейсе hiring assistant она ложится на доменную логику почти без насилия: у рекрутера есть проекты, у проектов — собственные предпочтения, выше — уровень самого рекрутера, а еще выше — когорта, например группа рекрутеров внутри одной компании, которые работают с похожими ролями. Такая структура позволяет обновлять только конкретную ветку или лист, а не перебирать всю память целиком.
Отдельная боль — свежесть данных. В рекрутинге пользователь легко меняет мнение по ходу процесса: еще пять минут назад искали кандидата в одном регионе, теперь нужен другой; сначала важен один стек, потом уже приоритет у комплементарных навыков. Поэтому retrieval-слой должен не просто находить похожее, а разруливать конфликты и отдавать приоритет наиболее свежим сигналам. В LinkedIn для этого совмещают онлайн-ingestion, retrieval-сервис и офлайн-консолидацию, которая убирает дубли, подтягивает внешние источники и чистит устаревшие данные. Bodigutla отдельно упоминает простые политики старения: если часть информации старше шести месяцев или года, она может уже не жить в оперативной части памяти, потому что сжата и перенесена в долгосрочное представление. Логика здравая: не тащить весь цифровой багаж пользователя в каждый ответ только потому, что он когда-то это сказал.
Есть и вторая реальность любой enterprise-системы: доступы. Если агент начинает помнить не только одного пользователя, но и сигналы уровня команды или компании, вопрос «кто это вообще может видеть» становится важнее красивых слов про персонализацию. В LinkedIn говорят, что память помечается владельцами и правами доступа, а на каждом шаге в workflow передаются корректные credentials, чтобы агент не читал больше, чем положено. Иначе любой «умный рекрутерский ассистент» очень быстро превращается в юридическую проблему с интерфейсом чата.
По скорости у команды тоже не романтические ожидания, а вполне жесткие рамки. На память отводится только 10-20% общего latency budget ответа приложения, потому что агенту еще нужно забрать данные из других систем и собрать итоговый ответ пользователю. Отсюда и решения, которые многим разработчикам покажутся знакомыми: меньше последовательного планирования, больше параллельного выбора нужных memory tools за один шаг, selective LLM calls только там, где без них никак, структурированные ответы вместо бесконтрольного разматывания reasoning tokens. На инфраструктурном уровне упоминаются оптимизации в vLLM вроде prefix cache и chunk prefill. Переводя с языка архитектурных диаграмм на нормальный: если можно не звать модель лишний раз, ее не зовут.
Для разработчиков этот кейс полезен сразу в двух плоскостях. Во-первых, он отрезвляет разговоры о «памяти агента»: долговременная память — это не один векторный индекс с красивым названием, а набор разных представлений, у каждого своя роль, срок жизни и цена ошибки. Во-вторых, LinkedIn показывает, что доменная структура данных важнее универсальной моды. Если предметная область естественно складывается в дерево, не нужно насильно натягивать на нее граф только потому, что графы красиво смотрятся в презентациях. Для бизнеса вывод тоже довольно прямой: персонализация в агентных продуктах начинает работать только тогда, когда память умеет обновляться инкрементально, учитывать свежесть и не ломать модель доступа.
Следующий большой вопрос здесь не в том, смогут ли все крупные платформы добавить агентам долговременное состояние, а в том, какая архитектура переживет рост числа сценариев. Пока у LinkedIn все выглядит убедительно в рекрутинге, где есть естественная иерархия проектов, ролей и когорт. Но чем шире агент выходит за рамки одного workflow, тем труднее удержать баланс между полезной персонализацией, стоимостью обновлений и правом пользователя не жить в бесконечной памяти продукта.