그냥 LLM이 코드베이스 전체를 이해해주면 안 될까: 번들링을 통한 RAG 시도
(gist.github.com/atjsh)"이 글에서는 많은 파일을 내포하는 TypeScript 코드베이스를 번들링(bundling)을 통해 1개의 JavaScript 파일로 압축한 후 LLM에게 전달하였을 때, LLM이 코드베이스와 관련된 질문에 얼마나 정확하게 답변할 수 있는지 확인할 것이다."
- NestJS 기반 웹 서버 코드베이스 1개 준비
- esbuild로 코드 압축(번들링)
- 압축된 코드는 prompt에 끼워넣어짐
- ChatGPT o3-mini에 프롬프트 전달
- 코드베이스와 관련된 질문에 얼마나 정확하게 대답하는지 확인
- Swagger 생성 테스트: 대부분의 시도에서 21개 엔드포인트 중 19개 이상의 엔드포인트를 정확하게 문서화하는 데 성공
- API 엔드포인트에 대한 설명 요청 테스트: 비개발자/개발자용 매뉴얼을 성공적으로 생성
- 한계점이 존재
- 결론
"LLM에 대해 코드베이스 전체를 RAG하기 위해, 코드베이스 전체를 한 파일로 압축하여 LLM에게 전달하는 테스트를 설계했다.
현존하는 번들링 툴을 그대로 사용하여 코드베이스를 압축하였을 때, LLM은 코드베이스 전체에 대한 API 문서화를 진행하거나, 특정 API에 대한 자세한 매뉴얼을 작성할 수 있었다.
코드베이스 압축을 진행하며 발생하는 정보 손실에 대해서는 원본 파일에 대한 추가적인 Semantic search를 통해 보완할 수 있을 것으로 전망한다."
번들링한 파일을 프롬프트에 넣거나 어플리케이션에 첨부해서 LLM에 쿼리하는 것이 RAG라고 할 수 있나요? 어느 부분이 Retrival에 해당하는지 궁금합니다
흥미롭네요. minify된 js로도 어느정도 잘 인지하는군요. https://news.hada.io/topic?id=19552 나 https://news.hada.io/topic?id=19540 에서 소개된 도구 등을 활용해 디렉토리 구조를 추가 맥락으로 제공해줘도 좋겠다 싶네요.
요즘 llm이랑 코딩을 워낙 많이 하다보니 항상 효율적인 정보 전달이 고민인데, 흥미로운 실험 감사합니다.
해외에서 codebase syntax를 graph로 추출해서 쿼리했던 시도도 있었는데,
번들링이 좀 더 일반적으로 적용하기 쉬운 방법일 것 같네요. (언어가 번들링을 지원한다면)
https://x.com/daniel_mac8/status/1908332949251948808
근데 요즘 gemini 성능이 너무 좋아서 o3랑 비교해보시면 더욱 흥미로울 것 같아요.