대규모 언어 모델을 사용하여 유전적 개선 돌연변이 강화

콘텐츠 개요

• 추상적인
• 소개
• 실험 설정
• 결과
• 결론 및 향후 연구
• 참고자료

추상적인

LLM(대형 언어 모델)은 프로그램 복구를 포함한 소프트웨어 엔지니어링 작업에 성공적으로 적용되었습니다. 그러나 유전적 개선(GI)과 같은 검색 기반 기술에 대한 적용은 아직 대부분 탐구되지 않았습니다. 본 논문에서는 검색 프로세스를 개선하기 위해 GI의 돌연변이 연산자로 LLM을 사용하는 방법을 평가합니다. OpenAI의 API를 호출하여 JCodec 도구에 대한 편집 내용을 생성하도록 Gin Java GI 도구 키트를 확장합니다. 5가지 다른 편집 유형을 사용하여 편집 공간을 무작위로 샘플링합니다. 표준 삽입 편집보다 LLM 기반 편집에서 단위 테스트를 통과하는 패치 수가 최대 75% 더 높은 것으로 나타났습니다. 또한 LLM에서 발견된 패치는 일반적으로 표준 편집에 비해 다양성이 떨어집니다. 런타임 개선 사항을 찾기 위해 로컬 검색으로 GI를 실행했습니다. LLM 강화 GI에서는 많은 개선 패치가 발견되었지만 가장 개선된 패치는 표준 GI에서 발견되었습니다.

소개

소프트웨어 시스템이 점점 더 커지고 복잡해짐에 따라 이를 유지 관리하려면 상당한 수동 노력이 필요합니다[2]. 소프트웨어 유지 관리 및 최적화 작업에 대한 개발자의 노력을 줄이려면 자동화된 패러다임이 필수적입니다. Genetic Improvement(GI)[15]는 검색 기반 기술을 적용하여 실행 시간과 같은 기존 소프트웨어의 비기능적 속성은 물론 버그 복구와 같은 기능적 속성을 개선합니다. GI는 업계에서 성공을 거두었지만[12,13], 검색에 사용하는 돌연변이 연산자 세트에 의해 여전히 제한적입니다[14].

LLM(대형 언어 모델)은 현재 특정 작업에 대한 추가 교육 없이 텍스트 쿼리를 처리할 수 있으므로 광범위한 응용 프로그램을 보유합니다. LLM은 다양한 프로그래밍 언어에 걸쳐 수백만 개의 코드 저장소에 대해 사전 교육을 받았습니다[5]. 소프트웨어 엔지니어링 작업에 대한 사용은 큰 성공을 거두었으며[9,6], 프로그램 복구[17,19]에도 가능성을 보여주었습니다.

Kang과 Yu[10]는 GI를 향상시키기 위해 LLM을 사용하는 데 아직 활용되지 않은 잠재력이 있다고 제안했습니다. GI는 다양한 최적화 작업에 동일한 돌연변이 연산자를 사용합니다. 이러한 연산자는 검색을 시작하기 전에 직접 제작되므로 검색 공간이 제한됩니다. 우리는 추가 돌연변이 연산자로서 LLM 패치 제안을 강화하면 검색 공간이 풍부해지고 더 성공적인 변형이 생성될 것이라고 가정합니다.

본 논문에서는 LLM을 GI의 돌연변이 연산자로 사용하면 검색의 효율성과 효능을 향상시킬 수 있는지 여부를 알아보기 위해 여러 실험을 수행합니다. 우리의 결과는 LLM 생성 패치의 컴파일 비율이 무작위 검색과 로컬 검색에 대해 각각 51.32%와 53.54%임을 보여줍니다(중간 프롬프트 범주 사용). 이전에는 LLM(LLM 모델을 있는 그대로 사용)이 대략 40%의 시간 동안 컴파일되는 코드를 생성하는 것으로 나타났습니다[16,18]. 무작위로 샘플링된 LLM 기반 편집은 표준 GI 편집에 비해 더 자주 컴파일되고 단위 테스트를 통과한 것으로 나타났습니다. 단위 테스트를 통과하는 패치 수가 GI 삽입 편집보다 LLM 기반 편집에서 최대 75% 더 높다는 것을 확인했습니다. 그러나 LLM에서 발견된 패치는 다양성이 떨어지는 것으로 나타났습니다. 로컬 검색의 경우 표준 GI 문 편집과 LLM 기반 편집을 사용하여 최상의 개선을 이룰 수 있습니다. 이러한 발견은 돌연변이 운영자로서 LLM의 잠재력을 보여주고 이 분야에 대한 추가 연구의 필요성을 강조합니다.

