언어 모델링의 새로운 시대가 도래했습니다. LLM(대형 언어 모델)은 자연어를 이해할 수 있을 뿐만 아니라 사용자 요구에 따라 맞춤형 코드를 생성할 수도 있습니다.
따라서 점점 더 많은 소프트웨어 엔지니어가 API를 사용하여 코드 조각을 생성하거나 코드에서 버그를 감지하는 등의 프로그래밍 질문에 답하기 위해 대규모 언어 모델을 쿼리하는 방법을 선택합니다. 대규모 언어 모델은 Stack Overflow와 같은 온라인 프로그래밍 포럼을 검색하는 것보다 프로그래밍 질문에 대해 더 적절하게 맞춤화된 답변을 검색할 수 있습니다.
LLM은 빠르지만 코드 생성 시 잠재적인 위험도 가려집니다. 소프트웨어 엔지니어링 관점에서 LLM 코드 생성 기능의 견고성과 신뢰성은 구문 오류 방지 및 생성된 코드의 의미론적 이해 향상 측면에서 많은 연구 결과가 발표되었음에도 불구하고 철저하게 연구되지 않았습니다.
온라인 프로그래밍 포럼의 상황과 달리 LLM에서 생성된 코드는 커뮤니티 동료가 검토하지 않으므로 파일 읽기 및 변수 인덱싱에서 경계 검사 누락, 파일 I/O 닫기 누락 등 API 오용 문제가 발생할 수 있습니다. 거래 완료 실패 등 생성된 코드 샘플이 올바르게 실행되거나 기능을 수행할 수 있더라도 잘못 사용하면 메모리 누수, 프로그램 충돌, 가비지 데이터 수집 실패 등 제품에 심각한 잠재적 위험이 발생할 수 있습니다.
더 나쁜 것은 이러한 질문을 하는 프로그래머가 API를 처음 접하고 생성된 코드 조각에서 잠재적인 문제를 식별할 수 없기 때문에 가장 취약한 프로그래머라는 것입니다.
아래 그림은 LLM에 프로그래밍 질문을 하는 소프트웨어 엔지니어의 예를 보여줍니다. Llama-2는 올바른 구문, 올바른 함수 및 구문 정렬이 포함된 코드 조각을 제공할 수 있음을 알 수 있지만 문제가 있습니다. 파일이 이미 존재하거나 폴더가 존재하지 않는다는 사실을 고려하지 않기 때문에 충분히 강력하고 신뢰할 수 없습니다.
따라서 대규모 언어 모델의 코드 생성 기능을 평가할 때는 코드의 신뢰성을 고려해야 합니다.
대규모 언어 모델의 코드 생성 기능을 평가하는 측면에서 대부분의 기존 벤치마크는 생성된 코드 실행 결과의 기능적 정확성에 중점을 둡니다. 즉, 생성된 코드가 사용자의 기능적 요구 사항을 충족할 수 있는 한, 사용자 그냥 수락하세요.
그러나 소프트웨어 개발 분야에서는 코드가 올바르게 실행되는 것만으로는 충분하지 않습니다. 소프트웨어 엔지니어에게 필요한 것은 장기적으로 잠재적인 위험 없이 새로운 API를 정확하고 안정적으로 사용할 수 있는 코드입니다.
또한 현재 대부분의 프로그래밍 문제의 범위는 소프트웨어 엔지니어링과는 거리가 멀습니다. 대부분의 데이터 소스는 Codeforces, Kattis, Leetcode 등과 같은 온라인 프로그래밍 챌린지 네트워크입니다. 비록 성과가 놀랍지만 실제 응용 시나리오에서 소프트웨어 개발이 작동하도록 돕는 것만으로는 충분하지 않습니다.
이를 위해 샌디에고 캘리포니아 대학교의 Li Zhong과 Zilong Wang은 대규모 언어 모델에서 생성된 코드의 신뢰성과 견고성을 평가할 수 있는 프레임워크인 RobustAPI를 제안했습니다. AST(Evaluator for Tree)를 사용한 추상 문법.
문서 주소: https://arxiv.org/pdf/2308.10335.pdf
데이터 세트의 목표는 실제 소프트웨어 개발에 가까운 평가 설정을 만드는 것입니다. 이를 위해 연구진은 스택오버플로(Stack Overflow)에서 자바에 관한 대표적인 질문들을 수집했다. Java는 가장 널리 사용되는 프로그래밍 언어 중 하나이며 WORA(Write Once Run Anywhere) 기능 덕분에 소프트웨어 개발에 널리 사용됩니다.
각 질문마다 연구원이 자세한 설명과 관련 Java API를 제공합니다. 또한 대규모 언어 모델을 호출하여 코드 조각과 해당 설명을 생성하기 위한 템플릿 세트를 설계했습니다.
연구원들은 생성된 코드 조각을 분석하고 예상되는 API 사용 패턴과 비교하기 위해 AST(추상 구문 트리)를 사용하는 평가기도 제공합니다.
연구원들은 또한 Zhang et al.(2018)의 방법에 따라 AI 사용 패턴을 구조화된 호출 순서로 공식화했습니다. 이 구조화된 호출 순서는 잠재적인 시스템 위험을 제거하기 위해 이러한 API를 올바르게 사용할 수 있는 방법을 보여줍니다. 소프트웨어 엔지니어링 관점에서 볼 때 이 구조화된 호출 순서를 위반하는 것은 모두 실패로 간주됩니다.
연구원들은 24개의 대표적인 Java API를 포함하여 Stack Overflow에서 1208개의 실제 질문을 수집했습니다. 연구진은 또한 비공개 소스 언어 모델(GPT-3.5 및 GPT-4)뿐만 아니라 오픈 소스 언어 모델(Llama-2 및 Vicuna-1.5)을 포함한 실험적 평가도 수행했습니다. 모델의 하이퍼파라미터 설정의 경우 기본 설정을 사용했으며 추가 하이퍼파라미터 조정을 수행하지 않았습니다. 그들은 또한 프롬프트에서 각각 0개 또는 1개의 데모 샘플을 제공하는 제로샷과 원샷이라는 두 가지 실험 형식을 설계했습니다.
연구원들은 LLM에서 생성된 코드를 종합적으로 분석하고 일반적인 API 오용을 연구했습니다. 그들은 이것이 코드를 생성할 때 LLM이 API를 오용하는 중요한 문제를 밝히고, 이 연구가 일반적으로 사용되는 기능적 정확성을 넘어 LLM 평가에 새로운 차원을 제공할 수 있기를 바랍니다. 또한 데이터 세트와 추정기는 오픈 소스입니다.
이 문서의 기여는 다음과 같이 요약됩니다.
RobustAPI는 LLM 생성 코드의 신뢰성과 견고성을 종합적으로 평가하기 위한 프레임워크입니다.
이 데이터 세트를 구축할 때 데이터 수집 프로세스와 프롬프트 생성 프로세스는 아래에 설명되어 있습니다. 그런 다음 RobustAPI에서 평가된 API 오용 패턴이 제공되고 오용으로 인한 잠재적 결과에 대해 논의됩니다. 추상 구문 트리를 사용하여 오용 사례에 대한 정적 분석이 제공됩니다.
키워드 매칭과 같은 규칙 기반 방법에 비해 새로운 방법은 LLM 생성 코드의 API 오용을 더 정확하게 평가할 수 있는 것으로 나타났습니다.
데이터 수집
소프트웨어 엔지니어링 분야의 기존 연구 결과를 활용하기 위해 연구진이 RobustAPI를 구축한 출발점은 exampleCheck(Zhang et al. 2018)의 데이터 세트였습니다. exampleCheck는 웹 Q&A 포럼에서 일반적인 Java API 오용을 연구하기 위한 프레임워크입니다.
연구원은 아래 표 1과 같이 이 데이터 세트에서 23개의 일반적인 Java API를 선택했습니다. 이 23개의 API는 문자열 처리, 데이터 구조, 모바일 개발, 암호화 및 데이터베이스 작업을 포함한 5가지 영역을 다룹니다.
프롬프트 생성
RobustAPI에는 데이터 세트의 샘플을 사용하여 채울 수 있는 프롬프트 템플릿도 포함되어 있습니다. 그런 다음 연구원들은 프롬프트에 대한 LLM의 응답을 수집하고 API 검사기를 사용하여 코드의 신뢰성을 평가했습니다.
이 프롬프트에서는 작업 소개와 필수 응답 형식이 먼저 제공됩니다. 그런 다음 수행된 실험이 소수 표본 실험인 경우 소수 표본 시연도 제공됩니다. 예는 다음과 같습니다.
데모 샘플
데모 샘플은 LLM이 자연어를 이해하는 데 도움이 되는 것으로 입증되었습니다. LLM의 코드 생성 능력을 철저히 분석하기 위해 연구원들은 단일 샘플 관련 없는 데모와 단일 샘플 종속 데모라는 두 가지 소수 설정을 설계했습니다.
단일 샘플 불가지론 데모 설정에서 LLM에 제공되는 데모 예제는 불가지론 API를 사용합니다. 연구원들은 이러한 데모 예제가 생성된 코드에서 구문 오류를 제거할 것이라고 가정했습니다. RobustAPI에서 사용되는 관련 없는 예는 다음과 같습니다.
단일 표본 상관 관계 데모 설정에서 LLM에 제공되는 데모 예제는 주어진 문제에 사용된 것과 동일한 API를 사용합니다. 이 예에는 질문과 답변 쌍이 포함되어 있습니다. 이 데모의 질문은 테스트 데이터 세트에 포함되지 않았으며 API 오용이 없고 답변과 질문의 의미가 잘 정렬되었는지 확인하기 위해 답변을 수동으로 수정했습니다.
Java API 오용
연구원들은 RobustAPI의 23개 API에 대한 40개의 API 규칙을 요약했으며 이는 해당 API의 문서에서 확인되었습니다. 이러한 규칙에는 다음이 포함됩니다.
(1) API 호출 전에 확인해야 하는 API에 대한 보호 조건입니다. 예를 들어, File.createNewFile() 전에 File.exists()의 결과를 확인해야 합니다.
(2) 필수 API 호출 순서, 즉 API는 특정 순서로 호출되어야 합니다. 예를 들어 File.write() 다음에 close()를 호출해야 합니다.
(3) API 제어 구조. 예를 들어 SimpleDateFormat.parse()는 try-catch 구조에 포함되어야 합니다.
다음은 예입니다.
API 오용 감지
코드에서 API 사용의 정확성을 평가하기 위해 RobustAPI는 API 사용 규칙에 따라 API 오용을 감지할 수 있습니다. 방법은 아래 그림 2와 같이 코드 세그먼트에서 호출 결과와 제어 구조를 추출하는 것입니다.
코드 검사기는 먼저 생성된 코드 조각을 검사하여 그것이 메서드의 코드 조각인지 또는 클래스의 메서드인지 확인하여 조각을 캡슐화하고 사용할 수 있도록 합니다. 추상 구문 트리를 구축합니다( AST).
그런 다음 검사기는 AST를 살펴보고 모든 메서드 호출과 제어 구조를 순서대로 기록하여 일련의 호출을 생성합니다.
다음으로 검사기는 이 호출 순서를 API 사용 규칙과 비교합니다. 각 메서드 호출에 대한 인스턴스 유형을 추론하고 해당 유형과 메서드를 키로 사용하여 해당 API 사용 규칙을 검색합니다.
마지막으로 검사기는 이 호출 시퀀스와 API 사용 규칙 사이에서 가장 긴 공통 시퀀스를 계산합니다.
호출 순서가 예상되는 API 사용 규칙과 일치하지 않으면 검사기가 API 오용을 보고합니다.
연구원들은 GPT-3.5, GPT-4, Llama-2 및 Vicuna-1.5의 4개 LLM에서 RobustAPI를 평가했습니다.
실험에 사용된 평가 지표로는 API 오용률, 실행 가능한 샘플 비율, 전체 API 오용 비율이 있습니다.
실험의 목적은 다음 질문에 답하는 것입니다.
특정 실험 프로세스에 대해서는 원본 논문을 참조하세요. 연구원이 얻은 5가지 결과는 다음과 같습니다.
발견 1: 현재 최고의 대규모 언어 모델은 일반적으로 실제 응답에 API 오류가 있습니다. -세계 프로그래밍 문제를 사용하십시오.
발견 2: 실행 가능한 코드가 포함된 모든 LLM 답변 중 57-70%의 코드 조각에는 API 오용 문제가 있으며 이는 프로덕션에서 심각한 결과를 초래할 수 있습니다.
발견 3: 관련 없는 샘플 예제는 API 오용률을 줄이는 데 도움이 되지 않지만 보다 효과적인 답변을 유발하여 모델 성능을 벤치마킹하는 데 효과적으로 사용할 수 있습니다.
발견 4: 일부 LLM은 올바른 사용 예를 학습하여 API 오용률을 줄일 수 있습니다.
발견 5: GPT-4에는 실행 가능한 코드가 포함된 답변 수가 가장 많습니다. 기본 API의 경우 LLM마다 오용률 추세가 다릅니다.
또한 연구원은 논문에서 GPT-3.5를 기반으로 한 일반적인 사례를 시연했습니다. 모델은 다양한 실험 설정에서 다양한 반응을 보였습니다.
이 작업은 PrintWriter.write API를 사용하여 파일에 문자열을 쓸 수 있도록 모델에게 요청하는 것입니다.
0샘플 및 1샘플 불가지론 데모 설정에서 답변은 약간 다르지만 둘 다 API 오용 문제가 있으므로 예외는 고려되지 않습니다. 모델에 API 사용의 올바른 예가 제공되면 모델은 API 사용 방법을 학습하고 안정적인 코드를 생성합니다.
자세한 내용은 원문을 참고해주세요.
위 내용은 GPT-4: 내가 작성한 코드를 감히 사용하시겠습니까? 연구에 따르면 API 오용률이 62%를 초과하는 것으로 나타났습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
