Transcription
Хорошо, спасибо всем. Извините за ожидание. Эм, это будет немного странная сессия, потому что, эм, в ней есть компонент мастер-класса. Так что, э, я думаю, все будут кодить на своих ноутбуках. Извините. Эм, но в любом случае, извините. Я Питер, и это мой коллега Брэндон. Эм, так что мы разобьем эту сессию на две разные части. Одна — это, эм, своего рода доклад, который я собираюсь сделать о том, для чего полезны контекстные движки и как вы можете построить один, о чем стоит подумать. Эм, а затем мы перейдем ко второй части. Итак, эм, кратко, эм, быстрая повестка дня. Мы поговорим о трех мифах, которые сейчас циркулируют, об эм, контекстных движках, а затем я расскажу о паре уроков или нескольких уроках, которые мы извлекли в процессе создания одной из этих вещей. Эм, а затем, наконец, мы сделаем это. Мы построим граф социальной инженерии. Это компонент, который очень полезен в контекстном движке. И сначала просто поднимите руки. Все ли понимают, что я имею в виду под контекстным движком, или кто-нибудь хочет уточнения по этому поводу? >> Хорошо. Итак, эм, в мире ИИ-агентов, эм, у вас есть агенты, которые, эм, когда вы начинаете и начинаете кодить, они, по сути, находятся на нулевом уровне. У них нет контекста о вашем коде, вашей организации, ничего. Хорошо. Так что обычно происходит то, что первое, что они делают, это начинают рыскать по вашей кодовой базе, эм, на основе задачи, которую вы им даете, чтобы получить некоторое понимание, эм, своего рода фоновое понимание, прежде чем они начнут выполнять свою задачу. Так что контекстная инженерия — это своего рода искусство предоставления всего необходимого контекста и, самое главное, всего контекста, который вам не нужен, в высокооптимизированном виде, чтобы, когда агент начнет работать, он выполнял задачу, эм, в упорядоченном виде, который соответствует лучшим практикам и ожиданиям вашей организации и так далее. Хорошо, мы доберемся до этого позже. Итак, не так давно, как четыре года назад или меньше, эм, вы были контекстным движком. Хорошо? Так что, когда вашему агенту что-то было нужно, эм, вы бы давали ему подсказку, вы бы брали билет с задачей, вы бы передавали ему всю информацию, которая ему нужна, чтобы начать свою задачу. И во многих случаях, даже когда он рыскал, получая фоновый контекст, когда он доходил до конца своей задачи, иногда он ошибался. На самом деле, во многих случаях так и было. И вам приходилось как бы сбрасывать его. Эм, направлять его снова к решению, которое вы имели в виду. Эм, или если он полностью промахнулся, вам приходилось говорить: «Нет, не JavaScript, дурак. Это исходный код на Python, на который я хочу, чтобы ты посмотрел». Эм, так что давайте просто вспомним, как вы строили контекст в организации. Эм, так что мы на секунду убираем ИИ из картины. И я просто хочу, чтобы вы представили, что до ИИ вы только что присоединились к организации, давайте вспомним, как мы ее строили. Так что со временем вы бы накапливали этот своего рода контекст через опыт, верно? Вы бы начинали работу, возможно, немного копались бы в коде, чтобы понять, эм, эм, как все работает. Вы бы, возможно, нашли наставника. Эм, и в конечном итоге вы бы испытали реальные вещи, такие как инциденты и сбои, и тому подобное. Это своего рода болезненные вещи, которые остаются с вами. Это боевые шрамы, верно? И это то, что составляет организационный контекст. Это, эм, это уроки, извлеченные в процессе, почему мы делали вещи так, как мы их делали. И теперь вы хороши в своей работе, потому что, эм, после всего этого опыта боли, теперь вы знаете, какие вопросы задавать. Вы знаете, куда смотреть, когда происходит инцидент. И это цель. Это то, чего мы хотим добиться для наших ИИ-агентов. Итак, эм, я просто возьму эту кривую принятия из Вимата. И, эм, я, возможно, исказил его фамилию, но извините, Вим, если вы это увидите. Эм, так что давайте начнем с начала. Это было примерно четыре года назад, в 2022 году. Все помнят модное автодополнение, верно? Эм, в те дни контекстные окна и ИИ были довольно ограничены. Я не уверен, помнит ли кто-нибудь это, но это было около 8 килобайт или, скорее, 8 тысяч токенов. И это не так уж много. И поэтому токены были высоко оптимизированы, а эм, агенты, такие как Cursor, фокусировались только на коде, который окружал эм, код, в который вы хотели войти и автодополнить. Так что, по сути, они брали какой-то код до, какой-то код после, помещали его в модель и говорили: «Этот пользователь работает над этим фрагментом кода, что наиболее вероятно дальше?» И это то, что выводилось. Эм, это постепенно улучшалось, поскольку мы интегрировали эм, языковые серверы, и тогда вы могли, по сути, извлекать, эм, блоки исходного кода и помещать все это в контекст, а затем LLM были очень хороши в завершении кода. Эм, так что на этих уровнях вы были контекстным движком, и, эм, во многих, во многих случаях здесь это своего рода то, где большинство людей находятся. Они находятся на, эм, параллельных агентах, подключенных к MCP и навыкам. Хорошо. Просто очень любопытно, выходил ли кто-нибудь за пределы курируемого контекста в последние несколько градусов, эм, агентской свободы, скажем так, где у вас есть фоновые агенты, работающие в облаке, делающие вещи в режиме YOLO. Экспериментирует ли кто-нибудь с этим? Хорошо, здорово. Это очень здорово. Это передовая технология. Эм, но давайте на мгновение признаем, что передовая технология сегодня — это новости вчерашнего дня через шесть месяцев. Хорошо. Так что, шайба, я канадец, так что я скажу это, шайба идет вниз по линии к фоновым агентам, безусловно. Эм, и одна из вещей, с которой мы сталкиваемся прямо сейчас, это это. Мы становимся узким местом как люди, верно? Я не уверен, пытались ли люди управлять параллельными агентами и работать над несколькими задачами одновременно, но все начинают чувствовать этот, эм, когнитивный разрыв, потому что вы постоянно переключаете контекст, и это просто, это просто очень, очень болезненно. Эм, очень трудно перейти от того режима, где вы, человек, управляете контекстом, к режиму фоновых агентов, если у вас нет какого-либо контекстного движка, который знает, как работает ваш код, как работает ваша организация и понимает мотивы исторических изменений и тому подобное. Итак, Эндрю, Андре, он попал в точку. Эм, системы интеллектуальны. Мы скоро достигнем экспоненты в, эм, интеллекте для кода. Все видели релиз о Митосе. Эм, даже если мы все еще не имели возможности действительно попробовать это. Обещание в том, что с точки зрения интеллекта кода, эта штука почти идеальна. Эм, но теперь узким местом является контекст. Конечно, без, эм, без контекста, я просто повторю этот момент. Вы, вероятно, попадете в петли гибели. Все знают, что такое петля гибели? Петля гибели — это когда вы, эм, вы боретесь с агентом. Он не совсем делает то, что вы хотите, и вам приходится постоянно его дорабатывать. Худший сценарий — вы запускаете эту штуку в режиме YOLO, и она завершает всю задачу, и она совершенно неправильная. Вам приходится возвращаться и исправлять, вы знаете, различные этапы. Эм, так что, когда у вас есть контекстный движок, вы можете добраться туда быстрее. Проблема в том, что доступ не означает понимание. Так что у нас есть клиенты, которые находятся на различных этапах, я просто вернусь сюда. У нас есть клиенты, которые находятся на различных этапах этого пути. Эм, и одна из интересных вещей, которую мы отметили, заключается в том, что люди чувствуют, что, вы знаете, они лучше всего понимают свою организацию. Так что, когда дело доходит до предоставления правильного контекста этим агентам, люди будут пытаться построить подобие того, что на самом деле представляет собой контекстный движок. Они, возможно, построят систему RAG или построят какой-то способ, как, эм, передавать организационные данные агенту. Эм, к сожалению, однако, доступ не означает понимание. Так что, это означает, что вы можете просто подключить кучу серверов MCP. Эм, и он не сможет понять, каковы взаимосвязи между всеми этими данными, как они туда попали, и почему они такие, какие есть. Эм, и есть еще одна проблема, о которой я расскажу немного позже, называемая удовлетворением поиска. Так что, просто запомните этот термин. Я вернусь к нему. Эм, хорошо. Так что я просто хотел вам это показать. Эм, это было что-то, что мы фактически реализовали, и мы сделали это в двух частях. Одна была просто без какого-либо контекстного движка, но подключенная к куче серверов MCP. Это сделало довольно хорошую работу. Но затем, когда мы достигли конца, эм, мы упустили тот факт, что у нас было что-то устаревшее, что зависело от этого старого, эм, метода, эм, интеллектуализации для антропиков. Так что у них теперь адаптивное мышление, но раньше вам приходилось предоставлять бюджет токенов, и именно так, как вы могли увеличить размер окна мышления. Эм, так что у нас был какой-то код, который как бы зависел от этого, и были причины для этого, эм, которые агент не понимал или не видел, и поэтому он просто, по сути, заблокировал весь этот код. Но когда мы добавили контекстный движок, он увидел все эти причины и реализовал его правильно. Так что он внес соответствующие изменения в нужные места, включил обратную совместимость для кода, который использовал старый метод. Хорошо, теперь о мифах. Миф первый: наивный RAG по моим документам — это контекстный движок. Эм, так что, если вы реализуете, скажем, векторный поиск, эм, или просто пару методов поиска, вы столкнетесь с этим, вы столкнетесь с несколькими проблемами. Одна из них — это проблема удовлетворения поиска, когда, эм, агент будет искать как сумасшедший, потреблять ваши токены, а затем в худшем случае вы достигнете компактирования. Хорошо. Так что, эм, без возможности найти конечную цель, эм, есть несколько других техник, таких как персонализация, когда вы строите систему извлечения, потому что если вы просто RAG все ваши данные, особенно для очень крупных организаций, будут такие вещи, как конфликты, которые вам придется разрешать в данных. Эм, это не будет сосредоточено на задаче, которую вы пытаетесь выполнить, это может привлечь, вы знаете, релевантный код из других частей вашей организации, особенно если у вас действительно большая организация, и у вас тонны разных репозиториев. Эм, это просто создаст огромный беспорядок. Так что вам нужен какой-то элемент персонализации. И затем снова, подключите кучу MCP. Я просто повторю этот момент. Я закончил. Нет, определенно нет. Эм, так что это то, что действительно, эм, подчеркивает точку удовлетворения поиска. И я объясню это через секунду. И, наконец, большее контекстное окно решит эту проблему. Эм, так что давным-давно, вы знаете, когда модели начали становиться большими, люди были очень взволнованы миллионом токенов в вашем контекстном окне. Первые модели, которые попробовали это, я думаю, это был Клод, на самом деле. Это был Клод? >> Я думаю, это был >> или OpenAI. Хорошо. Хорошо. Gemini. >> Gemini. Да. Извините. Мне так жаль. Эм, так что да, Gemini — первая модель, которая попробовала это, и она была очень хороша в поиске иголки в стоге сена. Так что вы могли бы передать, скажем, огромный документ, и пока вы знали, что вы ищете заранее, она могла бы найти его. Но она совсем не была хороша в рассуждении по разным источникам данных, эм, понимании истинного смысла проблемы, а затем в рекомендации соответствующих решений. Так что ничего из этого не было возможно. Очевидно, вещи стали намного лучше. Теперь проблема в том, что у большинства организаций есть более миллиона токенов контекста. Так что попытка вписать все это в контекстное окно все равно не сработает. Давайте спроецируем будущее и представим, что вы могли бы вписать, скажем, 10 миллионов токенов, 50 миллионов токенов. При текущей скорости потребления памяти, просто для работы моделей, это будет невозможно в течение очень долгого времени. Даже если бы это было, и вы вписали весь этот контекст в свое контекстное окно, вы все равно столкнетесь с проблемами понимания того, что истинно, что ложно, эм, как выбрать правильную информацию. Хорошо, теперь я вернусь ко второму пункту здесь, удовлетворение поиска. Это термин, который на самом деле происходит из медицинской области радиологии. И идея заключается в том, что, эм, когда техники смотрят на рентгеновские снимки, эм, и ищут причину симптомов, они могут найти что-то на рентгеновском снимке, что объясняет эти симптомы, а затем они останавливаются. И это своего рода, эм, опасная вещь в медицине, потому что могут быть другие признаки рака, которые упускаются. Так что, эм, удовлетворение поиска — это реальная проблема в радиологии, и существует множество протоколов, чтобы не останавливаться сразу после того, как вы нашли первое. Это то, что происходит с агентами, когда они ищут, скажем, в Notion и вашем коде, Confluence, они натыкаются на то, что выглядит как то, что они ищут, и они останавливаются, а затем они продолжают. Но настоящие, эм, золотые самородки информации могут находиться в другом месте, куда агент не подумает заглянуть, например, в прошлый разговор в Slack или в отчет об инциденте, что-то вроде этого. Так что вот классический мем с айсбергом. Код, который компилируется. Это как бы базовый уровень. Производит ли агент код, который компилируется? Но все, что на самом деле важно, происходит под этим. Так что понимание первоначального намерения пользователя, что было отвергнуто командой в прошлом и опробовано раньше, но потерпело неудачу. Как вы собираетесь извлечь такой контент, просто глядя на документы и код и тому подобное? Так что вам нужно как-то это понять. И даже хуже, эм, иногда трудно понять, когда вещи были удалены, например, при отсутствии информации. Так что вам нужна история, ведущая к решениям. Вот почему мы думаем, что вам нужен контекстный движок. Контекстный движок понимает, кто вы, в какой команде вы работаете, с кем вы работаете, кто эксперты в вашей организации, эм, и какие решения привели к текущей итерации вашей кодовой базы. он способен разрешать конфликты. Так что это своего рода ситуация «правда и ложь». Что истинно, что нет. Иногда эта истинность — серая зона, верно? Так что контекстный движок должен также понимать, когда инструктировать агента, что он не смог разрешить конфликт, а затем учиться на дополнительном вводе пользователя. Этот третий пункт, конечно, очень важен в любой крупной организации или на предприятии. Часто есть, вы знаете, репозитории, к которым не у всех есть доступ, секретные проекты и тому подобное. Так что очень важно, чтобы вы передавали права доступа вверх. У нас есть, я приведу пример, который всем понравится, это Slack. Наш контекстный движок интегрируется со Slack или Microsoft Teams. И когда у вас есть частные каналы, это очень конфиденциально, верно? Например, вы можете обсуждать информацию HR или, возможно, что-то, что вы действительно не хотите, чтобы видели все остальные. И поэтому, когда Unblocked отвечает на вопросы, он будет использовать информацию из частных каналов, но он не будет использовать эту информацию, только если человек, задающий вопрос, имеет к ней доступ. И тогда эти ответы не являются общедоступными. Хорошо? Так что они частные для вас. И, наконец, конечно, предоставление правильного контекста в нужное время. И это касается эффективности токенов. Это касается как можно более быстрого получения ответа. Итак, вот высокоуровневый обзор того, как может работать контекстный движок. Слева у нас входные данные из источников. Так что, такие вещи, как инструменты планирования, документы, разговоры, код, PR, по сути, все, что имеет отношение к выполнению работы на инженерном уровне. А затем справа у нас выходные данные. Так что, вы знаете, все это может поступать в кодирующие агенты MCP или инструменты CLI. Вы можете создавать пользовательские приложения через API. У нас есть, у нас есть компонент обзора кода, который просто подключается к вашему SCM и предоставляет обзоры кода, и, конечно, интеграции с приложениями для обмена социальными сообщениями. Так что это своего рода широкие шесть требований, которые, по нашему мнению, важны. На самом деле их гораздо больше, но это высокоуровневые вещи. Итак, снова унифицированные системные контексты, это касается построения взаимосвязей между данными. Хорошо. Но это больше, чем просто распознавание, когда, эм, одна часть данных связана с другой. Например, в Slack у вас могут быть разговоры о PR. Это простая связь, потому что вы публикуете ссылки туда и обратно. Так что это легко. Что менее легко, так это понимание причины, по которой были приняты решения, или лучших практик вашей организации, верно? Так что, чтобы понять это, вам придется копнуть немного глубже. Делать такие вещи, как извлечение комментариев к запросам на извлечение из PR и попытка извлечь их суть, а затем, когда вы видите повторяющиеся шаблоны, вы можете собрать эти шаблоны вместе и сохранить их как, вы знаете, «воспоминания», чтобы, когда, эм, кто-то работает над похожим кодом, вы можете загрузить эти воспоминания, и тогда агент сможет увидеть это и сказать: «О, да, верно, так эта организация делает эту конкретную вещь». Разрешение конфликтов очень важно. Мы сначала применили своего рода наивный подход к этому, основываясь только на недавности, верно? Так что мы отдавали предпочтение более новым вещам. К сожалению, при полной полноте вашего контекста недавности недостаточно. Часто люди пишут документы или общаются на своих платформах обмена сообщениями, и они могут говорить вещи, которые не совсем соответствуют тому, как работает система. Так что, вы знаете, тогда мы начали отдавать предпочтение коду. Так что у нас была недавность, и мы были как бы, основная ветка, безусловно, ваш источник истины, но не всегда, потому что иногда то, что важно, это то, что происходит дальше, а не то, как система работает в настоящее время. Например, когда вы работаете над задачей, то, что вы действительно хотите, это чтобы агент понимал, куда вы идете, а не обязательно, где вы были. Где вы были, помогает ему понять, чего не делать. Куда вы идете, помогает ему понять, что вы должны делать. Так что, в случае со Slack, просмотр разговоров, которые ведут эксперты вашей организации, важнее, чем просто понимание того, о чем говорит каждый случайный инженер. Целенаправленное извлечение и личная релевантность очень связаны. Так что я просто кратко расскажу о них вместе. Так что, эм, опять же, когда вы извлекаете контекст, важно, чтобы вы извлекали контекст только для соответствующей задачи и, вероятно, для вас. Так что вот интересная техника. Вы можете понять, над какими репозиториями человек работает больше всего по количеству PR, которые он отправляет, вкладов, а затем, если вы делаете, если вы делаете векторное извлечение, вы можете сделать глубокое извлечение из этих сфокусированных репозиториев, а затем более широкое извлечение из, вы знаете, остального исходного кода, а затем как бы сместить выбор в сторону сфокусированных репозиториев, потому что там, скорее всего, человек будет работать и проводить свое время. И, вы знаете, мы говорили об управлении данными, так что я не думаю, что мне нужно повторять это снова. Очень важно. Это был просто небольшой эксперимент, который мы провели с более крупной задачей. Я полностью признаю, что некоторые из этих цифр немного странные. Это, по сути, вывод чисел Клодом. Так что не доверяйте этому. Просто доверяйте атмосфере вещи, а не обязательно цифрам. По сути, это означает, что когда мы начали без активного сервера MCP или, скорее, без активного контекстного движка, он действительно упустил многое. И это просто потому, что он не понимал, как действительно работает существующая реализация и почему она такая, какая есть, что было опробовано раньше и потерпело неудачу. И поэтому он совершил много тех же ошибок. С включенным контекстным движком, очевидно, он попал в точку. Ключевые цифры — это время и токены, которые потребовались. Так что без контекстного движка задача заняла два с половиной часа с 21 миллионом токенов, что очень много токенов. Но с контекстным движком это заняло всего 25 минут и 10 миллионов токенов. Так что это довольно драматическая разница. Хорошо, так что трудные уроки, это просто примеры, кстати, но это те, которые мы сочли интересными. Итак, во-первых, изначально мы оптимизировали доступ, а не понимание. Так что наша первая предпосылка была такова: если мы просто подключим кучу инструментов и предоставим граф знаний, он сможет перемещаться по графу знаний и выполнять кучу инструментов извлечения для конкретных интеграций и так далее и все выяснять. Это не работает. Так что вам придется копнуть немного глубже. Второй момент: мы скрывали конфликты вместо того, чтобы их выявлять. Так что, скрывая конфликты, я не имею в виду, что мы просто игнорировали конфликты. Вместо этого мы пытались разрешить эти конфликты, используя эти наивные стратегии, и мы не выявляли конфликты, которые мы не смогли разрешить. Так что это был очень хороший урок: контекстный движок, я имею в виду, мы доберемся туда в конце концов, вероятно, но он не всегда может определить, каковы истинные элементы, и когда он не может, вы должны выявить это и учиться на этом. Это главное. И, наконец, я думаю, многие люди пробовали это. Это очень плохая идея. Так что, когда контекстный движок предоставляет ответ, не кэшируйте ответ и не пытайтесь снова предоставить тот же ответ на похожий вопрос. Причина очевидна, довольно очевидна ретроспективно, но все постоянно меняется, код меняется, документы меняются, причины вещей меняются. Так что это просто не работает. Другое дело, что если вы попытаетесь использовать предыдущие ответы в качестве контекста для новых ответов, вы регрессируете к среднему. Так что, если модель ведет себя плохо или делает что-то плохое, и вы постоянно включаете это в контекст, вы, очевидно, загрязняете контекст. И это то, что происходит. Итак, давайте теперь поговорим о том, где команды, ориентированные на ИИ, такие как те, которые занимаются этим, например, облачные агенты, используют и извлекают выгоду из контекстных движков. Определенно, и особенно на этапе планирования. Хорошо, здесь вы получаете наибольшую отдачу, несомненно. Привлекайте контекстный движок, используйте навык для его привлечения. Подключите его к серверу MCP и наблюдайте, как он делает свое дело. Здесь вы получаете наибольшую отдачу. Это также полезно делать во время обзора. Так что вы получаете планирование и обзор в конце. Потому что, знаете, если вы дадите агенту провести обзор, он, по сути, просто обратит внимание на код и попытается понять, где точки разрыва, проблемы безопасности, такого рода вещи. Но без организационного контекста он не понимает мотивации для этого. Так что это действительно важная вещь. Выбор обогащения. Это очень крутой вариант использования. Так что вы создаете билет для новой функции, а затем просто просите агента, подключенного к контекстному движку, заполнить пробелы. Работает. Триангуляция. Я использую это все время. Когда я вижу проблему в продакшене, я просто вставляю ее в агента, подключенного к контекстному движку, и он мгновенно выводит все связанные с этим прошлые проблемы и начинает работать немедленно. Все чаще мы видим это в управлении инцидентами. Хорошо. Так что мы только что подключили Datadog и этот, извините, Sentry и Datadog, извините. И это уже оказывается очень крутым вариантом использования. Он может видеть сигналы, а затем действовать на все сигналы и связывать это с кодом, связывать это с прошлыми инцидентами, которые у вас были, и обсуждениями, которые у вас были в Slack. Иметь все эти вещи вместе одновременно — это почти волшебство. И, наконец, я думаю, это на самом деле мой любимый, и им пользуются больше всего клиенты — это поддержка клиентов, продаж и инженеров. Так что многие большие команды делают так, что у них есть каналы поддержки инженеров, куда могут приходить другие команды и задавать вопросы. Если вы поместите контекстный движок в одну из этих вещей, вы можете автоматически отвечать на многие вопросы и экономить инженерам кучу времени. Хорошо. Как команды делают контекстный движок своими навыками. Так что определенно создавайте навыки, которые вы можете использовать для курирования контекста в репозитории GitHub. И вы можете создавать другие навыки вокруг него, такие как ввод билета с обогащением, дайте ему идентификатор проблемы, и тогда он сможет использовать контекстный движок для создания рабочих процессов обогащения, таких как этот, подготовьте временную шкалу инцидента, а затем вы можете просто отправить ее своему агенту снова, контекстный движок, бла-бла-бла, собирает все вместе, волшебство, и эта штука здесь, вы можете подключить ее ко всем видам агентов. У меня есть, эм, одна из вещей, которую любят делать многие клиенты, это подключать ее к Claude Code в вашей системе CI. У нас действительно есть компонент обзора кода, так что вам не нужно этого делать, если вы используете Unblocked. Но люди используют это для других вещей, не только для обзора кода. Как только вы подключите контекстный движок в фоновом режиме, дайте ему ключ API, позвольте ему работать самостоятельно, он может делать довольно безумные вещи. Так что я просто покажу быстрый пример того, что может сделать подключение контекстного движка. Так что это PR, который написал мой коллега, и он разблокировал, прошел и предоставил своего рода обзор этой вещи, и внизу этого обзора, вот часть обзора. Вы можете видеть, что Ричи, автор этого PR, сказал: «Очень круто, это то, что я бы сказал». Теперь причина комментария, которая заключалась в том, что вы, по сути, дублировали кучу тестов, вы можете немного привести это в порядок, заключается в том, что это была лучшая практика, извлеченная из множества других PR, и забавная часть в том, что автор этих PR был Ричи. Так что он тот, кто фактически внедрил лучшую практику в организации. Так что это был просто классный маленький момент, когда мы это обнаружили. Вот еще один пример. Так что это был довольно длинный транскрипт. Я не собираюсь показывать его целиком, но мы отправили его на миссию выполнить большую задачу. Без Unblocked это заняло довольно много времени. Как вы можете видеть, транскрипт довольно длинный. И он упустил кучу всего. С Unblocked это было намного компактнее. Он очень быстро и правильно получил ответ. И просто потому, что мы теперь ориентированы на ИИ и ленивы, мы взяли оба этих транскрипта и запустили их в Claude и просто сказали: «Эй, Клод, почему бы тебе просто не проанализировать обе эти вещи и не дать нам свой результат». Так что он прошел, я не буду, вы знаете, утомлять вас деталями, но просто чтобы сказать, что в конце вердикт таков: план контекстного движка — это то, с чем я бы работал. Другой хорош для прототипа, но ему не хватает кучи вещей, которые важны для этой организации. Это было ранее обсуждалось. Итак, это, по сути, то, что я пытался сказать. Сгенерированный ИИ код должен просто ощущаться так, как будто его написал кто-то, кто был в вашей команде около 20 лет. Хорошо. Если это еще не так, это нормально. Это будет. Если вы подключите Unblocked, вы увидите огромную разницу в производительности агентов, и если вы строите одну из этих вещей, абсолютно, возьмите все это и постройте, и посмотрим, куда это приведет. Так что прямо перед тем, как мы перейдем к компоненту мастер-класса, может быть, мы просто проведем 5-10 минут вопросов и ответов. >> Я Брэндон >> и это Брэндон. Так что он поможет с >> этим. >> Спасибо. Эм, так что ясно, что это дает вам и какие проблемы решает? Но для меня большой знак вопроса — что это такое? Что это за артефакт, который подходит? Это как программа, которую вы устанавливаете, API, который размещен удаленно, или сервер MCP? Что это? >> Это все это. Так что контекстный движок, я объясню, что такое Unblocked. Может быть, я просто покажу быструю демонстрацию. Эм, так что в широком смысле существует множество различных поверхностей контекстного движка. Вы хотите, чтобы он был в вашем потоке агента, и вы можете сделать это с помощью сервера MCP. Вы можете сделать это с помощью инструмента CLI, например. У нас также есть эта поверхность панели управления, где вы можете задавать вопросы о вашем коде. Это довольно простой, но вы можете видеть, что он понимает, кто я и над чем я работал. Эм, а затем, эм, у нас есть Slack, у нас также есть подключение к Slack. Так что вы можете принести Unblocked в Slack. Управляйте им в разговорах и пусть он автоматически отвечает на вопросы. Это имеет смысл? Я ответил на ваш вопрос или >> Хорошо. >> Да. API, CLI, MC. >> Да. Да. >> Извините. >> Спасибо. Эм, так мой вопрос заключается в следующем: насколько я понимаю, это приложение для управления знаниями и извлечения. >> Да. И связано ли это как-то с такими вещами, как, эм, LLM wiki, как это недавно популяризировал Андрей Карпати, или с трассировками решений и контекстными графами, >> о которых много говорилось несколько месяцев назад. >> Да. Так что вы можете думать обо всех этих вещах как о своего рода полезных компонентах контекстного движка. Контекстный движок должен делать гораздо больше, потому что, эм, так что агенты очень хорошо рекурсивно проходят по вики, например. Зависит от того, как вы строите эту вики, потому что есть куча вещей, таких как организационные воспоминания, лучшие практики, вы знаете, эксперты в вашей организации, которые используются как точки опоры для извлечения контекста. Так что вики не решает эти проблемы, если у нее нет, вы знаете, вы могли бы построить структуру с ней. И я думаю, Карпати обнаружил, что если вы относитесь к вики как к своего рода файловой системе, вы можете разбить ее и заставить агента проходить по ней, как по файловой системе. Кстати, агенты очень хорошо оптимизированы для обхода файловой системы. >> Да. Шаг компиляции. Точно. >> Да. Да. Извините. Извините, может быть, тот же вопрос, но это общий контекстный движок или он нацелен на код, потому что будет ли он полезен как, скажем, как эксперт в бизнес-домене или своего рода построение бизнес-домена, а затем иметь этот контекстный движок, использующий мой, чтобы все мои другие ИИ-агенты могли использовать это как контекст для бизнеса. или вы бы сказали, что это больше для части кода? >> Эм, так что это определенно ориентировано на инженерию, интеграции ориентированы на инженерные мероприятия. Так что, вы знаете, интеграции SCM и другие инструменты, которые используют инженеры. Мы все чаще видим, как клиенты используют это для других целей. Так что бизнес-аналитика — это ключевая вещь. И это обычно полезно, когда люди в бизнес-функциях пытаются понять продукт и его работу. У нас нет, скажем, интеграций Salesforce, подключенных для этого. Так что вы не можете использовать его для понимания, вы знаете, чего-либо, связанного с продажами. Это действительно в первую очередь контекстный движок, ориентированный на инженерию. Это не значит, что это не изменится. Да. >> по поводу управления, если вы >> уважаете права доступа, как он может синтезировать данные и затем разрабатывать новые знания внутри себя, которые он затем может предоставить людям? >> Так что да, вы правы, что указали на это. Синтез >> compartmentalized. Так что есть, вы знаете, места, которые compartmentalized, такие как отдельные репозитории. Это своего рода уровень доступа. Так что, если вы можете синтезировать исторические данные на основе этого, а затем сопоставить их с общедоступной информацией в Slack, то это один из способов синтеза без пересечения организационных границ. Так что, вы знаете, другой способ — это посмотреть и пометить, когда синтезированная информация пересекает эти организационные границы, и вы можете взять что-то вроде подхода группового ID к этой проблеме, прикрепляя теги группового ID к синтезированной информации, а затем извлекать ее только в том случае, если человек, который имеет к ней доступ, может ее построить. Так что сначала примените compartmentalized подход, потому что именно там вы получите наибольшую отдачу, а затем вы как бы построите оттуда. Я имею в виду, это основная проблема использования такой технологии, как Graph RAG, потому что Graph RAG — это как пирамида, которая строится слоями, а затем, по сути, суммирует каждый слой, но это неизбежно пересекает границы разрешений. Так что вам нужно создать compartmentalized карманы. Да. Это хороший вопрос. >> Да. >> Да. Вы много говорили о различных источниках информации, которые вы потребляете и объединяете. Когда вы синтезируете их, это все еще своего рода наивный RAG, векторный поиск, все эти вещи под капотом? Или это агенты решают, что уместно? как что или, вероятно, комбинации всего, но что это за шаг? >> Эм, да, вы правы. Это комбинация всего. Так что построение графа знаний происходит множеством разных способов. >> Эм, вещь с PR, которую я вам показал, например, это как, во-первых, вы строите наивный граф знаний процедурно, а затем из него вы можете использовать LLM для дистилляции, суммирования и построения таких типов техник. Наш контекстный движок сначала строит, скажем, граф знаний из основы, используя попытку использовать все различные сущности. Это своего рода ранговый поиск, где он процедурно строит взаимосвязи, а затем, конечно, векторизует данные. А затем есть процедурные инструменты, которые извлекают данные во время выполнения. Многое из дистилляции для, вы знаете, разрешения конфликтов происходит в двух местах. Так что одно — это как бы во время приема данных, есть теги, которые связывают данные друг с другом, чтобы мы могли видеть, можем ли мы деконфликтовать на этом уровне, а затем ранжировать друг против друга на этом уровне, а затем, конечно, во время выполнения вам придется передать вещи судье с критериями, а затем он выполняет дополнительное деконфликтование в реальном времени. >> Это имеет смысл? >> Да. >> Хорошо. >> Еще один вопрос. Так что я был любопытен, вы сказали конфликты, но в какой-то момент вы получаете конфликты, что что-то означает доход для одной компании и означает доход для другой компании, это совершенно разный смысл, как вы можете это распознать, так как вы получаете людей в цикле, как вы используете их онтологии и как вы можете использовать это, когда вы сталкиваетесь с этим, так что я очень любопытен на самом деле, как как >> да, так что если я могу показать вам кое-что быстро здесь, так что вы заметите, что внизу ссылки, которые использовались для ответов, доставляются как человеку в этом интерфейсе, так и агенту. Так что, если агент, если контекстный движок не может выполнить деконфликтование, то в этом месте человек может вмешаться и направить агента, когда есть достаточно >> так что вы можете буквально просто ответить и сказать, что это неверно, или вы можете прийти сюда >> и >> о да, извините >> да, или вы можете сделать это, например, не полезно, и дать причину, почему, например, это немного ручной процесс на данном этапе, но сигналы, которые накапливаются со временем, >> это смешно, верно? Вы можете поймать много человеческого интеллекта этим, верно? >> Да, это потрясающе. >> Да, для типичного клиента, сколько у вас этой метрики? >> О, это огромно. Это, это, это потрясающе. Например, я был действительно удивлен, насколько охотно люди дают обратную связь. Да. Нет, это >> сотни или тысячи >> Я имею в виду, при небольшом размере команды это, вы знаете, сотни, при таком небольшом размере команды, как 20-30 человек, при большом размере команды 100-200 человек, это сотни и сотни >> о, вау >> обратной связи. Да >> люди просто очень любят взаимодействовать с агентами и говорить им на естественном языке, что не так. Это просто совершенно естественная вещь. >> Да. >> Круто. Хорошо. Мы закончили с вопросами и ответами? >> и тогда мы можем перейти к >> задавать вопросы, пока мы хакаем. Но >> да, давайте перейдем к, давайте перейдем к части мастер-класса. Так что, эм, мы создали, эм, на самом деле, я сделаю это первым. Так что вы можете сделать это сейчас, если хотите. Я вернусь к этому слайду через секунду. Идея здесь в том, что мы попросим всех присоединиться к рабочей области Slack, которую мы создали, а затем мы попросим всех перейти в репозиторий, где живет этот, эм, где живет этот пример кода, а затем мы просто начнем хакать его вместе. Хорошо. >> Да. У меня уже есть люди, которые приходят. >> Отлично. >> Когда вы войдете, вы увидите канал AI Engineering London. Надеюсь, там будет ссылка на этот дроп и >> ссылка на Unblocked не будет работать, пока вы не выполните шаг два. Да. >> Чтобы попасть в GitHub или >> О, нет. >> У меня уже есть много людей, которые приходят. Так что я очень надеюсь, что >> это сеть? Да. >> Мы узнаем. >> Эм, хорошо, пока люди это делают, я просто покажу вам, во что мы входим. Так что это, эм, GitHub организация. Эм, то, над чем мы работаем, это построитель социальных графов. Так что это сделает следующее: посмотрит на репозиторий исходного кода. Так что вы можете запустить это на своем собственном репозитории. Он ничего не загрузит. Все локально. Так что вы можете видеть, как эта штука строится против вашей собственной организации. И это сделает кучу вещей. Мы получим, по сути, социальный граф из него, и я покажу вам, как он выглядит. И мы поймем, кто эксперты и над какими частями кода они работают. Эм, а затем будет небольшая интерактивная визуализация. Так что цель этого упражнения — запустить эту штуку и начать просто хакать ее. Так что, например, начните отправлять PR, как только мы это запустим. Так что вот как это выглядит. Этот граф здесь — наша организация Unblocked. И, эм, то, что вы видите здесь, это граф взаимосвязей, который показывает, кто рецензирует чьи PR, и кто рецензируется. По сути, эм, эта штука — это дистилляция всех различных команд в Unblocked. Так что это примерно точно на самом деле. Ну, не примерно, это довольно точно. Эм, у нас есть, я сделал это с самого начала 2025 года. Когда вы запускаете эту штуку, я бы рекомендовал, возможно, сделать это за более короткий период времени, потому что это будет немного медленно, если вы пойдете до 25-го. Это может занять около 15 минут. Но это эффективно дистиллировало, кто такие команды, и, эм, вы, единственный шаг ИИ в этом — это маркировка команд. Вам не обязательно запускать шаг ИИ, если вы не хотите, он просто будет использовать части кода, над которыми люди работают больше всего. Эта вкладка здесь покажет экспертов в организации и над чем они работают. Так что это просто разбито по областям проекта и путям, и показывает, какие области кода имеют хорошее покрытие. Покрытие в основном определяется тем, присутствует ли высококвалифицированный организационный эксперт и является ли это активно вносимой частью кода. И, наконец, у нас будет этот интерактивный граф, который разбивает вещи по командной области и показывает, вы знаете, кто основные участники. Я здесь, в команде ИИ. Да, вот и все. Давайте все войдем, и мы начнем хакать это. >> Да, абсолютно. >> Да. >> Многие из вас должны получить приглашение, если вы уже указали свой GitHub. Так что, пожалуйста, проверьте. GitHub — это худшее. >> Да. >> Мы сделаем это. Это лицензия MIT. Мы сделаем ее общедоступной позже, но пока она должна быть закрыта. О, ты еще не получил? Я покажу. >> Что ты сделал? Я тоже в Slack. Так что, я думаю, остальная часть этой сессии теперь будет просто хакать. Так что, эм, через секунду, я думаю, я, я уберу это, если все это получили. Так что, чтобы Брайан и я могли сосредоточиться на работе с вами, ребята, над созданием функций. О, когда вы отправляете PR, кстати, вы заметите, что Unblocked сидит там как рецензент кода. Так что не чувствуйте себя плохо, если он немного разбрызгает ваш PR. >> Зависит от того, насколько у вас крутое имя пользователя. Хорошая работа. >> Все ли в порядке с этим? Я беру это. Хорошо. >> Брэндон, ты на связи с приглашениями. Хорошо. >> Есть еще несколько. Я на Крисе дал два. >> Это нормально. Я отправлю оба. Не волнуйся. >> Это просто то, где я в этом списке. О, я забыл упомянуть пару вещей здесь на самом деле. >> Да. >> Возвращаясь в прямой эфир. Да, хорошо. Эм, просто пара вещей. Так что, если вы ищете что-то для реализации и начинаете с придумывания идей и тому подобного, есть набор предопределенных проблем, которые вы можете хакать. Так что вы можете просто взять одну из них, отправить ее в Claude и посмотреть, как она справится, когда она будет подключена к контекстному движку. Сервер MCP для Unblocked здесь. Так что, если вам нужны инструкции о том, как подключить это к Claude Code или другому агенту, то вы можете получить его из инструкций отсюда. Хорошо. Итак, я у Ларса. Здесь еще двое. Так что я все еще иду, кстати, для тех, кто только добавляет, что происходит, Брэндон? >> О, извините, просто одно из имен пользователей >> О, хорошо. Вы должны были получить прямо за Кристофером, вы еще не получили приглашение? >> Нет, я не получил. >> Это странно. >> Позвольте мне проверить. Вы должны получить одно, но >> да, я должен. Вы должны получить электронное письмо. Я дошел до одного из вас. Так трудно. >> Это как пять кликов, чтобы добавить участника. Я как бы, >> Я бы сказал, что должен был использовать CLI для этого. Что происходит? >> Правильно. >> Нет, они продолжают вставлять это в мой PR, и я этого не хочу. Copilot будет рецензировать меня >> очень плохо, но он будет задавать вопросы. >> Да, конечно. >> Подождите. Позвольте мне взять микрофон. Надеюсь, он включен. >> Он работает? Да. Эм, так что, я думаю, этот контекстный движок очень хорошо работает для асинхронных агентов, так что вам не нужно указывать вещи на клавиатуре, потому что они могут получить то, что им нужно. Это одно из основных применений, я думаю. И >> эм, так что он очень хорошо играет, я думаю, с агентами, такими как Copilot на GitHub. Видите ли вы, если вы можете поделиться, какие агенты используются больше всего с Unblocked, будь то больше, потому что в дикой природе разработчики с нашими ноутбуками, я думаю, CL Code используется гораздо больше, чем Copilot, но, возможно, вы видите другую картину. >> Хорошо, я уберу это с экрана для безопасности >> и попробую посмотреть, смогу ли я это найти для вас.
Эм, но ответ — да, мы примерно знаем, как выглядит эта разбивка. Итак, позвольте мне взять это. Хорошо. Я думаю, это дает вам примерное представление. >> Хорошо. Итак, это своего рода грубая, грубая картина здесь. Эм, к сожалению, из-за того, как это устроено, мне, вероятно, следует, как >> расширить экран, но я просто перейду сюда. Итак, э, облачный код используется гораздо чаще всего. Эм, за ним следует, это следующий — курсор. Так что это кажется довольно очевидным. Последнее здесь — это своего рода сборная солянка, но что действительно интересно, так это то, что многие люди используют облачный рабочий стол, что было очень неожиданно, но это так. Эм, так что, а затем VS Code и Codeex составляют гораздо меньшую часть, но да, кажется, все используют либо курсор, либо облачный код. Я ожидал большего, знаете ли, полностью асинхронного агента, вроде того, что люди просто запускали бы из PR. Хорошо, вы можете запускать код из PR, но это реже. Возможно, иногда вы используете Copilot, потому что он встроен. >> Да, на самом деле этот, облачный код, эм, может, может захватывать часть этого трафика. Так что, вероятно, это то, что вы видите, потому что люди будут подключать облачный код в CI >> и делать такие вещи. >> Спасибо. >> Пожалуйста. У меня есть потенциально глупый вопрос. >> Глупых вопросов не бывает >> это. Ну, посмотрим. >> На самом деле, знаете, знаете, >> вы скоро. >> У меня был учитель в третьем классе, который говорил мне: «Глупых вопросов не бывает, бывают только глупые люди». Продолжайте. Я могу быть одним из них. Эм, как, с вашей точки зрения, вы можете использовать, скажем, суб-агентов с исследовательской точки зрения. >> Да. >> Как, как, как это плюс память плюс просто, скажем, хранение фрагментов информации, которые могут быть, я думаю о социальной графе, который вы только что показали, верно? >> Да. >> Даже в организации из нескольких тысяч человек вы могли бы сохранить это в очень маленьком файле. Нет. >> Эм, вы бы, как граф, который вы показали. >> О, я вижу компонент социальной графы. Да. Да, он может быть компактным. Я >> пытаюсь понять, как это сравнивается, какой своего рода, скажем, USP по сравнению с исследовательскими агентами и повторением этого. >> Я понимаю, что вы имеете в виду. Хорошо. Эм, так вот, есть два, есть два компонента. Один из них заключается в том, что исследовательский агент должен делать это каждый раз. Так что, когда он начинает с нуля, да, возможно, он сможет восстановить своего рода иерархию социальной графы, но ему придется сделать две вещи, чтобы сделать это. Одно — это фактически написать код, чтобы составить граф, по крайней мере, так, как агенты есть сегодня, или так, как модели есть сегодня. Вы не сможете просто заставить его, скажем, запускать базовые инструменты вокруг >> организации и выяснять, кто есть кто. >> ему придется написать своего рода алгоритм социальной графы, запустить его, а затем получить дистилляцию с бэк-энда. Так что, в этот момент вы, по сути, приближаетесь к этому компоненту. В любом случае, так что вы его обходите и просто запускаете и используете. Эм, возможно, мне следует объяснить некоторую мотивацию для этой вещи. На самом деле, я сейчас понимаю, что, возможно, я не сделал это эффективно. Эм, социальная графа — это не просто передача информации о том, кто является экспертами. Она используется в контекстном движке как точка опоры >> для получения более важного контекста. Так что понимание того, кто является экспертами в определенной области кода, действует как точка прыжка, потому что >> другая часть контекстного движка, которая происходит на уровне приема и обработки, — это >> дистилляция >> мы называем это «бутилированием эксперта», но по сути это дистилляция того, над чем работал этот человек в прошлом. >> где они находятся в своего рода иерархии организации >> решения, которые они приняли на основе разговоров в Slack, которые у них были, на основе их комментариев к PR, все это >> когда вы дистиллируете это и передаете это агенту, тогда происходит следующее: скажем, я новый сотрудник, и я собираюсь работать над определенной областью кода >> есть множество различных способов загрузки контекста для этого кода, один из них — это, знаете ли, семантический поиск через векторный векторный поиск. >> Да. Так что это своего рода первый уровень. Другой уровень — это >> предварительно созданные воспоминания. И затем третий уровень — это бутилирование и разбутилирование эксперта для этой области кода. И получение знаний эксперта в контекст — это действительно мощный механизм. Он помогает управлять остальным поиском в циклическом режиме агента и помогает >> агенту >> направленно, куда идти дальше. Это имеет смысл? >> Верно. Я думаю, все уже здесь. >> Отлично. >> Итак, давайте >> Хорошо. Итак, я думаю, мы, если мы все здесь, то >> следующее здесь — это когда я снова выведу это на экран. >> Я все еще, я все еще отправляю приглашения. Я видел, как кто-то просто, так что, пожалуйста, продолжайте приходить, и мы можем продолжать. >> Да. Так что, эм, не стесняйтесь, по сути, просто бросить этот репозиторий вашему агенту и заставить его, скажем, запустить его. Если вы буквально просто скажете Cloud Code, запустите это против моего репозитория, >> обязательно укажите временной диапазон или ограничение PR, иначе он выйдет из-под контроля и займет очень много времени. Так что просто скажите, обработай последние, скажем, 300 PR или обработай до, знаете ли, сентября 2025 года или что-то в этом роде. >> В readme достаточно информации, чтобы он мог просто сделать это и просто запустить его против вашего репозитория. >> Я клонирую, прочитаю readme и сделаю это. >> Да. >> Могу я задать еще один вопрос? Какие у вас планы на ближайший год или что-то в этом роде? >> для разблокировки >> это, это связано с разблокировкой или с этим >> этим >> эм, ну, я, я, я как бы намекал на это раньше, но куда движется шайба, это полностью автономные агенты. Так что мы очень сосредоточены на том, чтобы потоки автономных агентов были высоко оптимизированы. Вы, как я говорил в начале разговора, не можете эффективно запускать эти вещи без, скажем, очень точно настроенного контекста. >> Да. Так что, когда вы думаете об этом, в какой-то момент я читаю вещи вроде трассировки, что делают агенты, и вы получаете из них рабочие книги, это, это путь, в который вы инвестируете, или что, что это поиск, что >> вы говорите конкретно об управлении инцидентами, тогда или >> извините >> вы говорите конкретно об управлении инцидентами, управлении этим и тому подобном. >> Нет, я говорю о вашем, я думаю, скорее с деловой точки зрения. Как мы можем извлечь бизнес-знания, которые очень глубоко встроены в системы, которые никто больше не знает, а некоторые люди думают, что знают, но не знают. >> Да. >> И документы, человеческие знания, верно? Проверенные знания. >> Да. Так что, я имею в виду, есть два способа обслуживания этого: либо на уровне продукта, либо >> через сам контекстный движок. И все чаще мы видим, что люди используют >> агентов для выполнения своей работы даже на этом уровне. Так что они пойдут в облачный код, они подключат контекстный движок unblock, это будет типа сделай это для меня, а затем контекстный движок найдет все, что ему нужно для выполнения этой задачи, и он >> предоставит эти данные. >> Да. >> Для нас это означает, что первая краткосрочная дорожная карта — это API. >> Да. Это как CLI >> CLI API вопрос, или это просто хорошо. Круто. Я снова подниму это. Надеюсь, люди начнут отправлять некоторые PR, и мы сможем >> Да, вы в этом GitHub. Позвольте мне на самом деле перепостить это в канал Slack, потому что эта ссылка >> так что эта организация останется до конца недели. >> после чего мы, по сути, ее закроем и >> выпустим это как открытый исходный код, и >> все, кто внесет свой вклад, очевидно, будут отмечены. Так что >> ваше имя будет на нем. Должны ли мы, скажем, настроить репозиторий локально, а затем начать делать то, что, по сути? Так что я только что закончил настройку >> Да, просто клонируйте репозиторий. >> самое простое — взять, скажем, агента, такого как Claude, и направить его на >> просто запустите его из этого репозитория из этого каталога и просто скажите, пожалуйста, >> загрузите и запустите этот продукт, и он начнет работать. Если вы столкнетесь с какими-либо техническими проблемами, мы, очевидно, здесь. Да. >> Давайте подождем. Давайте дадим вам микрофон. О, вы получили. У меня есть петличный микрофон. >> так >> отлично. Круто. >> Да. >> Вы меня слышите? Да. Отлично. >> Итак, на слайде, где у вас была, скажем, производительность, и вы были на 80%, а без разблокировки — на 20%. >> Да. >> И теперь я вижу, что вы, по сути, подключаете unblock к cloud code. Так что в некотором смысле, справедливо ли сравнивать, что я буду использовать обычный cloud code с доступом к MCP и навыкам. >> Да. >> И затем я буду использовать cloud code, подключенный с unblock, с теми же MCP и теми же навыками. >> Да. >> И здесь вы можете провести сравнение производительности. И здесь у вас все еще много альфа из, я полагаю, того, что вы готовите внутри unblock. Было ли это сравнение проведено, или оно было проведено без >> было ли оно проведено с обычным cloud code, но без контекста? >> Нет, оно было проведено с серверами MCP, такими как GitHub и Slack, подключенными. >> Я понимаю. >> Да, круто. >> Мы, по сути, достигли паритета со всеми серверами MCP каждого поставщика SAS в одном. Это было как обычный cloud code со всеми MCP, а другой — cloud code с unblock только >> а затем выполнить задачу и >> тот же контекст, как тот же контекстный файл >> тот же промпт >> и тот же доступ. Да. Да. >> Это довольно весело. Да. О, спасибо. >> Эм, возможно, два вопроса. Итак, один — я вижу, что многие из этих, скажем, социальных графов построены с использованием традиционных сетевых >> расчетов и статистических аспектов сетей. >> Это подход, с которого вы начали, и он уже работал лучше всего, или >> вы, потому что большинство систем памяти работают больше над фильтрацией, скажем, эпизодической памяти, чего-то еще, чего-то еще, чего-то еще, и это действительно хорошая система оценки >> это первый вопрос, это также с unblock второй вопрос >> >> вы упомянули, что он работает с командами >> в среде Microsoft, я задаюсь вопросом, какие различия вы наблюдали между построением социальных графов для разных сред, потому что на GitHub я представляю, что это очень отличается от SharePoint Teams и т. д. и т. д. Это также основано на сетевой статистике, или это что-то другое? >> >> ну, я имею в виду, наша первая реализация была невероятно наивной, она просто использовала >> количество вкладов в PR и сравнивала это напрямую с >> количеством PR, рассмотренных каждым человеком, так что это была простая игра чисел. >> с этим не удалось получить точные кластеры команд. Так что затем мы перешли к >> алгоритмам, которые вы видите здесь. >> Unblock делает немного больше, чем это. Так что это своего рода средний путь. >> Другая стратегия, которую использует Unblock, — это, скажем, эксперты по кластерам векторов. Так что, когда мы принимаем исходный код и векторизуем его, >> мы понимаем, кто является >> наиболее активными участниками этого фрагмента исходного кода. Так что, когда мы ищем отдельных лиц, мы можем видеть, над чем они работали, и какие >> кластеры находятся в непосредственной близости, а затем связывать людей на основе их >> близости к кластеру. Так что это больше похоже на подход типа ML. И затем есть финальный слой, который является >> своего рода >> AI LLM тяжелым слоем, который выполняет дистилляцию >> множества различных контекстных элементов, того, над чем люди работали в прошлом, разговоров, которые они вели в Slack. >> И затем, когда вы берете все это и взвешиваете это против >> процедурно сгенерированного графа, вы получаете гораздо более точную дистилляцию там. Этот здесь, вы заметите, что некоторые люди будут привлечены к кластерам команд, которые, знаете ли, работают во многих разных командах, например, и это не будет учтено >> разные алгоритмы, разные, скажем так, я не хочу вынимать >> это, так что нет, этот алгоритм чисто основан на SEM. Так что алгоритмы для, вы правы, >> Slack, команды, они довольно сильно отличаются, потому что у вас нет этих точек обзора. >> Так что тогда становится, знаете ли, кто наиболее активен в определенных каналах, а затем вам нужна дистилляция или резюме того, о чем этот канал, и вам нужно векторизовать это, а затем вам нужно оценить это против наиболее частых участников. >> но этого недостаточно. Вам нужно связать это обратно с данными SCM, чтобы выяснить, кто настоящие эксперты. Одна из проблем, с которой я лично сталкивался в некоторых организациях, в которых я работал, заключается в том, что у вас есть, скажем, шумный младший инженер. >> Так что они очень шумные. Они любят говорить, но соотношение сигнала к шуму невелико. И >> то, что кто-то не говорит много вещей, не означает, что его сообщения не имеют влияния. Так что часть этой игры заключается в оценке влияния >> когда люди говорят определенные вещи, знаете ли, как это связано с PR, которые появляются в результате? Сколько из этих PR объединяются? Знаете ли, такие вещи. >> Да. >> О, разве нет? >> Должно быть. Хорошо, проверьте это. >> Ну, вы должны иметь возможность открыть pull request. Вы не можете пушить в main. >> Хорошо. >> Так что, если это, если это ситуация, но я имею в виду, мы проверим. >> Да, вы должны иметь возможность создать ветку. >> О, нет, нет. Вы не можете форкнуть репозиторий. >> О. Эм, да, форки могут быть отключены. >> Это будет открытый исходный код, скажем, к концу недели. >> И все ваши вклады будут на нем. Что действительно весело, так это использовать этот инструмент социальной графы позже против вашего собственного репозитория и, скажем, показывать его вашей команде. >> Да. >> О, извините. >> О, я приду. Мне нравится это. Unblock попытался ответить вам на этот вопрос. >> О, вы видите этот автоматический ответ Slack? Извините. Вы здесь? Это камера. Извините. >> О, ничего страшного. Я просто О, хорошо. >> Позвольте мне проверить. Этого не должно быть. Хорошо. Дайте мне знать, если вам все еще нужен приглашение в GitHub. >> Просто проверьте участников. Я думаю, там может быть, да, там может быть проблема. Секунду. О, это были прямые назначения. Так что, я думаю, нам нужно >> втянуть людей в весь проект, потому что они не назначены организации. >> О, GitHub, я люблю тебя. >> 09 часов безотказной работы. >> Да, мы исправим это. Да. Загрузите всех. Давайте. >> Вы получили. Я пытаюсь, потому что теперь нам просто нужно добавить людей. >> Перейдите в настройки, соавторы. unblocked. У всех вас есть права на запись. Это название компании. >> Просто подтвердите это для нас, если хотите. >> Да, пожалуйста, дайте мне знать. >> Отлично. >> Хорошо. Хорошо. Мы получаем реальные PR сейчас. Вот так. Отлично. Отлично. >> Черт возьми. Теперь давайте делать веселые вещи. Хорошо, выглядит хорошо. >> Что? >> Я думаю, мы получили наш первый одобренный PR. Я отправляю, я просто отправляю нелепые чаты в unblock, чтобы вы могли видеть, как он пытается отвечать на вопросы в Slack по мере поступления PR. Я собираюсь посмотреть, что он скажет об этом. >> Попросите его >> Это как О, дайте мне подумать об этом. >> О, вы спросили его о PR? >> Да, но PR, я думаю, вы приняли. Так что посмотрим, что произойдет. >> Да, я имею в виду, он одобрил его. Так что, знаете ли, unblocked был >> unblocked, это выглядит хорошо, чувак. заблокирован. >> Видно только вам. О нет. >> Какой хороший ответ был. >> Отличный PR. Хорошая работа, unblock. Отличный ответ. >> Да. О, да. Да. Я верну его. Я верну его. Секунду. >> Эм, куда он делся? На самом деле, я потерял его здесь. >> О, да. Обрабатывать источники или что-то еще. >> Вы хотите приложение? >> Да, конечно. Да. >> О, да. Да. >> Да. Конечно. Мы были сосредоточены на вашем строительстве, но Да. >> Что мне делать? >> О, нет, все в порядке. Я имею в виду, давайте. >> О. О, >> Я, извините. Так что эта, эта вещь, которую я показывал раньше, это проект, который существует в этом репозитории. >> Так что >> О, так идея такая, скажем, подумайте о функциях, которые вы хотите добавить, или о вещах, которые вы хотите исправить, или о новых компонентах, а затем просто взломайте это и отправьте PR. >> Извините. >> Да, моя вина. >> Эм, вы хотите открыть, скажем, терминальную сессию и показать MCP? >> О, конечно. Да, потому что я, люди, очевидно, могут использовать его, но у них нет всего нашего исходного кода. Да. >> Консультант хотел попробовать предложить его клиенту. Я не могу показать контекст или, возможно, получить IDE. Ну, я имею в виду, одна вещь, которую вы можете сделать, >> если вы посещаете клиентов, вы можете спросить их, запускают ли они инструмент на своем >> на своем >> репозитории, и тогда он сгенерирует этот результат для них, чтобы они могли увидеть на своем собственном проекте, в чем ценность. >> Я думаю, Питер, я думаю, он просто спрашивает о нашем продукте конкретно, а не об этом. >> О, unblocks. Вы спрашиваете об unblocked. >> Моя вина, чувак. >> Мы едем так. >> Извините, извините. Односторонняя дорога. >> Итак, ваш вопрос в том, как вы можете продемонстрировать ценность unblock клиентам или >> увидеть ценность. >> Да. >> Извините. >> Да. >> Вы можете создавать конфликты в вашем приложении, но >> а затем есть уровень соответствия, который очень интересен для корпоративных клиентов. >> Я думал, как это >> переводится в UX, потому что, знаете ли, >> многие люди не понимают, это в основном для кодирования. Да. >> И предназначено ли это для технических людей или, возможно, знаете ли, людей, контролирующих инженеров, или самого инженера, я имею в виду, просто увидеть, как работает ваша платформа. Но если это вне контекста, я имею в виду, это нормально. >> Нет, нет, это совершенно нормально. Так что эта панель управления — это своего рода >> фронтенд-интерфейс клиента к продукту. Так что, знаете ли, вы заходите сюда и можете задать любой вопрос о вашем кодовом базе или вашей организации и получить ответ здесь. >> Это сейчас, знаете ли, подключено к, извините, я потерял свой курсор. Это подключено к >> этому тестовому репозиторию, который у нас есть, но я мог бы использовать его против unblocked, и я мог бы сказать, например, >> у меня есть небольшая горячая штука здесь, которую я могу показать. Ой. >> Так что движок исходного кода — это внутренний компонент, который мы используем для отслеживания изменений исходного кода с течением времени, включая, например, где >> изменения перемещаются между файлами и так далее. >> Так что в качестве демонстрации, знаете ли, вы можете показать, я имею в виду, вы можете забронировать своих клиентов для демонстрации с нами, и мы можем продемонстрировать это, или вы можете подключить его к своей собственной организации и продемонстрировать этот поток клиентам >> и попытаться найти, знаете ли, варианты использования, где источники данных конфликтуют, и продемонстрировать, что проблема с контекстными движками заключается в том, что очень трудно продемонстрировать ценность кому-то, не подключив его на самом деле. Так что есть небольшие накладные расходы, где люди должны подключить его ко всем своим интеграциям. Теперь хорошая новость заключается в том, что >> unblocked имеет бесплатный пробный период для предприятий, поэтому люди могут попробовать продукт в его полной форме, прежде чем >> платить за него. Да. >> Так что, если какая-то из этой информации неверна, вы можете просто ответить в чат-боте или пометить ее в ссылках. >> Точно. Да. Так что вы можете просто ответить здесь или сказать «не полезно» и объяснить почему, и тогда >> он дистиллирует это для следующего, следующего раунда. >> Так что он будет корректировать некоторые веса или оценки уверенности внутри. >> Эм, ну, внутри он конструирует память задач. >> Так что, >> он ищет такие повторяющиеся сигналы, и >> это на самом деле то, где используется граф экспертов. Он используется много. >> Граф экспертов обеспечивает >> вес. Так что, когда приходит эксперт и говорит, что это неверно, это получит больший вес и дистиллирует память для него. >> если >> это просто новый инженер, который говорит, что это неверно, то это не очень надежный источник. Так что >> вам нужен надежный источник, на котором можно основываться. Это имеет смысл? >> Да, это имеет большой смысл. Это как социальная сеть. >> Точно. Как-то. >> Да. Да. >> Спасибо. >> Пожалуйста. >> Круто. >> О, под капотом. >> Ну, когда это представлено ИИ, это представлено как файлы. >> но под капотом мы храним это в, знаете ли, таблицах баз данных и тому подобном. >> например, воспоминания >> состоят из множества различных источников. Так что они не просто основаны на плоских файлах, знаете ли, вся конструкция памяти будет гидратирована во время выполнения. Так что >> вы просто дадите свои инструменты вашей базе данных на основе любых критериев пользователей? >> Да. Ну, для >> Да. Так что, да, есть набор инструментов для извлечения данных. Для памяти конкретно, >> вы не можете просто оставить это на усмотрение агента для гидратации памяти, потому что это своего рода часть начального контекста. Чтобы агент двигался в правильном направлении, вы должны снабдить его соответствующими данными, а контекст экспертов — это хорошая отправная точка для агента. Так что, да. Да. >> Есть ли какой-нибудь официальный бенчмарк, который отслеживает тип ценности, которую вы пытаетесь принести, например, >> да, потому что я чувствую, что это не совсем кодирование, или это так, но да, мне интересно, есть ли какие-нибудь >> общедоступные вещи, которые вы отслеживаете сами. >> Так что у нас есть некоторые внутренние бенчмарки. >> Вы правы, это немного расплывчато. >> Эм, так что антро, вы слышали, как Борис Черни говорил >> в cloud code? Это как создатель cloud code. >> Создатель cloud code. Да. Так что он >> дал это интервью, где они говорили о том, как они измеряют успех >> для cloud code внутри. Это могло измениться, потому что сейчас много бенчмарков, у них есть, у них есть, скажем, бенчмарк talk. Вы, вероятно, видели его. >> но что это действительно сводится к этому, это вайбы. И поэтому самое важное в >> системах, подобных этой, — это захватить настроение. И поэтому, если ваше настроение >> имеет тенденцию к росту, то >> это хорошо. Наше настроение сейчас >> по шкале от -100 до 100 где-то около 60 >> оценка 60. Так что в нормализованной шкале это примерно 0,75-0,8. Так что, так что вайбы будут захвачены чем-то вроде, возможно, меньшего количества обмена сообщениями в PR, или, возможно, >> я не знаю, у вас меньше обмена сообщениями с облачными кодами, чтобы сделать свою работу. >> Да. Так что вайбы — это, они, они люди довольны, верно? Так что удовлетворение может исходить из многих источников, а недовольство — из многих источников. Так что способ думать об этом заключается в том, что он кодирует все эти вещи. >> но вы можете захватить конкретные метрики, и мы делаем это: сколько времени занимают вещи, и мы на самом деле сейчас очень усердно работаем над снижением >> времени отклика, потому что >> ну, хотя агенты >> вот что интересно: по мере того, как мы движемся к более автономной вселенной, время отклика для серверов MCP становится все менее и менее важным. Более важным является то, что они получают абсолютно точный ответ. >> Да. >> И причина в том, что >> количество времени, которое контекстный движок тратит на сбор всей этой информации и ее дистилляцию, является микрокосмом того, что занимает полная задача для реализации и прохождения. >> Так что, если вы можете потратить немного больше времени и сократить реализацию на 60-70-80%, это огромная победа, верно? И продолжайте. >> Извините, очень маленькое дополнение. На самом деле, мне интересно, есть ли у вас какие-нибудь приблизительные >> цифры о том, сколько времени тратится на извлечение контекста по сравнению с выполнением задачи, по вашему мнению? Например, это 10% сейчас, 90%, или я понятия не имею. Я имею в виду, у меня есть свой собственный опыт. >> Это как, да, эм, сбор контекста агента, вероятно, близок к этому числу. Это как 90%. >> фактическая часть написания кода очень, очень быстрая. Если вы можете даже просто наблюдать, что делает агент. >> когда он пишет код, выходные токены, кстати, это то, что замедляет >> производительность. Все раньше думали, что это входные токены. Мы провели множество экспериментов с этим. Вы можете увеличить размер входных токенов, и, знаете ли, время до первого выходного токена сейчас довольно хорошее. Как это очень оптимизировано. То, что действительно влияет на производительность, — это выходные токены. >> Так что вам нужно быть, скажем так, осмотрительным в том, как вы собираете и предоставляете контекст обратно агенту, чтобы он оставался плотным в своих выходных циклах. >> Для >> одного бенчмарка, который Питер упомянул в докладе, мы дали амбициозную задачу, потому что, очевидно, это зависит от промпта, сколько времени вы добавляете, и, скажем, с контекстным движком. >> но амбициозная задача, которую мы дали, заключалась в реализации нового режима адаптивного мышления в цепочке инструментов антропиков, когда они его представили, что, как упоминалось, заняло от 25 минут до 2,5 часов с unblock с контекстным движком. Другой случай без него занял 2,5 часа. Но основная причина этого заключалась в том, что мы дали ему все данные. Мы запустили промпт, и тогда его первый вывод был совершенно неправильным. Так что пришлось, человек должен был повторить и сказать: нет, нет, нет, это, это, это, а следующий вывод был неправильным, а следующий вывод. Так что, когда вы делаете четыре цикла, у вас есть около 2,5 часов реального времени по сравнению, очевидно, с 25 минутами, когда он не соответствовал этому, когда исправления не требовались. >> Эм, как упоминалось, думайте об этом как о водопаде. Чем больше высококачественного, правильного, высокосигнального контекста у вас есть заранее, тем лучше будет каждое действие агента, пока он не скажет, что закончил, правильно он это сделал или нет. Да. >> Да. >> Он понял. >> Вы также упомянули, что использование токенов для вызовов инструментов и просто поиска информации действительно уменьшилось. Так что я знаю, что многие из этих инструментов, которые предоставляют >> или агрегаторы для использования инструментов, имеют безумное, скажем, использование токенов. Так что, возможно, у вас есть какие-то оценки того, как, скажем, мне нужен разговор в Slack, какое-то резюме от одного разговора к другому, или как люди взаимодействуют, там будет 60 тысяч токенов на composio, я задаюсь вопросом, сколько токенов будет использоваться unblocked? >> да, меньше, мы все еще очень ориентированы на вайбы, так что трудно получить реальные данные от других клиентов или людей на рынке. >> Но опять же, с той же задачей, я буду продолжать говорить о той же задаче, это легко. Эта задача прошла от общего использования 21 миллиона токенов до 10 миллионов токенов с контекстным движком. Так что часть этого заключается в том, что вам не пришлось делать цикл. >> Так что, когда, конечно, это увеличило расходы на токены, так что мы снизили их на 50% на большой задаче. Опять же, очевидно, если вы говорите, я центрирую div, вы не получите большого выигрыша. Это как бы в обучающих данных. >> но да, как любая функция >> исправление, так что много, как опять же, много того, что люди пропускают через unblocked, это то, что инженер делает каждый день. Очень редко, когда вы выполняете задачу, которая настолько, я не знаю, незначительна, что, я имею в виду, опять же, я просил Клода сделать git push, так что я не единственный, я уверен, я был как, ты сделай это. Это как, почему это стоило мне 30 центов? Я не знаю. >> Да, я приложил все усилия, чтобы правильно разместить свои ключи GBG, так что я, типа, Cloud Go. Еще вопросы, пока вы все отправляете? Любое замешательство? Что-нибудь, что я могу разблокировать для вас? Это моя цель в жизни. >> Извините, вы, возможно, уже ответили на этот вопрос, но >> так вы используете knowledge b knowledgebase rag в unblocked или что именно вы представляете? >> О, так много всего. >> Я могу подойти поговорить с вами сбоку. Я сниму микрофон. Я просто отвечу на этот вопрос. >> Конечно. >> Это было просто >> это талантливо. Да. >> О, это в реальном времени, по сути. Так что, >> есть, я думаю, две части этого вопроса. Одна — это, скажем, сколько или как часто unblocked обновляет данные на бэкэнде. >> Так что это в реальном времени для многих интеграций, а для других — по расписанию cron, потому что для этих конкретных интеграций у них нет веб-хуков, по сути. >> Да. Но дистилляция >> это означает, что перестроение данных графа должно происходить очень часто. Да. >> Да. >> Да. >> Да. >> Нет, это инкрементально. Так что наш >> алгоритм построения социальной графы имеет инкрементальный компонент. Так что нам не нужно перезапускать все. >> но также >> социальные графы менее чувствительны к частым изменениям данных, потому что маловероятно, что, знаете ли, одно изменение окажет огромное влияние на граф экспертов, если только ваша организация не новая. Так что для >> Да. >> Да. Так, например, >> мы выполняем дистилляцию лучших практик с гораздо более низкой частотой, скажем, еженедельно, потому что, да, она просто не так сильно меняется. >> Да. >> Ну, О, да. Повторите свой вопрос. Это хороший вопрос. Так что я хочу убедиться, что мы его запишем. О, >> с точки зрения конфиденциальности клиентов, хранения данных >> вроде >> да, с моей точки зрения, я думаю о, скажем, корпоративном SAS или даже о локальных развертываниях, которые я не предполагаю, что вы, я просто думаю о таком типе клиентов. >> >> да, вы получаете, вы получаете отпор? Вы, как они относятся к тому, что вы храните данные? Это еще один процессор в цикле. >> Ну, так, обсуждения конфиденциальности происходят на организационном уровне. Так что это >> мы на самом деле не сталкиваемся с большим трением. >> Есть определенные среды, такие как государственные учреждения и банки, которые имеют сверхчувствительные потребности, и для этих потребностей у нас есть локальное решение, но это определенно не тот путь, который я бы рекомендовал, оставаясь в облаке, как мы имеем очень крупные корпоративные организации, которые полностью облачные, полностью облачные. >> >> секретный соус, скажем так, меньше кодируется в исходном коде сейчас, а больше кодируется в >> рассуждениях. >> Так что организации, как правило, более чувствительны к таким вещам, как данные Slack, например, но >> то, как мы храним данные, как у нас есть целая белая книга о том, как мы защищаем данные клиентов, и это никогда не было проблемой. >> Да. >> Простите? Вы можете работать локально? >> Да, у нас есть локальное решение, но, как я уже сказал, это не рекомендуемый подход, но для чувствительных сред, конечно. Да. >> О, почему это не рекомендуется? >> Ну, облачные интеграции, знаете ли, обновляются чаще, и поэтому есть исправления программного обеспечения. Внутри организации их немного сложнее поддерживать. >> есть один клиент, это банк, где администрирование >> платформы становится довольно сложным, потому что у них есть сетевая изоляция, и поэтому теперь один из нас должен, знаете ли, находиться в этой сети и администрировать платформу, или мы должны обучить >> отдельных лиц внутри компании администрировать платформу. Так что это просто больше упражнение по обслуживанию и >> поддержке. Но да. >> Да, именно так. >> Да. Спасибо. Спасибо, что пришли. Большое спасибо.