실험 설정

GI에서 돌연변이 연산자로 LLM의 사용을 분석하기 위해 OpenAI의 GPT 3.5 Turbo 모델과 GI 도구 상자 Gin [3]을 사용했습니다. 우리는 Gin 내에서 구현된 두 가지 유형의 검색, 즉 무작위 검색과 로컬 검색을 실험했습니다. OpenAI API를 사용하는 LLM에 대한 요청은 온도 0.7의 Langchain4J 라이브러리를 통해 이루어졌습니다. 실험에서 개선 대상 프로젝트는 Java로 작성된 인기 있는 JCodec [7] 프로젝트였습니다. 편집 대상이 되는 '핫' 방법은 Gin의 프로파일러 도구를 사용하여 프로파일링을 20회 반복하고 결과 세트의 합집합을 취함으로써 식별되었습니다.

무작위 샘플링 실험의 경우 명령문 수준 편집([14]에서 복사/삭제/교체/교체 및 [4]에서 중단/계속/반환 삽입) 및 LLM 편집으로 실행을 설정하여 각 유형을 무작위로 1000개 생성합니다. . 편집으로 인해 발생하는 무한 루프를 포착하기 위해 각 단위 테스트에 10000밀리초의 시간 초과가 사용되었습니다. 시간 초과를 초과하면 테스트 실패로 간주됩니다. 지역 검색의 경우 실험도 유사하게 설정되었습니다. 10번의 반복 실행(상위 10개 핫 메서드 각각에 대해 하나씩)이 있었지만 실행은 100번의 평가로 제한되어 총 1000번의 평가가 발생하여 무작위 검색과 일치했습니다. 실제로 패치되지 않은 원본 코드의 시간을 측정하는 데 첫 번째 편집이 사용되었기 때문에 실행당 99번의 편집이 이루어졌습니다.

우리는 두 검색 유형 모두에 대해 LLM에 요청을 보내기 위해 세 가지 다른 프롬프트(간단한 프롬프트, 중간 프롬프트, 세부 프롬프트)를 실험했습니다. 세 가지 프롬프트를 모두 사용하여 우리 구현에서는 현재 코드의 다섯 가지 변형을 요청합니다. 단순 프롬프트에서는 추가 정보 없이 코드만 요청합니다. 중간 프롬프트는 그림 1과 같이 제공된 코드와 요구 사항에 대한 자세한 정보를 제공합니다. 특히 LLM에 사용된 프로그래밍 언어, 코드가 속한 프로젝트 및 형식 지정 지침을 제공합니다. 자세한 프롬프트는 유용한 변경 사항의 예를 포함하여 중간 프롬프트를 확장합니다. 이 예는 Brownlee et al.이 얻은 결과에서 가져온 것입니다. [4]. 패치는 jCodec 프로젝트에 적용된 삽입 편집의 성공적인 인스턴스입니다(즉, 컴파일하고 단위 테스트를 통과했으며 원래 코드에 비해 속도 향상을 제공한 편집). 실험에 사용된 모든 세부 프롬프트 요청에 대해 동일한 예를 사용합니다. 이는 LLM이 사용자가 특정 정보를 제시하는 귀납적 추론이 가능하고 LLM이 해당 입력을 사용하여 보다 일반적인 진술을 생성할 수 있기 때문이며 GPT-4[8]에서 더욱 개선되었습니다.

