Если говорить только про разработку, то типы задач такие:
Исследования. Пример из комментария выше «как другие люди в репозитории делают X», «лучшие техники ускорения», «найди самые прикольные поисковые фичи». Либо модели надо будет читать весь репозиторий
Глубокие зависимости. Читать все md по цепочке, чтобы найти ответ дорого. А поиск сразу вытащит нужный кусок знания, исходя из которого модель дальше может сама дочитать нужные подсказки
Сценарии, когда не все знания есть в вашем коде. Например, детали работы внешней апишки, которая на серверные ошибки отдаёт код 200. Писать же вообще всё в claude.md и раздувать его в рамерах не полезно ни с точки зрения экономии денег за токены, ни с точки зрения качества работы модели
Эти сценарии очень похожи, потому что их объединяет выход за предел узкого контекста кода конкретного проекта. Куда именно модели надо выйти, ей нужно подсказать. Для этого и был изобретен RAG. Выше Вы сами описали сценарии, в которых каждый из подходов рулит. Claude.md - хранитель локальных кодовых правил, а поиск по базе - инструмент для работы с широким контекстом
Положить в промпт вообще все знания можно не для всех задач - не хватит контекста По изначальной задумке в claude.md нужно записывать именно правила обращения с кодом и общую информацию про архитектуру. Читать LLM-кой ченджлог на каждый запрос расточительно. Такая информация нужна далеко не всегда. Поэтому да, на мой взгляд, в гибриде смысл есть и попробовать научить модельку делать поиск можно уже сейчас. Это не так сложно, а статья Вам в этом поможет
Точку, в которой у claude.md адекватного объёма начинается потеря информации, и точку, в которой файл становится неоправданно толстым, трудно выразить точным количеством строк исходного кода. Всё зависит от используемых моделей, сложности проекта, активности изменений и качества кода. Если вы за день делаете 100500 изменений, чуть ли не с нуля переписывая файл, то история быстро затрётся. А у меняющегося раз в год кода запаса побольше. Когда в самом коде понятные названия методов и переменных, используются корректные тайп хинты, а ещё есть уместные комментарии, дополнительных подсказок надо немного. Рассказать стилистические требования будет достаточно. Если весь код лежит в одном 200к-строчном файле с переменными "a,b1,c_3", то тут и подсказки не помогут
документации и тикетов таск-трекера почти нет, поиска над ними тоже
у Вас есть ресурсы абсолютно весь важный контекст положить в md-файлики рядом с кодом
Вопрос в том, нужен ли тут поисковик самых релевантных кусков интранета, если уже всё описано в Claude.md. Если так, то поисковик тут действительно не критичен (разве что поиск по регуляркам в коде)
Почему поиск по интранету критичен для Яндекса:
У нас уже есть огромный накопленный опыт, осевший в виде тикетов, пулл риквестов и вики-страничек. А Claude.md люди придумали относительно недавно. Поэтому первый пункт - поисковики и RAG-и актуалны для компаний с большим опытом. Claude.md небесполезны, но положить в них десятилетия разработки сложно и не всегда целесообразно
Поиск и RAG можно давать людям, а CLAUDE.md людям не так удобен. Нужно будет либо искать документацию по регуляркам, либо всё равно реализовывать поисковик над этими файлами. Людям свой код тоже полезно понимать :)
Claude.md не должен сильно забивать контекст, поэтому он должен быть компактным. Раз есть ограничения на размер, то по любому есть и потеря информации. Например, сценарии вида “в проде ошибка X, помоги”. Вряд ли в Claude.md будут перечислены все возможные варианты ошибок, в тч из всех зависимостей кода. Если я даю агенту конкретную задачу вида “поменяй в ручке X в походе в базу таймаут”, то Claude.md топ. Если я говорю “хочу ускорить свой поиск, посмотри как это делают другие, выбери лучшие доступные в монорепе технологии”, то без поиска тяжело
Поиск - универсальное решение для разных профессий. В Яндексе трудятся не только разработчики и поэтому не всем актуально работать именно с кодом. Есть также некодовые знания, актуальные всем профессиям, включая разработчиков. Например, HR-запросы вида “как пойти в отпуск”. Их, скорее всего, в коде не напишут
Если что, я не говорю, что файлы-подсказки для агентов в коде не стоит делать. Интуиция подсказывает, что, как всегда побеждает дружба. Для локальных кодовых задач Claude.md крут, но в работе с большими проектами с кучей сложных зависимостей, не во всех из которых есть Claude.md, поиск поможет лучше
На последней картинке 85% - это аудитория Внутреннего поиска (то есть поисковой строки), а 25% - аудитория нашего AI Chat (то есть генеративного ответа). По всей видимости, путаница из-за третьего пункта, на картинке не очень ясно 25% аудитории чего. Спасибо за комментарий!
Если говорить только про разработку, то типы задач такие:
Исследования. Пример из комментария выше «как другие люди в репозитории делают X», «лучшие техники ускорения», «найди самые прикольные поисковые фичи». Либо модели надо будет читать весь репозиторий
Глубокие зависимости. Читать все md по цепочке, чтобы найти ответ дорого. А поиск сразу вытащит нужный кусок знания, исходя из которого модель дальше может сама дочитать нужные подсказки
Сценарии, когда не все знания есть в вашем коде. Например, детали работы внешней апишки, которая на серверные ошибки отдаёт код 200. Писать же вообще всё в claude.md и раздувать его в рамерах не полезно ни с точки зрения экономии денег за токены, ни с точки зрения качества работы модели
Эти сценарии очень похожи, потому что их объединяет выход за предел узкого контекста кода конкретного проекта. Куда именно модели надо выйти, ей нужно подсказать. Для этого и был изобретен RAG. Выше Вы сами описали сценарии, в которых каждый из подходов рулит. Claude.md - хранитель локальных кодовых правил, а поиск по базе - инструмент для работы с широким контекстом
Положить в промпт вообще все знания можно не для всех задач - не хватит контекста
По изначальной задумке в claude.md нужно записывать именно правила обращения с кодом и общую информацию про архитектуру. Читать LLM-кой ченджлог на каждый запрос расточительно. Такая информация нужна далеко не всегда. Поэтому да, на мой взгляд, в гибриде смысл есть и попробовать научить модельку делать поиск можно уже сейчас. Это не так сложно, а статья Вам в этом поможет
Точку, в которой у claude.md адекватного объёма начинается потеря информации, и точку, в которой файл становится неоправданно толстым, трудно выразить точным количеством строк исходного кода. Всё зависит от используемых моделей, сложности проекта, активности изменений и качества кода. Если вы за день делаете 100500 изменений, чуть ли не с нуля переписывая файл, то история быстро затрётся. А у меняющегося раз в год кода запаса побольше. Когда в самом коде понятные названия методов и переменных, используются корректные тайп хинты, а ещё есть уместные комментарии, дополнительных подсказок надо немного. Рассказать стилистические требования будет достаточно. Если весь код лежит в одном 200к-строчном файле с переменными "a,b1,c_3", то тут и подсказки не помогут
Интересный опыт, спасибо, что поделились!
Насколько я понял вводные следующие:
рассматриваются только задачи кодовой генерации
документации и тикетов таск-трекера почти нет, поиска над ними тоже
у Вас есть ресурсы абсолютно весь важный контекст положить в md-файлики рядом с кодом
Вопрос в том, нужен ли тут поисковик самых релевантных кусков интранета, если уже всё описано в Claude.md. Если так, то поисковик тут действительно не критичен (разве что поиск по регуляркам в коде)
Почему поиск по интранету критичен для Яндекса:
У нас уже есть огромный накопленный опыт, осевший в виде тикетов, пулл риквестов и вики-страничек. А Claude.md люди придумали относительно недавно. Поэтому первый пункт - поисковики и RAG-и актуалны для компаний с большим опытом. Claude.md небесполезны, но положить в них десятилетия разработки сложно и не всегда целесообразно
Поиск и RAG можно давать людям, а CLAUDE.md людям не так удобен. Нужно будет либо искать документацию по регуляркам, либо всё равно реализовывать поисковик над этими файлами. Людям свой код тоже полезно понимать :)
Claude.md не должен сильно забивать контекст, поэтому он должен быть компактным. Раз есть ограничения на размер, то по любому есть и потеря информации. Например, сценарии вида “в проде ошибка X, помоги”. Вряд ли в Claude.md будут перечислены все возможные варианты ошибок, в тч из всех зависимостей кода. Если я даю агенту конкретную задачу вида “поменяй в ручке X в походе в базу таймаут”, то Claude.md топ. Если я говорю “хочу ускорить свой поиск, посмотри как это делают другие, выбери лучшие доступные в монорепе технологии”, то без поиска тяжело
Поиск - универсальное решение для разных профессий. В Яндексе трудятся не только разработчики и поэтому не всем актуально работать именно с кодом. Есть также некодовые знания, актуальные всем профессиям, включая разработчиков. Например, HR-запросы вида “как пойти в отпуск”. Их, скорее всего, в коде не напишут
Если что, я не говорю, что файлы-подсказки для агентов в коде не стоит делать. Интуиция подсказывает, что, как всегда побеждает дружба. Для локальных кодовых задач Claude.md крут, но в работе с большими проектами с кучей сложных зависимостей, не во всех из которых есть Claude.md, поиск поможет лучше
На последней картинке 85% - это аудитория Внутреннего поиска (то есть поисковой строки), а 25% - аудитория нашего AI Chat (то есть генеративного ответа). По всей видимости, путаница из-за третьего пункта, на картинке не очень ясно 25% аудитории чего. Спасибо за комментарий!