Вслед за игрой с помощником кодирования Aider, последние несколько недель я использую Mentat для кодирования.
Сравнение с Aider
Принцип работы похож. Он работает в терминале с текстовым пользовательским интерфейсом. В нем даже можно настроить цветовую схему для светлого и темного режимов. Сессии кодирования включают в себя добавление соответствующих файлов для контекста. В чате вы высказываете свои пожелания, и в ответ приходит план действий с изменениями кода. Одобрите их, и изменения будут внесены.
В целом опыт близок к Aider, за исключением того, что Aider делает git-коммит для каждого изменения (от которого вы можете отказаться). Mentat оставляет управление версиями на ваше усмотрение.
От того, как вы сформулируете свои пожелания, зависит качество работы. Вы должны быть довольно многословны. То, что вы получите в ответ, зависит от вашего выбора LLM. Я не стану приписывать умные способности помощникам по кодингу, но я бы приписал им более высокий опыт разработки, если таковой имеется. Независимо от того, какой из них вы используете, вам все равно придется разговаривать с ними как с несведущими стажерами.
Контекстное ограничение
Из коробки Mentat поддерживает скудный список LLM по сравнению с Aider (это может измениться, а может и нет). Я не стал рассматривать это как проблему, а подключил его к использованию LLM для кодирования в Together.ai.
Но это не имело значения; я сразу же столкнулся с ограничением контекстного окна. Конечно, некоторые из моих файлов имеют производственную длину, но я включил не так много из них. У меня даже не было возможности заставить его сделать что-то умное. Я был полон решимости заставить это работать, но только контекстное ограничение мешает.
Решение не в том, чтобы просто использовать LLM с большим ограничением контекста. Всегда есть верхний предел, и в итоге вы просто будете постоянно его сбивать.
Построил свой собственный RAG
Я слышал, что RAG - это выход. Поэтому я создал промежуточное ПО, которое находится между Mentat и LLM.
Это OpenAI-совместимый REST API (http://localhost:<port>/chat/completions), работающий локально, и все это размещено в одном Python-файле. Для удобства я называю его Broken Sword.
С точки зрения Mentat, Broken Sword - это настоящий LLM-сервис. Внутри Broken Sword я перехватываю запросы Mentat, обрабатываю входные данные, отправляю на любой LLM, который мне нужен, и возвращаю ответ совместимым с OpenAI способом. При этом я вижу сложные директивы, которые дает Mentat, то есть то, что выглядит как подсказка-инжиниринг.
Просто сделав это, я позволил Mentat использовать любой доступный человечеству LLM. Я использую Google Gemini 1.5 для питания Broken Sword, в основном потому, что он обладает правильным балансом качества и стоимости.
Однако это само по себе не решает проблему контекстного окна. Это не более чем прославленная труба.
Вместо того чтобы передавать входные данные из Mentat дословно, огромное количество контекста можно хранить в векторной базе данных и передавать в виде вкраплений. Если я правильно понимаю, большие куски текстов превращаются в многомерные матрицы чисел. Для LLM это гораздо меньше, чем оригинальные тексты.
Я сделал все это с помощью LangChain (в нем абстрагирована последовательность процессов), с добавлением Flask для простого API. Это было похоже на жульничество, когда я еще не знаю, как работает эта магия, но я хотел взломать все быстро. Я знаю, они говорят, что LangChain не нужен, и я им верю, но когда-нибудь, чувак, когда-нибудь.
Это работает
Когда я закончил, оказалось, что Mentat работает так, как и должен работать. Я заставил его писать юнит-тесты, и они были написаны в стиле, соответствующем существующим. Я заставил его написать рабочий процесс GitHub Actions, и результат оказался разумным.
Это было приятно, когда все работало. Знать, что я заставил его работать с Broken Sword, вдвойне приятно.
В связи с этим мне стало интересно, почему Mentat не использует RAG или векторную базу данных, как я только что сделал? Это казалось почти тривиальным. Я заглянул в кодовую базу Mentat, действительно, там используется Chroma DB (та же самая векторная база данных, которую использую я). Так что, может быть, они как-то и делают RAG, но не так, чтобы это имело для меня значение.
Но он неуклюжий
По мере того как я все больше и больше использовал Mentat в работе, его неуклюжесть стала очевидной. Время от времени он давал сбои. Иногда потому, что LLM не вернулась с чем-то, что ей понравилось, но чаще всего по неизвестной мне причине. Грациозный отказ не является его сильной стороной.
Бывало, что Mentat падал после того, как я делал запрос. После перезапуска и повторного включения соответствующих файлов я повторял тот же запрос (хорошо, что у них есть история чата, чтобы облегчить эту задачу), и все работало.
Смесь ручного кодирования
Один из вопросов, на который я надеялся ответить в этом приключении, - правильное сочетание использования помощника по кодированию и непосредственного редактирования файлов при решении одной задачи. То есть, если это возможно, то все кодирование должно осуществляться только с помощью помощника по кодированию? Или мы должны иметь готовый редактор кода на следующем экране?
В моем случае половина экрана отведена под Mentat, другая половина - под emacs. Я ожидал, что Mentat предоставит мне почти все, что я хочу, но не идеально, и я буду вносить небольшие коррективы вручную в те же файлы в emacs.
Если у помощника по кодированию в стиле Mentat есть будущее, интересно, так ли это должно быть.
dev.to
Deep dive into Mentat coding assistant
Create attached notes ...