Comments 8
а разве mcp IDE не закрывает вопрос поиска с контекстом?
эту хрень все равно надо запустить для первоначального индексирования, а потом постоянно обновлять (у них там есть авто-режим но я уже вижу как оно будет зависать при гит-переключениях между ветками кода где расхождения существенные)
даже кодовые агенты имеют "кеш" из-за чего они иногда не видят того что было изменено буквально минуту назад, а тут целая векторная база которая должна в фоне все переиндексировать
сомнительно вообщем, собсвенно сомнительно для больших проектов и домашнего использования когда у тебя на ПК отнюдь не один проект (то есть векторная база сразу по всему диску не есть хорошо, сомневаюсь что они отдельно векторы под каждую папку держат)
Технически ничего не мешает семантичесеому индексу иметь наборы фильтров по worktree, коммитам и папкам. Это нетривиально сделать в плане того чтобы определять что когда перестраивать и как не начать хранить слишком много, но в целом реально.
MCP IDE это LSP или что-то другое? LSP в общем задачу нечёткого поиска не решает.
Нет, буквально IDE MCP, который высовывает наружу свои возможности, включая поиск, например: https://www.jetbrains.com/help/idea/mcp-server.html#formatting-toolset
У меня есть большие сомнения, что "Use this tool for semantic lookup by identifier fragments" реализует семантический поиск в том же смысле, в котором его реализует инструмент, упомянутый в статье. В целом разница между таким инструментом и grep/semgrep только в том, что оно отфильтровывает файлы, которые включены в проект. Это полезно, но не позволяет агенту спросить "как реализован рейтлимитер", а найти файл с названием "sliding_window.cpp", где слов "rate" и "limiter" нет.
Я если что не использовал инструмент, который описывается в статье, но разницу между векторным поиском и поиском по LSP + fuzzy matching (а search_symbol это скорее всего он) представляю хорошо, они совсем разные.
Отметил для себя, чтобы попробовать. Интересная идея реализация. Потенциально хорош для определённых задач.
Велосипед и мусора.
В гите заявляют об экономии 70% токенов, но я нигде не нашел ни методики тестирования, ни собственно тестов, ни способов проверки.
Хотя нет ничего проще, чем взять свой инструмент, конкретных агентов, и протестировать хотя бы на своем-же репозитории - сделать набор симметричных тестов на конкретном комите (повторяемость и проч.).
Раз этого нет, значит, скорее всего они сами ничего не тестируют, разработка идёт наугад, и любой другой инструмент, который свою эффективность проверяет скорее всего будет работать лучше.
Почему AI-агент ищет по коду неправильно, и как это чинит cocoindex-code за две команды