Comments 23
:
Если бы текст начинался с:
"Я использую Ragex уже 6 месяцев. Вот три конкретных проблемы, которые он решил, и сколько времени я сэкономил"
...это была бы полезная статья.
Вместо этого — glorified portfolio project с оправданиями типа "параноики оценят" и "MCP-протокол, потому что AI-ассистенты — будущее".
Ну и статья написана LLM из обрывочных мыслей, говна и палок риторики и раздувания важности без конкретики.
Выглядит интересно. А планируется статья на elixirforum или чём-то подобном? Было бы интересно почитать мнения и, возможно, какие-то отзывы от потенциальной аудитории бетатестеров.
Как всегда, есть вопросы:
1. Аналоги - вы их искали/сравнивали или нет? (только не понимайте, пожалуйста, это как агрессию — один умный и крайне успешный человек из нашей общей Alma Mater упоминал, что часто правильно не делать "поиск по литературе", а пытаться решить задачу самому, а уже после решения искать. А второй момент — если вы нашли своё решение, то нельзя отчаиваться — большой вероятностью оно другое).
2. Как насчёт комментариев? В них часто дофига информации.
3. Обычно канонического AST нет, а есть разные Parsetree, в зависимости от ситуации. Это вы рассматривали? Или на данном этапе это слишком дотошно?
4. А сколько вы это херачили по времени?
Какая агрессия, вы чего? Вот уж кому-кому, а вам такие оговорки точно не требуются.
Искал. Не нашел. Похоже, идея доставать AST для RAG для MCP пришла (в мире опенсорса, по крайней мере) мне в голову первому.
Да, в планах есть. Для эликсира и эрланга они причем фактически рядом с AST в формализованных чанках лежат.
Расматривал. Я питон, например, поддерживаю — и в планах раст. У них нативного AST нет, но есть библиотеки, которые «строят» этот AST, и я вызываю их через шелл.
Да сложно сказать, я месяц потратил на пережевывание идеи, прикидывал варианты, то-сё; а сам код дней за пять написал.
1 — Тогда есть https://glean.software/ — это родственный проект, крайне не рекомендую пытаться развернуть у себя — потратите массу времени, т.к. это продукт кровавого хаскельного ынтерпрайза. Но документацию проглядеть, кмк, полезно. MCP к нему, кажется, уже прикручен коллегой месяц назад. Там к базе данных добавлен собственный велосипед аля типизированный Пролог для запросов. Как всегда, с косяками.
То есть, у вас система состоит из нескольких компонент: парсер (внешний), база данных, язык «запросов» поверх языка базы данных, внешний интерфейс.
2 — Круто.
--------------------------------------
Неповоротливость Glean'а отчасти обусловлена тем, что он сделан для Экстремистской Организации с её объёмами кода и клиент-серверной архитектурой. У вас, насколько я понимаю, проект как Git по сравнению с SVN.
Ух ты, спасибо. Завтра посмотрю. Меня не пугает хаскель, в принципе :)
парсер (внешний), база данных, язык «запросов» поверх языка базы данных, внешний интерфейс
Я думал изначально именно о такой архитектуре — и отмел её ровно потому, что это не то, что я хочу разворачивать у себя вместо LSP.
Я допишу генерацию escript + elixir archive, и моя балалайка будет разворачиваться в один клик.
Ещё есть тема для раздумий про эволюцию. Очевидно, что в том наборе, который вы сделали, это надо обсуждать, т.к. языки, особенно Питон, всё время меняются. Какие-то конструкции приходят, какие-то уходят...
Да и код меняется. Причём меняется быстрее. И в какой-то момент у нас может возникнуть ситуация, когда «исторический» код не разбирается современным парсером.
И ещё в какой-то момент может быть придётся мигрировать с парсера на парсер для того же Питона, скажем. Или держать 2 парсера.
Да, спасибо, над этим я пока не думал.
Подумал: не будет никаких проблем; я ничего не делаю с питоном сам, я делегирую (через erlang port, то есть, через шелл) — питоновской родной библиотеке, которая строит их AST. На машине разработчика ожидается тот питон, с которым он работает именно в этом проекте, так что если проект компилируется — я и AST получу без сучка и задоринки.
Для синтаксического разбора часто используют tree-sitter (например https://aider.chat/2023/10/22/repomap.html, https://ast-grep.github.io/), который поддерживает кучу языков. Но он больше оптимизирован на скорость, нежели полноту.
Более глубокий анализ можно выдрать из LSP (например https://github.com/axivo/mcp-lsp). Но здесь могут быть сложности с развертыванием и вопросы к перфомансу.
Из взрослого есть CodeQL от GitHub https://codeql.github.com. Он кроме AST поддерживает разные варианты графов: call graph, control flow graph, data flow graph, api graph. Из минусов сложные настройки и никакущая документация, которой много, но она ни чего не объясняет.
Про схожие проекты с tree-sitter’ом я знаю, конечно; вот самый перспективный, на мой взгляд: https://github.com/vitali87/code-graph-rag
За CodeQL спасибо, прошел мимо меня, гляну. А, так это гитхабовский query language, я его не опознал по названию. Он во-первых делает немного иное, а во-вторых (и в-главных) — у него ровно та же родовая травма, что у всех остальных: они с кодом, как с текстом работают (в лучшем случае — с внутренним представлением tree-sitter’а или LSP). А я — напрямую с нативным AST.
Более глубокий анализ можно выдрать из LSP
Вот это я не очень понял: а LSP его откуда возьмет?
В каком-то смысле Ragex уже сейчас может на 90% заменить LSP, причем сделает это лучше (например, он понимает сгенерированный макросами код by design, а LSP и tree-sitter — нет, и никогда не научатся).
Вот это я не очень понял: а LSP его откуда возьмет?
Под капотом конкретных реализаций LSP уже наворотили не только синтаксический анализ, но и поддержку различных библиотек, фреймворков, пакетеых менеджеров, систем сборки и т.п. специфики, которая не считывается с уровня лишь синтаксиса языка программирования.
CodeQL для компилируемых языков вообще по умолчанию пытается делать сборку проекта, чтобы получить еще больше данных.
Под капотом конкретных реализаций LSP уже наворотили не только синтаксический анализ, но и […]
Ну не надо со мной, как с ребенком-то разговаривать. Я не с нуля взялся такой проект делать, я как бы сначала в LSP нашего стека покоммитил, примерно представляю себе, как оно там внутри.
не считывается с уровня лишь синтаксиса языка программирования
Что именно не считывается с уровня синтаксиса языка программирования? Если можно, конкретный пример: вот LSP, вот кусок кода в нем, который пользуется ×××, потому что с уровня синтаксиса данную необходимую LSP информацию не получить.
CodeQL для компилируемых языков вообще по умолчанию пытается делать сборку проекта, чтобы получить еще больше данных.
Им это нужно, чтобы расширить семантическое поле на вопросы типа «какая библиотека у меня парсит json» — в RAG для MCP это бессмысленно.
Ну не надо со мной, как с ребенком-то разговаривать.
В каждом из нас живёт внутренний ребёнок, который умеет радоваться, огорчаться, а порой даже капризничать)
Что именно не считывается с уровня синтаксиса языка программирования?
Например, для построения графа зависимостей между модулями TypeScript требуется анализ файлов конфигурации компилятора где могут быть определены кастомные пути и алиасы https://www.typescriptlang.org/tsconfig/#paths. Такие конфиги можно раскидать по разным папкам. Это может использоваться и внутри одного проекта (разные конфиги для кода и тестов), и для разных в случае монорепозиториев. Не могу рассказать, как это реализовано у них в LSP, я тут больше юзер.
анализ файлов конфигурации компилятора где могут быть определены кастомные пути и алиасы
Ух. Спасибо. Хотя, признаться, я не понимаю, как это можно упаковать в RAG (LSP) — выставлен некий environment, в нем какие-то свои конфиги, пути и алиасы как-то разрешены уже — вот по ним RAG/LSP и должен шарашить, как иначе-то? Сразу писать код для трёх окружений? А переключать как?
Это был лишь один из примеров. Часто можно встретить проекты, где разные кусоки пишутся на разных языках. При этом они тесно связаны какими-то общими соглашениями. Это может быть специфичная структура директорий, соглашения по именованию, конфиги, аннотации, типы, API или даже все вместе. Код может лежать как в одном репозитории, так и в разных. Где-то зависимости прописаны строго (варианты .lock файлов), а где-то результат становится известен лишь после установки. Могут использоваться разные библиотеки или разные версии одной и той же библиотеки, порой несовместимые друг с другом.
Короче, код анализ в общем случае это сложная проблема, решение которой не сводится к одному лишь AST. У вас логичная идея - построить граф зависимостей. Но как добывать для него данные это креативная часть.
Исследование завершено! Я нашел несколько качественных альтернатив ragex, которые значительно превосходят его по всем критериям.
🏆 Лучшие альтернативы ragex
1. MindsDB (38,156 ⭐) - Enterprise решение
Полная экосистема с поддержкой 20+ баз данных
Встроенная RAG функциональность и векторные базы
Поддержка MCP, AI агентов, интеграция с LLM
Активная разработка, 6,079 форков
2. Qdrant MCP Server (1,149 ⭐) - Официальная векторная база
Векторная база данных с семантическим поиском
Поддержка гибридного поиска
Интеграция с Claude, Cursor, Windsurf
Apache 2.0 лицензия
3. Needle MCP (91 ⭐) - Специализированный RAG
Долгосрочная память для LLMs
Семантический поиск
MIT лицензия
4. MCP Local RAG (95 ⭐) - Локальное решение
Полностью локальная работа без API
Веб-поиск с RAG-подобной сортировкой
MIT лицензия
5. PageIndex MCP (86 ⭐) - Инновационный подход
Векторless reasoning-based RAG
Многошаговый поиск и tree search
📊 Сравнение с ragex
Критерий ragex Лучшие альтернативы Звезды 2 91-38,156 Форки 0 19-6,079 Активность Низкая Высокая Документация Минимальная Полная Тестирование Нет Активное
🎯 Рекомендации
Для продакшн: MindsDB или Qdrant MCP Server
Для локальной разработки: MCP Local RAG или Needle MCP
Для инноваций:PageIndex MCP
Вывод: Все найденные альтернативы значительно превосходят ragex по функциональности, активности разработки, документации и сообществу.
Вы идиот?
Нет, это Вы плохо искали...
Чел просто в "ленивого начальника" решил поиграть : ) Представьте, инженер приносит начальнику сложный проект/решение, тот ни в дуб ногой, но надо показать компетентность, он скармливает текст ЛЛМ и такой: "Чатгпт сказал, что всё фигня переделывай есть альтернативы лучше, а у твоего решения есть минусы! Объяснись!". Да, такие есть. Да, многие инженеры так и работают. В качестве страшилки на ночь можете представить, что в вашу компанию такой пришёл.
Можете пояснить для людей, знающих про лексический и синтаксический анализ, но не разбирающихся в ЛЛМ, почему оно будет лучше работать с AST, чем с исходником?
Да я в курсе, просто у меня аж челюсть отвисла: так позориться на публике — и захочешь — не сразу получится.
почему оно будет лучше работать с AST, чем с исходником
Это пока проверяемая гипотеза, а не факт. Подтолкнуло меня к таким мыслям вот что:
Когда Г для корпоратов «расширил» контекстное окно до 1М токенов, эмпирически выяснилось, что они просто перестали выбрасывать ошибку, но на самом деле хвост (примерно 800К) ни на что видимо не влиял;
Отсюда напрашивается и так, вроде, очевидный вывод, что бесконечное наращивание мощностей и расширение контекстных окон — путь в никуда, потому что мало эти токены принять, с ними надо что-то делать еще потом (выучить наизусть частушку значительно проще, чем Онегина);
Я подумал: хорошо бы научиться максимально сжимать контекстное окно при помощи RAG, чтобы токенов было как можно меньше, но информация почти при этом не терялась, чтобы не выплеснуть с водой и ребенка;
Текст, как знает любой человек, пробовавший со скуки писать свой архиватор, — сущность крайне неэффективная с точки зрения соотношения размер / смысл.
А что у нас самое эффективное с точки зрения «сохранить 100% важной информации в максимально сжатом виде»? — Ну и вот.
Повторяю: это гипотеза пока, но меня результаты уже сейчас прям радуют, я в хвост и гриву использую Ragex вместо LSP для дальнейшей разработки Ragex, и прям доволен (хотя, как в любом прототипе, пока приходится молоток и напильник из рук не выпускать).
Ragex: Гибридный RAG для анализа кода