LLM 편집은 대상 '핫' 방법에서 블록 문을 무작위로 선택하여 적용됩니다. 이 블록의 내용은 in the prompt. The first code block in the LLM response is identified. Gin uses JavaParser (https://javaparser.org) internally to represent target source files, so we attempt to parse the LLM suggestion with JavaParser, and replace the original block with the LLM suggestion.

결과

첫 번째 실험에서는 표준 GI 변형, 즉 삽입 및 명령문 편집을 무작위 샘플링을 사용하여 서로 다른 세부 프롬프트(단순, 중간 및 세부)를 사용하는 LLM 편집과 비교합니다. 표 1은 모든 패치에 대한 결과는 물론 고유 패치에 대한 결과도 보여줍니다. JavaParser가 성공적으로 구문 분석한 패치 수(Valid로 명명), 컴파일된 패치 수, 모든 단위 테스트를 통과한 패치 수(Passed로 명명)를 보고합니다. 원본 소프트웨어와 구문적으로 동일한 패치는 제외했습니다. 최상의 결과는 굵은 글씨 로 표시되어 있습니다.

표준 삽입 및 명령문 편집을 통해 훨씬 더 유효한 패치가 발견되었지만 LLM 생성 편집을 사용하면 더 많은 통과 패치를 찾을 수 있음을 알 수 있습니다. 특히 중간 및 세부 프롬프트의 경우 292 및 230 패치가 각각 단위 테스트를 통과했습니다. 삽입 및 명령문 편집의 경우 각각 166개와 91개만 단위 테스트를 통과했습니다. 일화로, 패치 통과율이 가장 낮거나 높은 핫 방법은 운영자마다 달랐습니다. 이러한 변형을 이해하는 것은 향후 조사에서 흥미로울 것입니다.

또한 LLM 패치의 다양성이 낮다는 점도 주목할 만합니다. Medium을 사용하는 LLM보다 표준 돌연변이 운영자가 50% 이상 더 많은 고유한 패치를 찾았습니다.

그리고 상세한 프롬프트. 그러나 단순 프롬프트에서는 제안된 편집 내용을 구문 분석할 수 없는 경우가 많았기 때문에 단일 패치가 단위 테스트를 통과하지 못했습니다. 따라서 LLM이 사용 가능한 출력을 생성하도록 하려면 자세한 프롬프트가 필요합니다.

우리는 Medium이 더 많은 수의 컴파일되고 통과된 패치를 갖고 있기 때문에 Detail(고유 패치 세트에서)을 사용한 성능 저하를 이해하기 위해 Medium과 Detail 프롬프트 사이의 차이점을 추가로 조사했습니다. 두 프롬프트 수준 모두에서 생성된 응답은 42개 사례(총 고유 유효 사례 중)에 대해 동일했습니다. 그러나 상세(Detailed)는 평균 363자로 더 긴 응답을 생성하는 경향이 있었지만 중간(Medium)은 평균 304자로 응답했습니다. 우리는 여러 가지 자세한 프롬프트 응답을 수동으로 조사했으며, 여기에서 다른 파일의 변수를 포함하는 일부를 식별하여 잠재적으로 GI가 탐색할 수 있는 코드 변형 세트를 크게 확장할 수 있었습니다.

두 번째 실험에서는 표준 및 LLM 편집의 성능을 지역 검색과 비교하여 분석을 확장합니다. 표 2는 지역 검색 실험 결과를 보여줍니다. 우리는 패치 컴파일 및 전달 수와 런타임 개선 사항이 발견된 패치 수를 보고합니다. 또한 우리는 밀리초(ms) 단위로 중앙값 및 최고 개선 사항을 보고합니다. 표에서는 빈 패치를 모두 제외했습니다. 이전과 마찬가지로 최상의 결과는 굵은 글씨 로 표시됩니다.

다시 한 번, 중간 및 세부 프롬프트를 사용하여 LLM에서 단위 테스트를 통과한 더 많은 패치를 찾을 수 있음을 알 수 있습니다. 또한 이러한 프롬프트와 함께 LLM을 사용하면 더 많은 개선 사항을 찾을 수 있습니다. 구체적으로 중간 및 세부 항목에서는 각각 164개 및 196개의 개선 사항을 발견한 반면, 삽입에서는 136개, 명령문에서는 71개만 발견했습니다. 가장 좋은 개선점은 명령문 편집을 통해 508ms에서 찾을 수 있습니다. LLM(중간 프롬프트 사용)을 사용하여 발견된 최고의 개선 사항은 런타임을 395ms만 개선할 수 있다는 것입니다. 또한 세부 프롬프트 응답의 낮은 컴파일 속도로 인해 중간 프롬프트와 세부 프롬프트 간의 차이에 대한 통찰력을 얻기 위해 지역 검색 결과의 일련의 편집 내용을 조사했습니다. 이 예에서는 함수 클립에 대한 호출을 인라인하기 위한 일련의 편집이 이루어졌습니다. 세부 프롬프트는 몇 가지 편집 내에서 거의 즉시 호출을 통합하려고 시도했으며 이로 인해 잘못된 코드가 발생할 수 있습니다. 반면, Medium 프롬프트는 덜 급진적인 변경을 하여 점차적으로 코드를 개선했습니다. 결국은 클립 함수 호출을 인라인하려고 시도하기 전에 삼항 연산자 표현식을 if-then-else 문과 시스템 함수 호출로 바꾸는 것으로 시작되었습니다.

결론 및 향후 연구

소프트웨어의 유전적 개선은 검색 프로세스에서 활용하는 돌연변이 연산자에 크게 의존합니다. 연산자를 다양화하고 검색 공간을 더욱 풍부하게 하기 위해 LLM(대형 언어 모델)을 연산자로 통합했습니다.

제한 사항 . 일반화하려면 향후 작업에서는 목표인 jCodec 이외의 프로젝트도 고려해야 합니다. 우리의 실험에서는 LLM에 의해 생성된 응답이나 이를 수정하거나 최적화하는 방식을 제어할 수 없는 API를 사용했습니다. 실험 중에 동작의 변화를 관찰하지는 못했지만 OpenAI는 언제든지 모델을 변경할 수 있으므로 향후 작업에서는 로컬 모델을 고려해야 합니다. 우리는 LLM 요청에 대해 세 가지 프롬프트 유형만을 실험했으며 이 제한된 수의 프롬프트 내에서 결과에 차이가 있음을 발견했습니다. 마지막으로 LLM의 응답을 구문 분석하기 위한 구현은 비교적 단순했습니다. 그러나 이는 우리가 보고한 결과가 비관적이며 LLM 기반 운영자가 훨씬 더 큰 개선을 달성할 수 있음을 의미할 뿐입니다.

요약 . Random Sampling을 사용한 표준 편집에서는 더 유효하고 다양한 패치가 발견되었지만 LLM 기반 편집에서는 단위 테스트를 통과한 패치가 더 많이 발견되었습니다. 예를 들어 중간 프롬프트를 사용한 LLM 편집에서는 기존 삽입 편집보다 단위 테스트를 통과하는 패치가 75% 이상 더 많았습니다. 지역 검색 실험에서는 명령문 편집(508ms)에서 가장 좋은 개선 사항을 발견했습니다. 최고의 LLM 기반 개선은 중간 프롬프트(395ms)에서 발견되었습니다. 따라서 LLM과 '전통적인' GI 편집을 결합한 접근 방식을 탐색할 가능성이 있습니다.

우리의 실험에 따르면 LLM 요청에 사용되는 프롬프트가 결과에 큰 영향을 미치는 것으로 나타났습니다. 따라서 향후 작업에서는 신속한 엔지니어링을 통해 더 많은 실험을 수행할 수 있기를 바랍니다. 프롬프트를 혼합하는 것도 도움이 될 수 있습니다. 예를 들어 중간에서 시작한 다음 세부로 전환하여 로컬 최소값을 벗어나는 더 큰 편집을 수행합니다. 또한 LLM 편집을 표준 복사/삭제/교체/교환 또는 PAR 템플릿[11]과 같은 다른 편집과 결합할 수 있는 가능성도 흥미로울 수 있습니다. 마지막으로 추가 테스트 프로그램에 대해 보다 광범위한 실험을 수행할 수 있기를 바랍니다.

데이터 가용성. 코드, LLM 프롬프트 및 실험적 인프라, 평가 데이터 및 결과는 [1]에서 오픈 소스로 제공됩니다. 코드는 github.com/gintool/gin의 'llm' 분기에도 있습니다(9fe9bdf 커밋, Gin과의 전체 통합을 보류 중인 마스터 커밋 2359f57에서 분기됨).

UKRI EPSRC EP/P023991/1 및 ERC 741278 에 대한 감사의 말씀을 드립니다 .

참고자료

1. 대규모 언어 모델을 사용하여 유전적 개선 돌연변이를 강화하는 인공물. 제노도 (2023년 9월). https://doi.org/10.5281/zenodo.8304433

   
   

2. B¨ohme, M., Soremekun, EO, Chattopadhyay, S., Ugherughe, E., Zeller, A.: 버그는 어디에 있으며 어떻게 수정됩니까? 실무자를 대상으로 한 실험입니다. 에서: Proc. 소프트웨어 엔지니어링의 기초에 관한 ACM 심포지엄. 117~128페이지(2017)

   
   

3. Brownlee, AE, Petke, J., Alexander, B., Barr, ET, Wagner, M., White, DR: Gin: 유전적 개선 연구가 쉬워졌습니다. 에서: GECCO. 985~993페이지(2019)

   
   

4. Brownlee, AE, Petke, J., Rasburn, AF: 더 빠른 Java 코드 실행을 위한 단축키 삽입. In: IEEE CEC 2020. p. 1~8

   
   

5. Chen, M., Tworek, J., Jun, H., Yuan, Q., Pinto, HPdO, Kaplan, J., Edwards, H., Burda, Y., Joseph, N., Brockman, G. 등 al.: 코드에 대해 훈련된 대규모 언어 모델 평가. arXiv 사전 인쇄 arXiv:2107.03374 (2021)

   
   

6. Fan, A., Gokkaya, B., Harman, M., Lyubarskiy, M., Sengupta, S., Yu, S., Zhang, JM: 소프트웨어 엔지니어링을 위한 대규모 언어 모델: 설문 조사 및 공개 문제(2023)

7. Github - jcodec/jcodec: Jcodec 메인 저장소, https://github.com/jcodec/jcodec

   
   

8. Han, SJ, Ransom, KJ, Perfors, A., Kemp, C.: 인간과 대규모 언어 모델의 귀납적 추론. 인지 시스템 연구 p. 101155 (2023)

   
   

9. Hou, X., Liu, Y., Yang, Z., Grundy, J., Zhao, Y., Li, L., Wang, K., Luo, X., Lo, D., Wang, H.: 소프트웨어 엔지니어링을 위한 대규모 언어 모델: 체계적인 문헌 검토. arXiv:2308.10620 (2023)

   
   

10. 강순, 유순.: 대규모 언어 모델을 통한 객관적 맞춤형 유전 개선을 향하여. arXiv:2304.09386 (2023)

    
    

11. 김동진, 남진, 송진, 김성수: 사람이 작성한 패치에서 학습한 자동 패치 생성(2013), http://logging.apache.org/log4j/

    
    

12. Kirbas, S., Windels, E., Mcbello, O., Kells, K., Pagano, M., Szalanski, R., Nowack, V., Winter, E., Counsell, S., Bowes, D., Hall, T., Haraldsson, S., Woodward, J.: Bloomberg의 자동 프로그램 복구 도입에 대해. IEEE 소프트웨어 38(4), 43–51(2021)

    
    

13. Marginean, A., Bader, J., Chandra, S., Harman, M., Jia, Y., Mao, K., Mols, A., Scott, A.: Sapfix: 자동화된 엔드투엔드 수리 규모. 에서: ICSE-SEIP. pp. 269~278(2019)

    
    

14. Petke, J., Alexander, B., Barr, ET, Brownlee, AE, Wagner, M., White, DR: Gin을 사용한 자동화된 프로그램 수정을 위한 프로그램 변환 환경. 경험적 소프트웨어 공학 28(4), 1–41 (2023)

    
    

15. Petke, J., Haraldsson, SO, Harman, M., Langdon, WB, White, DR, Woodward, JR: 소프트웨어의 유전적 개선: 포괄적인 조사. 진화 컴퓨팅에 관한 IEEE 거래 22, 415–432 (2018)

    
    

16. Siddiq, ML, Santos, J., Tanvir, RH, Ulfat, N., Rifat, FA, Lopes, VC: 단위 테스트 생성에서 대규모 언어 모델의 효율성 탐색. arXiv 사전 인쇄 arXiv:2305.00418 (2023)

    
    

17. Sobania, D., Briesch, M., Hanna, C., Petke, J.: chatgpt의 자동 버그 수정 성능 분석. In: 2023 APR(자동 프로그램 복구)에 관한 IEEE/ACM 국제 워크숍. 23~30쪽. IEEE 컴퓨터 학회(2023)

    
    

18. Xia, CS, Paltenghi, M., Tian, JL, Pradel, M., Zhang, L.: 대규모 언어 모델을 통한 보편적 퍼징. arXiv 사전 인쇄 arXiv:2308.04748 (2023)

    
    

19. Xia, CS, Zhang, L.: 대화를 계속하세요. chatgpt를 사용하여 337개의 버그 중 162개를 $0.42에 수정합니다. arXiv 사전 인쇄 arXiv:2304.00385 (2023)