Comments 10
Как же не хватает какого-то внятного доказательства полезности! Читать то очень интересно, правда!
Пожалуйста, возьмите 20–50 настоящих старых issue этого самого монолита и прогоните вслепую Claude Code против Claude Code + TeaRAGs: solved/not solved, время, токены, число tool calls. Тогда из очень интересной инженерной статьи получится доказательство, что система действительно работает.
Я просто возмущен отсутствием комментариев на статье! Даже зарегался ради такого дела. Кладезь, коллега! Утащил себе в закрома, буду пробовать, тестировать и применять у себя
Привет! Отличная статья, накидаю несколько вопросов:
"Взяли 13 моделей с заявленными 128K+ токенов — и уже на 32K одиннадцать из них упали ниже половины собственного качества на коротком контексте"
а можно плиз ссылку на ресерч? Те агент начинает тупить уже на таком маленьком (32к это сколько - пара файлов?) контексте?
если есть можно плиз приложить ссылки на ресерчи где использовали современные модели, ну те сравнение с gpt 4.o выглядит сильно устаревшим
еще интересно было бы сравнить как с другими агентами (кроме клода) обстоит дело, например в курсоре есть своя рага - какую часть проблемы она закрывает?
"Anthropic индекс действительно не строят, и их резоны понятны: эмбеддинги на миллионы чужих кодовых баз, их свежесть и хостинг чужого кода на масштабе флота." - вот тут тоже не понял, курсор же строит. Но опять таки, я не оценивал объем и выгоду от rag в cursor.
а можно плиз ссылку на ресерч?
Те агент начинает тупить уже на таком маленьком (32к это сколько - пара файлов?) контексте?
Да, вы правильно заметили, это утверждение актуально только для устаревших моделей, но отлично демонстрирует принцип деградации контекста, наряду с Context Rot, которые сохраняются и на актуальных версиях моделей
если есть можно плиз приложить ссылки на ресерчи где использовали современные модели, ну те сравнение с gpt 4.o выглядит сильно устаревшим
Такие исследования действительно есть, например:
Retrieval and Multi-Hop Reasoning in 1M-Token Context Windows: Evaluating LLMs on Classical Chinese Text – это показывает, что классическая "Lost In The Middle" практически полностью решена для Single retrieval (извлечение одного факта) на 1М контексте, но для Multi Hop (извлечение нескольких связанных фактов), достаточно сильная деградация начинается при переходе от 512К к 1М
еще интересно было бы сравнить как с другими агентами (кроме клода) обстоит дело, например в курсоре есть своя рага - какую часть проблемы она закрывает?
Наверное, под словом "рага" стоит понимать "слой семантический поиска", чтобы не было путаницы с древним подходом "naive RAG". Сам по себе семантический поиск закрывает "расход инпут токенов", поиск по неточным символам и, частично, проблему с дивергенцией кода, от какой-то конкретной платформы это не должно зависеть
"Anthropic индекс действительно не строят, и их резоны понятны: эмбеддинги на миллионы чужих кодовых баз, их свежесть и хостинг чужого кода на масштабе флота." - вот тут тоже не понял, курсор же строит. Но опять таки, я не оценивал объем и выгоду от rag в cursor.
Хороший вопрос. По моему скромному мнению, стоит чётко разделять Antrophic/Open AI от Cursor/JetBrains. Если первые позиционируют себя на рынке как "исследователи в области ИИ" и, literally, торгуют токенами, то вторые уже относятся к категории "инструменты для разработчиков"
Мое предположение заключается в том, что для первых:
а) Огромные энтерпрайз проекты это не ЦА продукта, например, почти ~80% проектов на GH живут в диапазоне до 500К строк (по версии SonarCloud), с чем неплохо справляются дефолтные агентские инструменты вроде грепа
б) Экономия от кодового индекса на таких проектах будет заключаться даже не в скорости поиска, а в снижении количества input tokens, но зачем продавцу сахара тратить деньги на борьбу с ожирением и уменьшать количество сахара в своих же пирожных (тратить колосальные деньги на поддержание инфраструктуры, отладку и разработку), если можно чаще выпускать пирожные подороже?
В свою очередь, для вторых:
а) Нужно конкурировать с первыми
б) Есть чёткая ЦА – профессиональные разработчики, которых нужно удержать любой ценой на "медленно умирающем" рынке IDE. Я думаю, что семантический поиск в этом случае – "high retention killer feature"
А подключением стандартных LSP для Ruby к агенту не решает проблему? Или это плохо работает именно из-за специфики Ruby с его динамической типизацией?
Я пробовал использовать Ruby LSP для того, чтобы реализовать частичное чтение файлов через find_symbol указатель, и столкнулся с некоторыми проблемами:
Не все символы можно получить
Один запрос на поиск символа отрабатывал 60+ секунд
Сам индекс постоянно строится с ошибками и часто не доступен, по крайней мере на нашем монолите
Тоже самое касается, встроенных в Ruby LSP,
get_callers/get_calles
Чисто теоретически, предположим, что появился некий LSP, который работает хорошо, быстро и качество (не важно какой язык рассматриваем). Проблема с навигацией частично решается, агент может изучить соседей и читать файлы частично через указатели строк, но все еще не может: понять, что перед ним хаб; увидеть Transitive Impact метода/класса (количество методов/классов от которых зависит просматриваемый метод), увидеть pageRank (критичность рассматриваемой функции), а также понять, hub перед ним или leaf
Т.е. то, что Ruby LSP "не тянет" энтерпрайз монолит, это верхушка айсберга: LSP проектировались не под Coding Agents, а под IDE, поэтому они решают совсем другой класс задач :)
Тема на самом деле довольно занимательная. Из инструментальной базы почему то сразу вспомнился MCP Serena. И соглашусь, что хочется увидеть как покажет комплекс решений в бою. Кажется что максимум пользы будет видно на каких нибуть ~14-30b локальных моделей, которые без хороших мср инструментов на таких монолитах как без рук.
Отличный поинт! Я тоже думал в эту сторону, но пока что ограничился исследованиями на тему того, что у локальных моделей слишком слабый ризонинг. У меня и топовые клод модели часто тупят при работе с монолитом, а тут предлагаете на печке с дровами модели запускать 😅 хотя, без сомнения, MCP-кодовые индексы заметно улучшают качество генерации (судя по ресерчам, которые видел)
Насчёт Serena, если меня не подводит память, она работает поверх LSP и последний раз, когда я пробовал её запустить, она так и не смогла проиндексировать мой монолит, когда я последний раз её запускал - кажется, что ЦА у таких проектов не та …
Codebase Intelligence для агента: строим «dev tool будущего» и сразу тестируем на Rails монолите в 3,5M+ строк