ИИ пашет, Саша одобряет
Grep vs структурный AST-поиск на больших проектах У агентов есть базовая проблема: когда они начинают что-то искать в рабочем проекте на 15-20К+ файлов, можно пойти налить кофе, выпить его, вернуться, а он всё ещё будет грепать. В январе, после почти полугода…
Ускорил индексацию в 3.6 раза, новый фича флаг в ast-index v3.43.1
Как попробовать?
Недавно позвали на одну из внутренних встречек рассказать про ast с метричками и всяким подобным, в итоге ребята накидали разные идеи + увидели что условный проект 250К файлов индексируетс за 400-500 секунд и это как-то долго выходит.
В общем сел вечером и начал изучать, а где вообще проблема в скорости и что можно сделать? Тут сразу нашел узкое место это запись батчей в sql базу + скорость волкера по дереву файлов и разные не большие оптимизации с транзакциями в базу.
В общем ускорение на проекте в 32 К файлов до 11 секунд, я еще сел и подумал, а что если можно еще ускроить?
И в общем начал пробовать, потом запустил индексацию огромного проекта и где-то после его половины, на такой скорости я загнал мак в ребут. 🫠
Ошибся, но где?
Дальше буду отдельно еще изучать перфоманс, в данном случае погубила жадность))
В общем понял, что лучше под экспериментальным флагом иметь стабильную реализацию безопасную и после этого откатился до ускорения в 3.6 раза
А зачем вообще это ускорение?
На проектах в 30К файлов будто не сильно важно, но ребята приходят с тем, что хотят работать из корня репозитория своего БЮ и индексировать сразу все, такие дела)
Пробуйте фичу, должно быть полезно прям на огромных проектах. Ну и сильно приятнее с индексацией проектов на 10-30 К файлов за считанные секунды.
Как попробовать?
ast-index rebuild --experimental-fast-rebuild
Недавно позвали на одну из внутренних встречек рассказать про ast с метричками и всяким подобным, в итоге ребята накидали разные идеи + увидели что условный проект 250К файлов индексируетс за 400-500 секунд и это как-то долго выходит.
В общем сел вечером и начал изучать, а где вообще проблема в скорости и что можно сделать? Тут сразу нашел узкое место это запись батчей в sql базу + скорость волкера по дереву файлов и разные не большие оптимизации с транзакциями в базу.
В общем ускорение на проекте в 32 К файлов до 11 секунд, я еще сел и подумал, а что если можно еще ускроить?
И в общем начал пробовать, потом запустил индексацию огромного проекта и где-то после его половины, на такой скорости я загнал мак в ребут. 🫠
Ошибся, но где?
Дальше буду отдельно еще изучать перфоманс, в данном случае погубила жадность))
В общем понял, что лучше под экспериментальным флагом иметь стабильную реализацию безопасную и после этого откатился до ускорения в 3.6 раза
А зачем вообще это ускорение?
На проектах в 30К файлов будто не сильно важно, но ребята приходят с тем, что хотят работать из корня репозитория своего БЮ и индексировать сразу все, такие дела)
Пробуйте фичу, должно быть полезно прям на огромных проектах. Ну и сильно приятнее с индексацией проектов на 10-30 К файлов за считанные секунды.
❤13👍5
Нужен ли код-ревью процесс в AI-first компаниях?
Годами мы делали ревью кода, чтобы держать проекты в порядке, обучать коллег и расширять общий инженерный кругозор.
Но с появлением агентов объем кода резко вырос. И PR-ревью очень быстро стало узким горлышком. Сначала люди еще пытались внимательно смотреть изменения, но за последние месяцы во многих командах это часто превращается в формальность: approve без глубокого просмотра.
Почему так происходит?
Во-первых, многое уже покрыто тестами, автотестами, CI-checks и прогонами на фермах. Критичные сценарии проверяются автоматически лучше и стабильнее, чем человеком в PR.
Во-вторых, после ревью, само тестирование задач тоже становится узким горлышком. Поэтому команды начинают искать путь, где код после успешного пайплайна просто едет дальше быстрее, без лишних ручных блокеров.
В итоге получается странная ситуация: код-ревью формально есть, но как реальный процесс проверки кода людьми оно постепенно исчезает.
Из этого, как мне кажется, следует простая вещь: если у вас хорошо настроены агенты под задачи команды, если они в большинстве случаев пишут надежный код, учитывают edge cases, а качество дополнительно держат тесты и CI/CD, то обязательное ручное ревью каждого PR теряет смысл.
Что остается вместо этого?
Остается пайплайн: PR, автоматические проверки, при необходимости тестирование, и дальше заливка. А если регресс все же случился, команда быстро доливает фикс. Это снимает главный блокер скорости: человеческий фактор в ревью.
Мое мнение: в агентской разработке сплошное ревью всех PR людьми или агентами будет приносить только убытки и не давать никакого эффекта. Особенно для внутренних систем, админок и low-risk задач.
Скорее всего, будущее за полным отказом от ревью в 90% задач, оно может остаться в агентском виде только в областях с высоким риском что-то сломать.
А вы думали вообще что будет с такими процессами в Ai-first компаниях?
Годами мы делали ревью кода, чтобы держать проекты в порядке, обучать коллег и расширять общий инженерный кругозор.
Но с появлением агентов объем кода резко вырос. И PR-ревью очень быстро стало узким горлышком. Сначала люди еще пытались внимательно смотреть изменения, но за последние месяцы во многих командах это часто превращается в формальность: approve без глубокого просмотра.
Почему так происходит?
Во-первых, многое уже покрыто тестами, автотестами, CI-checks и прогонами на фермах. Критичные сценарии проверяются автоматически лучше и стабильнее, чем человеком в PR.
Во-вторых, после ревью, само тестирование задач тоже становится узким горлышком. Поэтому команды начинают искать путь, где код после успешного пайплайна просто едет дальше быстрее, без лишних ручных блокеров.
В итоге получается странная ситуация: код-ревью формально есть, но как реальный процесс проверки кода людьми оно постепенно исчезает.
Из этого, как мне кажется, следует простая вещь: если у вас хорошо настроены агенты под задачи команды, если они в большинстве случаев пишут надежный код, учитывают edge cases, а качество дополнительно держат тесты и CI/CD, то обязательное ручное ревью каждого PR теряет смысл.
Что остается вместо этого?
Остается пайплайн: PR, автоматические проверки, при необходимости тестирование, и дальше заливка. А если регресс все же случился, команда быстро доливает фикс. Это снимает главный блокер скорости: человеческий фактор в ревью.
Мое мнение: в агентской разработке сплошное ревью всех PR людьми или агентами будет приносить только убытки и не давать никакого эффекта. Особенно для внутренних систем, админок и low-risk задач.
Скорее всего, будущее за полным отказом от ревью в 90% задач, оно может остаться в агентском виде только в областях с высоким риском что-то сломать.
А вы думали вообще что будет с такими процессами в Ai-first компаниях?
👍8🤯4😁1
Нужны ли IDE в новых реалиях?
Тут, по личному опыту, студии всегда жрали очень много оперативы, мешали работать и подбешивали.
Условно, Android Studio базово всегда отжирала 8-16 Гб. Хоть на маке и 36 Гб, но если добавить индексацию в IDE и запустить какой-нибудь билд, мы получаем зависающее приложение и подтормаживающий мак, потому что уходим в своп по памяти.
Еще в сентябре, когда начал использовать Клода, я задумался: а зачем мне вообще ее открывать?
Но в целом еще какое-то время, примерно до ноября, держал ее открытой, чтобы посмотреть код или что-то найти.
И в какой-то момент подумал: а зачем она мне вообще нужна?
К ноябрю я как раз уже достроил своего агента для выполнения задачек, описал правила и воркфлоу, плюс проводил через него первичное ревью, а дальше только по критичным вещам пробегался в PR.
И вот это постоянное дополнительное пожирание памяти очень мешало, особенно когда агенты начинали делать рабочие задачки в 2-3 рабочих деревьях и ресурсы становились главным узким горлышком всей работы.
Доходило до того, что мак просто висел, и ни я, ни агенты не могли нормально работать, что в итоге сильно просаживало производительность и качество.
Что было дальше?
Тут все просто: я снес IDE и пошел в сторону допиливания работы с агентами, создания для них инструментов под себя, чтобы стабильно получать высокое качество задачек.
Жалею ли я о том, что больше не использую IDE?
Ни разу не пожалел. На самом деле все поделилось на до и после: это позволило осознать, что студии только мешали работать. И даже если надо что-то глянуть, проще открыть файл через open в терминале.
Ну и в целом отказ от студий позволил взглянуть на разработку с агентами под другим углом, лучше понять, какие есть недостатки и проблемы, и пойти в их точечное решение вместо попыток дальше работать по-старому.
Кстати, по опыту других ребят вокруг тоже слышу, что они полностью отказались от использования IDE.
А вы еще пользуетесь студиями или уже тоже отказались?
Тут, по личному опыту, студии всегда жрали очень много оперативы, мешали работать и подбешивали.
Условно, Android Studio базово всегда отжирала 8-16 Гб. Хоть на маке и 36 Гб, но если добавить индексацию в IDE и запустить какой-нибудь билд, мы получаем зависающее приложение и подтормаживающий мак, потому что уходим в своп по памяти.
Еще в сентябре, когда начал использовать Клода, я задумался: а зачем мне вообще ее открывать?
Но в целом еще какое-то время, примерно до ноября, держал ее открытой, чтобы посмотреть код или что-то найти.
И в какой-то момент подумал: а зачем она мне вообще нужна?
К ноябрю я как раз уже достроил своего агента для выполнения задачек, описал правила и воркфлоу, плюс проводил через него первичное ревью, а дальше только по критичным вещам пробегался в PR.
И вот это постоянное дополнительное пожирание памяти очень мешало, особенно когда агенты начинали делать рабочие задачки в 2-3 рабочих деревьях и ресурсы становились главным узким горлышком всей работы.
Доходило до того, что мак просто висел, и ни я, ни агенты не могли нормально работать, что в итоге сильно просаживало производительность и качество.
Что было дальше?
Тут все просто: я снес IDE и пошел в сторону допиливания работы с агентами, создания для них инструментов под себя, чтобы стабильно получать высокое качество задачек.
Жалею ли я о том, что больше не использую IDE?
Ни разу не пожалел. На самом деле все поделилось на до и после: это позволило осознать, что студии только мешали работать. И даже если надо что-то глянуть, проще открыть файл через open в терминале.
Ну и в целом отказ от студий позволил взглянуть на разработку с агентами под другим углом, лучше понять, какие есть недостатки и проблемы, и пойти в их точечное решение вместо попыток дальше работать по-старому.
Кстати, по опыту других ребят вокруг тоже слышу, что они полностью отказались от использования IDE.
А вы еще пользуетесь студиями или уже тоже отказались?
👍11
Релиз ast-index 3.44.0
Вышла новая версия инструмента https://github.com/defendend/Claude-ast-index-search/releases/tag/v3.44.0
C++ поиск стал namespace-aware: теперь работают и symbol Client, и symbol foo::bar::Client, плюс pattern-поиск вроде ::Client и foo::bar*
rebuild и update стали надежнее: безопаснее SQL query, корректнее работа с include и extra roots
часть безопасных оптимизаций rebuild вынес в дефолт из под флага (--experimental-fast-rebuild) и добавил новые бенчи для индексации / update / module graph / Android XML+resources
В общем фикс мелких ишью от ребят из c++, теперь ast там наконец-то умеет в базу)))
Ну и базовые ускорения ребилда без эксп флага, конечно чем больше юзеров, тем аккуратнее приходится делать обновления 🫠
Тут уже не скажешь клоду/кодексу как в начале, го с питона на раст разом перепишем, хоть и было все покрыто тестами)))
upd: поддержаны enum для парсинга в плюсах 3.44.2
Вышла новая версия инструмента https://github.com/defendend/Claude-ast-index-search/releases/tag/v3.44.0
C++ поиск стал namespace-aware: теперь работают и symbol Client, и symbol foo::bar::Client, плюс pattern-поиск вроде ::Client и foo::bar*
rebuild и update стали надежнее: безопаснее SQL query, корректнее работа с include и extra roots
часть безопасных оптимизаций rebuild вынес в дефолт из под флага (--experimental-fast-rebuild) и добавил новые бенчи для индексации / update / module graph / Android XML+resources
В общем фикс мелких ишью от ребят из c++, теперь ast там наконец-то умеет в базу)))
Ну и базовые ускорения ребилда без эксп флага, конечно чем больше юзеров, тем аккуратнее приходится делать обновления 🫠
Тут уже не скажешь клоду/кодексу как в начале, го с питона на раст разом перепишем, хоть и было все покрыто тестами)))
upd: поддержаны enum для парсинга в плюсах 3.44.2
🔥9😁2
Поздно ли вкатиться в работу с ИИ на продвинутом уровне?
Многие сейчас считают, что большиство очень хорошо разбираются в Ai и том как его настраивать и как следствие сидят с мнением, да что я там вообще могу сделать?
Как по мне в таком мнение и есть ловушка, которая мешает вам увидеть, что на самом деле большая часть людей сейчас на уровне: "у нас в проекте настроили агентов, у меня работает, что еще можно сделать то?".
Причем они сами просто не могут настроить их вообще и не понимают как и если чего-то нет в проекте, то так и будут жить.
Ну а как вообще вкатиться то?
Есть несколько классных способов, для начала возьмите себе подписку, в текущей ситуации советую кодекса, так как там почти безграничные лимиты на текущий момент.
Имея подписку, попробуйте начать каждый день общаться с агентами и пилить с ними какие-нибудь штуки + экспериментировать, так как такое число ресурсо позволяет играться как хочется и ни в чем себе не отказывать.
А какие еще способы есть?
Постоянно читать разные статьи, инфу, но ее уже столько, что это будет выглядеть как какой-то ад.
А как вообще лично я вкатывался?
Мой товарищ, Леша Гладков потратил кучу времени и сделал классные челленджи на 30 дней, еще до нового года, суть была простой, каждый день есть задание, которое не сделать руками вообще, а если не сделаешь вылетаешь сразу.
Я как раз принял участие для разнообразие в обычном (одном из первых, до нового года) и продвинутом, прошел оба и было прям весело и очень много пользы, а также принесло кучу знакомств с крутыми ребятами.
И вот как говорит сам Леша, он делает одни из последних челленджей своих и дальше с ними завязывает, 1 июня и еще один чуть позже. Проводит его он лично, и общается со всеми в чатике, можно обсудить много интересного кроме челленджа и познакомиться с другими крутыми ребятами.
Если интересно загляните к нему
Постик:
https://t.me/alexgladkovblog/6993
Сайт:
https://mobiledeveloper.tech/ai_advent_8
Ну и я с ним договорился на промик от меня, копеечка, но приятно)
Многие сейчас считают, что большиство очень хорошо разбираются в Ai и том как его настраивать и как следствие сидят с мнением, да что я там вообще могу сделать?
Как по мне в таком мнение и есть ловушка, которая мешает вам увидеть, что на самом деле большая часть людей сейчас на уровне: "у нас в проекте настроили агентов, у меня работает, что еще можно сделать то?".
Причем они сами просто не могут настроить их вообще и не понимают как и если чего-то нет в проекте, то так и будут жить.
Ну а как вообще вкатиться то?
Есть несколько классных способов, для начала возьмите себе подписку, в текущей ситуации советую кодекса, так как там почти безграничные лимиты на текущий момент.
Имея подписку, попробуйте начать каждый день общаться с агентами и пилить с ними какие-нибудь штуки + экспериментировать, так как такое число ресурсо позволяет играться как хочется и ни в чем себе не отказывать.
А какие еще способы есть?
Постоянно читать разные статьи, инфу, но ее уже столько, что это будет выглядеть как какой-то ад.
А как вообще лично я вкатывался?
Мой товарищ, Леша Гладков потратил кучу времени и сделал классные челленджи на 30 дней, еще до нового года, суть была простой, каждый день есть задание, которое не сделать руками вообще, а если не сделаешь вылетаешь сразу.
Я как раз принял участие для разнообразие в обычном (одном из первых, до нового года) и продвинутом, прошел оба и было прям весело и очень много пользы, а также принесло кучу знакомств с крутыми ребятами.
И вот как говорит сам Леша, он делает одни из последних челленджей своих и дальше с ними завязывает, 1 июня и еще один чуть позже. Проводит его он лично, и общается со всеми в чатике, можно обсудить много интересного кроме челленджа и познакомиться с другими крутыми ребятами.
Если интересно загляните к нему
Постик:
https://t.me/alexgladkovblog/6993
Сайт:
https://mobiledeveloper.tech/ai_advent_8
Ну и я с ним договорился на промик от меня, копеечка, но приятно)
AI8W1K
❤5👍2
Claude Code, Codex или OpenCode: что бы я выбрал сейчас?
После последних решений Anthropic с банами, закручиванием гаек и ощущением, что модели стали работать тупее, мне в какой-то момент это надоело. Решил, что пора что-то менять, и отнес свои $200 в OpenAI.
Жалею ли я об уходе с Claude Code?
Нет, пока ни разу не пожалел. Достаточно быстро мигрировал свои процессы и работу агентов под флоу в Codex: условно по 15-30 минут на один проектик, причем часть можно было делать параллельно.
Почему именно Codex, а не что-то другое?
Первая причина — на текущий момент очень большие лимиты. Они позволяют дальше экспериментировать с разными агентскими штуками, не думать постоянно о расходе и продолжать искать более эффективные и дешевые подходы.
Вторая — удобство самого приложения Codex для менеджмента кучи проектов и окон. Когда у тебя работа уже превращается в переключение между десятью окнами, когнитивно это становится тяжело вывозить.
Почему не OpenCode?
Тут все просто: я сторонник идеи, что универсальное решение под любых агентов и любые модели часто не вытаскивает максимум из конкретной модели.
Возможно, у каждого тут будет свое мнение, но мне кажется, что если у модели есть свой родной harness, то лучше начинать с него.
Не много ли $200 за подписку?
На Claude оно у меня заканчивалось довольно быстро, если себя не контролировать. А с Codex ситуация пока намного приятнее: можно буквально 24/7 работать над своим пулом проектов и не думать каждую минуту про лимиты.
В общем gpt-5.5 вообще не ни одной модели антропиков, а то и лучше чем они.
После последних решений Anthropic с банами, закручиванием гаек и ощущением, что модели стали работать тупее, мне в какой-то момент это надоело. Решил, что пора что-то менять, и отнес свои $200 в OpenAI.
Жалею ли я об уходе с Claude Code?
Нет, пока ни разу не пожалел. Достаточно быстро мигрировал свои процессы и работу агентов под флоу в Codex: условно по 15-30 минут на один проектик, причем часть можно было делать параллельно.
Почему именно Codex, а не что-то другое?
Первая причина — на текущий момент очень большие лимиты. Они позволяют дальше экспериментировать с разными агентскими штуками, не думать постоянно о расходе и продолжать искать более эффективные и дешевые подходы.
Вторая — удобство самого приложения Codex для менеджмента кучи проектов и окон. Когда у тебя работа уже превращается в переключение между десятью окнами, когнитивно это становится тяжело вывозить.
Почему не OpenCode?
Тут все просто: я сторонник идеи, что универсальное решение под любых агентов и любые модели часто не вытаскивает максимум из конкретной модели.
Возможно, у каждого тут будет свое мнение, но мне кажется, что если у модели есть свой родной harness, то лучше начинать с него.
Не много ли $200 за подписку?
На Claude оно у меня заканчивалось довольно быстро, если себя не контролировать. А с Codex ситуация пока намного приятнее: можно буквально 24/7 работать над своим пулом проектов и не думать каждую минуту про лимиты.
В общем gpt-5.5 вообще не ни одной модели антропиков, а то и лучше чем они.
👍18
Корзинки качества или симуляция общения с агентом?
Сейчас многие пытаются построить системы оценки качества AI-агентов: наборы кейсов, скоринги, ручную разметку, автопроверки, “корзинки качества”. Но насколько такие системы действительно отражают качество агента, вопрос сложный.
С одной стороны, мы получаем понятную численную оценку. С другой стороны, критерии часто размыты, зависят от людей-разметчиков и плохо ловят реальные сценарии общения.
Тут появляется другая идея: симуляция.
Симуляция — это возможность прогонять агента через диалоги в форматах агент-агент или человек-агент. Например, дать коллегам удобный интерфейс, чтобы они могли тестировать разные флоу, или создать отдельного агента, который играет роль пользователя с конкретным профилем, целью и поведением.
То есть мы можем тестировать агента не только на статичных кейсах, но и на “отложенных пользователях”: раздраженный клиент, новичок, человек с неполными данными, пользователь, который меняет цель по ходу диалога, и так далее.
Что выбрать?
Кажется, это не взаимоисключающие подходы. Корзинки качества помогают измерять, а симуляции помогают находить новые сценарии, собирать диалоги и улучшать сами критерии оценки.
В идеале нужна связка: симуляции генерируют реальные и пограничные сценарии, а система оценки превращает их в понятные метрики качества.
Возможно, ошибаюсь, но сейчас экспериментирую в эту сторону.
Как думаете, какие сценарии вы бы обязательно добавили в симуляцию?
Сейчас многие пытаются построить системы оценки качества AI-агентов: наборы кейсов, скоринги, ручную разметку, автопроверки, “корзинки качества”. Но насколько такие системы действительно отражают качество агента, вопрос сложный.
С одной стороны, мы получаем понятную численную оценку. С другой стороны, критерии часто размыты, зависят от людей-разметчиков и плохо ловят реальные сценарии общения.
Тут появляется другая идея: симуляция.
Симуляция — это возможность прогонять агента через диалоги в форматах агент-агент или человек-агент. Например, дать коллегам удобный интерфейс, чтобы они могли тестировать разные флоу, или создать отдельного агента, который играет роль пользователя с конкретным профилем, целью и поведением.
То есть мы можем тестировать агента не только на статичных кейсах, но и на “отложенных пользователях”: раздраженный клиент, новичок, человек с неполными данными, пользователь, который меняет цель по ходу диалога, и так далее.
Что выбрать?
Кажется, это не взаимоисключающие подходы. Корзинки качества помогают измерять, а симуляции помогают находить новые сценарии, собирать диалоги и улучшать сами критерии оценки.
В идеале нужна связка: симуляции генерируют реальные и пограничные сценарии, а система оценки превращает их в понятные метрики качества.
Возможно, ошибаюсь, но сейчас экспериментирую в эту сторону.
Как думаете, какие сценарии вы бы обязательно добавили в симуляцию?
👍6🔥3
ИИ пашет, Саша одобряет
Корзинки качества или симуляция общения с агентом? Сейчас многие пытаются построить системы оценки качества AI-агентов: наборы кейсов, скоринги, ручную разметку, автопроверки, “корзинки качества”. Но насколько такие системы действительно отражают качество…
А может, стоит остановиться и переосмыслить систему качества агентов, подойдя к ней под другим углом?
Сегодня прочитал очень интересную и полезную статью про качество агентов и способы их оценки.
Статья: https://www.howtoeval.com/
Идея простая, но очень сильная: прежде чем строить сложную систему качества, вернитесь в самое начало и начните каждый день читать реальные диалоги вашего агента с пользователями.
Что делать?
Запускаем → наблюдаем → анализируем → улучшаем → повторяем.
Если у вас уже 1000+ диалогов в день, стоит вычитывать хотя бы часть из них, например 50-100 диалогов. Именно так можно увидеть узкие места, повторяющиеся ошибки и моменты, где агент начинает сыпаться.
Еще одна классная идея — научить агента говорить «я не знаю» в тех случаях, где он действительно не уверен. Один плохой или неточный ответ может убить доверие, а доверие критически важно при внедрении агентов в общение с людьми.
Потеряв доверие один раз, вернуть его к вашему агенту будет очень сложно.
Что еще полезно отслеживать кроме самих диалогов?
По сути, нужно строить возможность видеть всю цепочку работы агента: сообщение пользователя, ответ агента, вызовы инструментов, контекст, промежуточные шаги. Это помогает лучше понимать поведение агента и находить краевые случаи, где он ошибается.
Еще интересная мысль — попробовать «поговорить» с той же моделью, передав ей историю чата и контекст агента, и спросить, почему она дала именно такой ответ. Это не абсолютная правда, но часто очень сильная подсказка, которая помогает понять, на что модель опиралась и где могла неверно интерпретировать задачу.
И тут появляется важная идея: а что если качество агентов на первом этапе строить вокруг возможности взять конкретный диалог, завернуть его в контекст, обсудить с моделью проблемные моменты или даже переиграть поведение с определенного шага?
Будто это дает совершенно новый способ тестировать агентов не в вакууме, а через реальные ситуации.
А если агенты уже работают на тысячах пользователей?
Тем более. Анализ их поведения и общения — один из лучших инструментов для улучшения. Без этого агенты будут ошибаться, не до конца выполнять исходную задачу и постепенно терять доверие пользователей.
Да, это может быть нудно. Но кажется, что такая работа полностью окупается: вы начинаете по-настоящему понимать поведение своего агента и получаете много конкретных идей, как его улучшить.
В общем, советую полностью прочитать статью и не гнаться за быстрым решением. Иногда полезнее остановиться и сначала понять, какое решение действительно нужно.
Будто в мире с ИИ мы стали слишком много бежать. Но, возможно, сейчас самое время остановиться и переосмыслить многое.
Сегодня прочитал очень интересную и полезную статью про качество агентов и способы их оценки.
Статья: https://www.howtoeval.com/
Идея простая, но очень сильная: прежде чем строить сложную систему качества, вернитесь в самое начало и начните каждый день читать реальные диалоги вашего агента с пользователями.
Что делать?
Запускаем → наблюдаем → анализируем → улучшаем → повторяем.
Если у вас уже 1000+ диалогов в день, стоит вычитывать хотя бы часть из них, например 50-100 диалогов. Именно так можно увидеть узкие места, повторяющиеся ошибки и моменты, где агент начинает сыпаться.
Еще одна классная идея — научить агента говорить «я не знаю» в тех случаях, где он действительно не уверен. Один плохой или неточный ответ может убить доверие, а доверие критически важно при внедрении агентов в общение с людьми.
Потеряв доверие один раз, вернуть его к вашему агенту будет очень сложно.
Что еще полезно отслеживать кроме самих диалогов?
По сути, нужно строить возможность видеть всю цепочку работы агента: сообщение пользователя, ответ агента, вызовы инструментов, контекст, промежуточные шаги. Это помогает лучше понимать поведение агента и находить краевые случаи, где он ошибается.
Еще интересная мысль — попробовать «поговорить» с той же моделью, передав ей историю чата и контекст агента, и спросить, почему она дала именно такой ответ. Это не абсолютная правда, но часто очень сильная подсказка, которая помогает понять, на что модель опиралась и где могла неверно интерпретировать задачу.
И тут появляется важная идея: а что если качество агентов на первом этапе строить вокруг возможности взять конкретный диалог, завернуть его в контекст, обсудить с моделью проблемные моменты или даже переиграть поведение с определенного шага?
Будто это дает совершенно новый способ тестировать агентов не в вакууме, а через реальные ситуации.
А если агенты уже работают на тысячах пользователей?
Тем более. Анализ их поведения и общения — один из лучших инструментов для улучшения. Без этого агенты будут ошибаться, не до конца выполнять исходную задачу и постепенно терять доверие пользователей.
Да, это может быть нудно. Но кажется, что такая работа полностью окупается: вы начинаете по-настоящему понимать поведение своего агента и получаете много конкретных идей, как его улучшить.
В общем, советую полностью прочитать статью и не гнаться за быстрым решением. Иногда полезнее остановиться и сначала понять, какое решение действительно нужно.
Будто в мире с ИИ мы стали слишком много бежать. Но, возможно, сейчас самое время остановиться и переосмыслить многое.
👍6🔥3
Тут недавно вышел пост, про то, что можно разместить рядом с своим решением ссылку на репо, думал и решил повесить туда ast по приколу, надо будет все же снова сходить на новое соревнование агентов, а то последнее 30 мая я просто проспал🫠
Просто его поставили в 11 вместо 14, еще и хаба в Око не было в этот раз, а значит и бесплатной еды, в итоге смысл соревноваться у меня был утерян😁
В прошлый раз я готовился с 11 до 14 до момента начала, возможно стоит чуть погонять заранее или не стоит))
Говорят в новом было весело, видимо надо идти и не скипать + настроить кэширование и тп на экономию денег🙃
Просто его поставили в 11 вместо 14, еще и хаба в Око не было в этот раз, а значит и бесплатной еды, в итоге смысл соревноваться у меня был утерян😁
В прошлый раз я готовился с 11 до 14 до момента начала, возможно стоит чуть погонять заранее или не стоит))
Говорят в новом было весело, видимо надо идти и не скипать + настроить кэширование и тп на экономию денег🙃
😁4
Forwarded from LLM под капотом
Как рассказать всему миру про свою архитектуру?
А заодно поделиться ссылками на github/LinkedIn блоги? Возможно найти новые интересные проекты?
Нужно прислать PR вот в эту github repo. Описание процесса в README.MD После обработки PR,
• ваш пост появится прямо на сайте в категории Insights
• в leaderboard появится ссылка на него (примеры PAC1)
А еще можно в insight указать model_names. И если использованы только локальные модели, то получите выделяющийся бэджик прямо в лидерборд!
Ждем!
Кому интересно увидеть какие-то архитектуры - пишите в комментарии, можно сразу с вопросами. Интерес очень мотивирует авторов!
Ваш, @llm_under_hood 🤗
А заодно поделиться ссылками на github/LinkedIn блоги? Возможно найти новые интересные проекты?
Нужно прислать PR вот в эту github repo. Описание процесса в README.MD После обработки PR,
• ваш пост появится прямо на сайте в категории Insights
• в leaderboard появится ссылка на него (примеры PAC1)
А еще можно в insight указать model_names. И если использованы только локальные модели, то получите выделяющийся бэджик прямо в лидерборд!
Ждем!
Кому интересно увидеть какие-то архитектуры - пишите в комментарии, можно сразу с вопросами. Интерес очень мотивирует авторов!
Ваш, @llm_under_hood 🤗
Интересно было бы статистику посмотреть, но как-то похоже на правду как по мне
Глава OpenAI Сэм Альтман заявил, что компании, которые активнее всех внедряют искусственный интеллект, одновременно и нанимают больше всех, — а увольнения на ИИ списывают как раз те, кто внедряет его меньше всего.
Forwarded from Алексей Гладков
This media is not supported in your browser
VIEW IN TELEGRAM
Китайские модели - ПМ с глушителем
😁10