Mentat 코딩 보조 도구에 대한 심층 분석

Aider 코드 도우미와 함께 놀아본 후 며칠 동안 Mentat을 사용해 왔다. Aider와 비교 작동 방식은 비슷하다. 터미널에서 텍스트 UI로 실행된다. 심지어는 라이트와 다크 모드 색 구성표를 설정할 수 있다. 코딩 세션에서는 관련 파일을 추가하는 것이 포함된다. 채팅 상자에서 당신의 souhaits를 표현하고, 코드 변경을 포함하는 액션 플랜이 돌아온다. 승인하면 변경 사항이 적용된다. 전체적으로는 Aider와 비슷하지만 Aider는 모든 변경 사항에 대해 git-commit을 생성하는 반면 Mentat은 버전 관리를 당신에게 맡긴다. 소망의 질은 작업의 질을 결정한다. 꽤 많은verbosity를 사용해야 한다. 돌아오는 것은 당신이 선택한 LLM의 기능이다. 나는 코딩 도우미에게 지능을 부여하지 않겠지만, 그들에게는卓越한 개발 경험을 인정할 것이다. 어느 것을 사용하든지 간에, 당신은 여전히 무지한 인턴에게 말을 걸어야 한다. 문맥 제한 박스에서 Mentat은 지원하는 LLM 목록이 Aider보다 적다. 하지만 나는 이를 문제로 만들지 않았다. 나는 그것을 함께.ai에서 코딩 LLM에 연결시켰다. 하지만 그것은 중요하지 않았다. 나는 즉시 문맥 창 제한에 직면하게 되었다. 내가 포함시킨 파일이 생산 길이의 일부라는 점을 고려하면, 나는 실제로 어떤 영리한 일을 하기 전에 제한에 부딪혔다. 나는 이를 작동하게 만들기로 결정했고, 문맥 제한이 방해가 되고 있었다. 해결책은 단순히 문맥 제한이 더 큰 LLM을 사용하는 것이 아니다. 언제나 제한이 있을 것이고, 당신은 계속하여 그 제한에 부딪칠 것이다. 자체 RAG 구축 나는 RAG가 답이라고 들었다. 그래서 Mentat과 LLM 사이에 있는 미들웨어를 구축했다. 이 것은 OpenAI와 호환되는 REST API(http://localhost:<port>/chat/completions)로 로컬에서 실행되는 모든 것이 포함된 파이썬 파일 하나에 있다. 나는 이를 Broken Sword라고 부른다. Mentat의 관점에서 Broken Sword는 실제 LLM 서비스다. Broken Sword 내부에서 나는 Mentat의 요청을 포착하고, 입력을 가공하고, 마음에 드는 LLM에 보내고, OpenAI와 호환되는 방식으로 응답을 반환한다. 이렇게 하면 Mentat이 준다는 정교한 지시를 볼 수 있다. 즉, 프롬프트 엔지니어링이 어떤 것인지 알 수 있다. 이렇게 하면 Mentat이 지구상에서 사용할 수 있는 모든 LLM을 사용할 수 있게 된다. 나는 다음으로 Google Gemini 1.5를 사용하여 Broken Sword를 구동시켰다. 대부분은 품질과 비용의 적절한 균형 때문이었다. 하지만 이것은 문맥 창 제한을 해결하지 않는다. 이것은 그냥 파이프일 뿐이다. Mentat에서 받은 입력을 그대로 보내는 대신, 나는 대량의 문맥을 벡터 데이터베이스에 저장하고, LLM에 대한 입력으로 사용할 수 있는 임베딩으로 변환할 수 있다. 내가 이해한 바로는, LLM은 텍스트보다 작은 숫자 행렬로 구성된 벡터를 처리하는 것이 더 쉽다. 나는 LangChain을 사용하여 이를 구현했는데, LangChain은 이러한 프로세스를 추상화하고 있다. 또한 나는 LangChain을 사용하지 않아도 된다는 것을 알고 있지만, 나는 빠르게 해킹하고 싶었다. 나는 이러한 마술이 어떻게 작동하는지 아직 모르지만, 언젠가 알게 될 것이다. 작동 마지막으로 Mentat은 작동하게 되었다. 나는 Mentat에게 유닛 테스트를 작성하게 했고, 결과는 기존 것들과 일관성이 있었다. 나는 Mentat에게 GitHub Actions 워크플로우를 작성하게 했고, 결과는 합리적이었다. 이렇게 되면 매우 만족스러웠다. Broken Sword를 사용하여 Mentat을 작동하게 만들었다는 것을 알게 되면 더욱 만족스러웠다. 이제 나는 Mentat이 왜 RAG를 사용하지 않았는지 궁금해졌다. 나는 Mentat 코드베이스를 살펴보았고, 실제로 Chroma DB를 사용하고 있었다. 따라서 Mentat은 RAG를 사용하고 있지만, 그것이 나에게 중요하지 않았다. 하지만それは clunky Mentat을 더 많이 사용할수록, clunkiness가 나타난다. 때로는 LLM이 예상치 못한 응답을 주는 경우가 있고, 때로는 알 수 없는 이유로 충돌이 발생하는 경우가 있다. 우아한 실패는 그들의 강점이 아니다. Mentat이 요청을 처리하고 나서 충돌하는 경우가 있었다. 다시 시작하고 관련 파일을 추가한 후, 나는 같은 요청을 반복하고(대체로 좋은 채팅 기록이 있었습니다) 모든 것이 잘 작동했다. 수동 코딩 혼합 이번 모험에서 내가 답하고 싶은 질문은 이러한 코딩 도우미를 사용하여 문제를 해결할 때의 적절한 코딩 도우미와 직접 파일을 편집하는 혼합 비율이다. 가능한 경우라면 모든 코딩을 코딩 도우미에서만 수행해야 하는가? 아니면 코드 에디터를 옆에 준비해야 하는가? 나의 경우에는 Mentat이 반쪽을 차지하고, 다른 반쪽은 emacs를 차지하고 있다. 나는 Mentat이 대부분의 요구를 충족시킬 것으로 예상하고, emacs에서 같은 파일에 대한 소규모 조정을 수행할 것으로 예상했다. Mentat 스타일의 코딩 도우미가 미래를 가질 경우, 나는 이러한 방식이 적절할지 궁금해졌다.