PaperlayerView exact revision on arXiv

Source-linked AI summary

When to Show a Suggestion? Integrating Human Feedback in AI-Assisted Programming

Hussein Mozannar, Gagan Bansal, Adam Fourney, Eric Horvitz

arXiv:2306.04930v3cs.HCcs.LGcs.SE

TL;DR

AI 코드 추천 시스템은 불필요한 검증이나 지연을 늘리지 않으면서, 프로그래머 피드백을 활용해 제안을 보여줄 가치가 있는 시점을 원칙적으로 결정해야 한다. 이 논문은 Copilot telemetry에서 수용 여부를 예측하고 제안을 선택적으로 숨기는 utility-theoretic cascade인 CDHF를 제안한다. 회고적 데이터는 표시 및 생성되는 제안이 크게 감소함을 보이며, 프로그래머의 잠재 상태가 중요하고 수용 최적화가 품질이 낮은 짧은 제안을 선호할 수 있음을 보여준다.

  • 문제

    이 논문은 예상 수용도와 유용성을 검증 및 생성 비용과 비교해 균형을 맞춤으로써, AI가 생성한 코드 제안을 언제 표시해야 하는지 묻는다.

  • 방법

    CDHF는 Copilot telemetry에 대한 utility-theoretic framework와 model cascade를 사용해 제안을 생성하고 표시할지 결정한다.

  • 결과

    회고적으로 CDHF는 표시된 제안의 25%를 숨기면서 그중 95%가 거부되었을 것임을 보장하고, 생성의 13%를 줄이며 수용률을 7.2% 높일 수 있었다.

  • 시사점 및 한계

    수용 피드백은 프로그래머의 검증과 시스템 지연을 줄이는 제안 표시 결정에 활용될 수 있지만, 수용 최적화는 품질이 낮은 짧은 제안을 만들어낼 수 있다.

  • 시사점 및 한계

    평가가 회고적으로 이루어졌으므로, CDHF 적용 전후의 Copilot을 결정적으로 평가하려면 전향적 연구가 필요하다.

Abstract

from arXiv · show

AI powered code-recommendation systems, such as Copilot and CodeWhisperer, provide code suggestions inside a programmer's environment (e.g., an IDE) with the aim of improving productivity. We pursue mechanisms for leveraging signals about programmers' acceptance and rejection of code suggestions to guide recommendations. We harness data drawn from interactions with GitHub Copilot, a system used by millions of programmers, to develop interventions that can save time for programmers. We introduce a utility-theoretic framework to drive decisions about suggestions to display versus withhold. The approach, conditional suggestion display from human feedback (CDHF), relies on a cascade of models that provide the likelihood that recommended code will be accepted. These likelihoods are used to selectively hide suggestions, reducing both latency and programmer verification time. Using data from 535 programmers, we perform a retrospective evaluation of CDHF and show that we can avoid displaying a significant fraction of suggestions that would have been rejected. We further demonstrate the importance of incorporating the programmer's latent unobserved state in decisions about when to display suggestions through an ablation study. Finally, we showcase how using suggestion acceptance as a reward signal for guiding the display of suggestions can lead to suggestions of reduced quality, indicating an unexpected pitfall.

1 서론

AI 코드 추천 시스템은 프로그래머의 생산성 향상을 목표로 하지만, 이 연구는 수용 피드백과 지연시간을 고려한 효용을 사용해 제안을 언제 표시하거나 보류해야 하는지 묻는다. CDHF는 수용되지 않을 가능성이 높은 제안을 숨기는 예측 모델을 사용하며, 회고적 결과는 표시 횟수와 생성량은 줄고 수용률은 높아짐을 보여준다.

  • 접근법: CDHF는 효용 이론에 기반한 표시 규칙과 수용 모델의 cascade를 사용해 제안을 생성하고 표시할 가치가 있는지 결정한다.이 절차는 예상 수용률과 생성 지연시간을 비교하며, 설정된 거부 확률 임계값에 따라 제안을 보류할 수 있다.
  • 평가: 표시된 제안의 25%는 숨길 수 있었으며, 그 경우 95%가 거부되었을 제안임을 보장할 수 있었고, 이러한 제안의 13%는 생성을 피할 수 있었다.회고적 평가는 535명의 프로그래머 세션과 168k개 제안에 대한 피드백을 사용했다.
  • 평가: CDHF는 수용률을 7.2% 높이는 동시에, 생성을 중단하는 parameter를 통해 표시되는 제안과 지연시간 사이의 균형을 맞출 수 있었다.이 절충을 통해 시스템은 제안의 생성 또는 표시를 얼마나 적극적으로 피할지 조절할 수 있다.
  • 함의: 저자들은 CDHF를 더 나은 제안 표시를 위한 로드맵으로 제시하며, 최소한의 버전이 최신 GitHub Copilot 릴리스에 구현되었다고 설명한다.또한 이러한 통찰이 Copilot과 코드 기반 작업을 넘어 확장될 수 있다고 말한다.
  • 확장: 이 연구는 제안을 선택하는 보상으로 수용을 사용하는 방안도 검토하며, 부분 완성이 완전한 코드 구간보다 우선될 수 있음을 발견한다.서론은 이를 추천을 언제 표시할지 결정하는 문제를 넘어선 별도의 방향으로 제시한다.

2 관련 연구

선행 연구는 학습된 품질 추정치를 사용해 코드 제안을 선택적으로 숨기는 반면, 본 논문은 Copilot telemetry에서 자연스럽게 수집된 프로그래머의 수락 피드백을 사용한다. CDHF는 기반 language model을 업데이트하기보다 빠른 inference와 표시 여부 결정에 중점을 둔다.

  • 선택적 표시: CDHF는 코드 완성 품질 데이터셋이 아니라 실제 프로그래머 행동으로부터 제안 수락을 추정한다는 점에서 QEBC [SDS+22]와 다르다.이 비교는 Copilot telemetry와 [SDS+22]에서 사용한 맞춤 학습 모델도 구분한다.
  • 시스템 설계: 이 접근법은 latency를 줄이기 위해 빠른 inference를 우선하며, language model을 업데이트하는 대신 제안을 숨긴다.이러한 운영상의 초점은 표시 개입을 모델 학습 접근법과 구별한다.
  • 기반 이론: 본 논문은 machine learning과 utility를 사용해 인간-AI 기여를 유도한 선행 연구 를 바탕으로 이론적 정식화를 구축한다.본 논문의 기여는 이러한 틀을 AI 보조 코드 제안 표시에 적용하는 데 있다.

3 문제 설정

문제 설정은 Copilot을 일시 정지 후 suggestion을 생성하고, telemetry에 prompt, suggestion, programmer action을 기록하는 시간 인덱스 기반 상호작용으로 모델링한다. Telemetry는 이벤트 사이의 활동을 누락하므로, programmer latent state는 acceptance prediction에서 중요하지만 관측되지 않는 요인이다.

  • 상호작용 설계: 핵심 설계 질문은 Copilot이 IDE에 suggestion을 언제 주입해야 하는가이며, 기존 시스템은 짧은 일시 정지를 감지하면 suggestion을 트리거한다.대안적 설계에서는 programmer의 명시적 요청을 요구하거나 human initiative와 machine initiative를 결합할 수 있다.
  • AI-Assisted Programming: Copilot은 시점 t의 code context에서 suggestion을 생성하고 t + τ에 제시하며, 여기서 τ는 language-model latency를 나타낸다.Programmer는 suggestion을 accept하거나 reject할 수 있으며, 계속 입력하면 암묵적으로 rejection이 트리거된다.
  • Telemetry: Telemetry는 세션 내 event time, action, prompt, suggestion을 기록하여 각 coding session의 이산화된 표현을 구성한다.Figure 2는 이러한 이벤트를 timeline으로 나타내며, 그 결과 데이터는 human-feedback signal을 제공한다.
  • Programmer State: Programmer latent state는 programmer가 suggestion을 검증하는 중인지, 또는 thinking이나 documentation consulting과 같은 활동에 참여하는 중인지를 포착한다.이 state는 recommendation value에 영향을 미치지만, 연속된 telemetry timestamp 사이에는 기록되지 않는다.

4 제안 효용의 이론적 정식화

이 논문은 제안을 숨기는 대신 표시했을 때 프로그래머의 총 코딩 시간이 어떻게 변하는지를 제안 효용으로 정식화한다. 기대 이익이 검증, 지연, 편집 및 거부 관련 비용을 초과할 때 제안을 표시해야 하지만, 효용을 직접 추정하기는 어렵다.

  • 프로그래머 모델: 제안을 표시하면 검증 및 지연 비용에 수락 가중 편집 시간과 거부 가중 작성 시간이 결합되는 반면, 제안을 숨기면 코드를 직접 작성해야 한다.이 모델은 이후 제안이 편집 및 작성 시간에 영향을 미치는 것도 허용한다.
  • 제안 효용: 제안 효용 δ는 제안을 표시함으로써 발생하는 프로그래머의 코딩 시간 변화를 나타내며, δ > 0이면 제안 표시가 작업 시간을 줄인다는 뜻이다.최적 정책은 효용이 양수일 때만 제안을 표시하는 것이다.
  • 효용 추정의 실행 가능성: δ를 직접 추정하려면 네 가지 양이 필요하지만, 높은 분산과 관측되지 않은 교란변수 때문에 검증 시간 예측은 R2 = 0.13의 성능만 달성한다.따라서 이 논문은 실제 방법론을 수락 확률 추정으로 제한한다.
  • 잠재 프로그래머 상태: 텔레메트리에는 프로그래머의 잠재 상태 ϕ가 포함되지 않으므로, 실제 모델은 P(A = accept|X, S, ϕ)가 아니라 P(A = accept|X, S)를 추정한다.보고된 ablation에서 정확도는 잠재 상태가 없을 때 61.9 ± 1.9에서 있을 때 83.6 ± 2.4로 상승했으며, p = 6.9e −7이고 t = 7.11이다.
  • 수락 임계값: 지연이 0일 때 P*에서는 표시와 숨김의 시간 비용이 동일하므로, 이 그림은 총 시간과 프로그래머의 조건부 수락 확률을 비교한다.도표에 표시된 수락 확률은 P(A = accept|X, S, ϕ)이다.
  • 수락 임계값: 수락 후 편집에 비해 거부 관련 작성 비용이 커질수록 수락 임계값 P*는 낮아지는 반면, 검증과 지연은 임계값을 높인다.수락 확률이 P*보다 낮으면 제안을 표시하지 않아야 한다는 것이 이 명제의 내용이다.

5 인간 피드백 기반 조건부 제안 표시

CDHF는 제안을 표시할지 결정하기 위해 cascade predictor를 사용하며, 때로는 제안을 생성하기 전에 결정한다. 이 설계는 거부될 가능성이 높은 제안을 숨기는 것과 제안 생성 latency 없이 정확한 결정을 내리는 것 사이의 균형을 맞추는 동시에, 숨겨진 제안의 거부율을 제한한다.

  • 표시 결정: CDHF는 먼저 code-only 정보로 제안을 생성하지 않고도 표시 결정을 내릴 수 있는지 판단한 뒤, 필요할 때 suggestion-aware 정보를 사용한다.이 2단계 설계는 더 어려운 결정을 위해 제안에 계속 접근할 수 있게 하면서 불필요한 LLM 호출을 줄인다.
  • Model Parameterization: 이 cascade는 code-only routing function r(X)과 1단계 및 2단계 acceptance predictor m1(X), m2(X, S)를 결합해 표시 결정 m(X, S)를 산출한다.When r(X) = 1, the system decides before generating S; otherwise it generates S and applies the second-stage model.
  • 목표와 보장: 이 방법은 거부되었을 제안을 숨기고 생성 전에 이루어지는 결정의 비율을 높이도록 최적화하되, 숨겨진 제안이 거부될 확률 p 이상이라는 제약을 둔다.suggestion-aware 결정이 더 정확하기 때문에 두 목표 사이에는 상충 관계가 있다.
  • Parameterization: CDHF는 calibrated acceptance predictor를 적합하고 threshold t1, t2, tr을 조정하며, entropy 기반 routing으로 code-only prediction이 충분히 결정적인 시점을 제어한다.threshold는 [0, 1]3에 대해 jointly 최적화되며, 이 절차는 LLM 호출을 줄여 latency를 절감한다.
  • 구현: 시스템은 programmer가 표시 결정을 override할 수 있도록 keyboard shortcut을 유지하며, 논문은 CDHF를 retrospective하게 평가한다.이 override는 자동화된 policy가 숨긴 제안에도 사용자가 접근할 수 있게 한다.

6 실험

실험에서는 Copilot telemetry를 사용해 CDHF를 평가하며, acceptance prediction, selective hiding, latency-aware generation, counterfactual outcomes를 측정한다. 결과는 display와 generation 사이의 유용한 trade-off를 보여주지만, retrospective 설계와 acceptance-based objective는 중요한 한계를 부과한다.

  • 6 실험: telemetry 평가에는 4,749개 coding session에 걸친 Python 프로그래머 535명이 참여했으며, 총 관찰 시간은 거의 1,675시간, 표시된 event는 168,807개였다.관찰된 acceptance rate는 21.4%였으며, 저자들은 이를 Copilot의 평균 acceptance rate로 해석해서는 안 된다고 밝혔다.
  • 6.2 Model Evaluation: 사용자 간 분할에서 acceptance model은 0.780 AUC를 달성했지만, suggestion feature를 제거하면 AUC가 0.631로 감소했다.personalized model의 accuracy는 81.1%였으며, 평가에서는 95% confidence interval도 보고되었다.
  • 6.3 Retrospective Evaluation of CDHF: CDHF는 suggestion을 숨기는 비율과 숨긴 suggestion이 실제로 거부되었을 때의 보장 accuracy 사이에서 trade off를 조정하는 operating point를 통해 hiding 및 generation 결정을 달리한다.Figure 5에서는 원하는 FNR/TNR constraint와 suggestion을 생성하기 전 또는 후에 이루어지는 결정의 빈도 R을 변화시킨다.
  • 6.3 Retrospective Evaluation of CDHF: 표시된 suggestion 중 25.3%는 숨길 수 있었으며, 이 경우 94.7%가 거부되었을 것임을 보장하면서 suggestion의 12.9%에 대한 generation을 피할 수 있었다.latency concern이 없다면 CDHF는 52.9%를 숨기면서 91.3%가 거부되었을 것임을 보장할 수 있었다.
  • Discussion and Limitations: 평가는 retrospective 방식이므로, CDHF가 프로그래머의 생산성을 높이는지 검증하려면 user study가 필요하다.논문은 또한 대표성이 충분하지 않은 training data로 인해 CDHF가 유용한 suggestion을 숨길 수 있으며, 거부된 suggestion도 여전히 유용할 수 있다고 경고한다.

7 어떤 Suggestion을 표시할 것인가?

이 논문은 예측된 acceptance를 기준으로 후보 code의 순위를 매기는 것이 어떤 suggestion을 표시할지 결정할 수 있는지 검토한다. 실험 결과, 이 목표는 매우 짧은 suggestion을 선호할 수 있으며, acceptance를 reward로 사용할 때 주의가 필요함을 시사한다.

  • 결과: k > 0일 때, 가장 높은 점수를 받은 suggestion은 164개 문제 중 60개 초과에서 [0, 0.2] length percentile에 속하며, 최소 40개 문제에서는 첫 번째 token이다.k = 0일 때 normalized length는 거의 균일하며, Kolmogorov–Smirnov test p-value는 0.53이고 KS=0.06이다.
  • 짧은 Suggestion을 향한 잠재적 편향: Acceptance 기반 ranking은 짧은 suggestion을 선호할 수 있다. 가장 높은 점수를 받은 candidate가 solution의 처음 몇 줄 안에 놓이는 경우가 많기 때문이다.저자들은 이 ranking scheme이 품질이 낮은 짧은 suggestion을 생성할 수 있다고 가정한다.
  • 한계: 짧은 suggestion에 대한 발견은 model이 Copilot suggestion만으로 trained되었다는 점에서 제한적이며, 이러한 suggestion 자체가 짧은 suggestion 편향을 반영할 수 있다.논문은 또한 embedding 기반 reward model이 AUC=0.701로 accepts를 예측했다고 보고하면서, language model을 fine-tuning하는 경우와 비교할 때 발생할 수 있는 편향을 지적한다.

8 결론

이 논문은 코드 제안을 언제 표시할지 결정하는 utility-theoretic 전략인 CDHF를 제안하며, Copilot의 utility를 희생하지 않고 제안 수와 프로그래머의 소요 시간을 줄일 수 있음을 회고적으로 확인한다.

  • 8 결론: CDHF는 utility theory에 기반한 2단계 예측 절차를 사용해 코드 제안을 표시할 시점을 결정한다.모델은 제안 수락 여부를 예측하고 제안을 표시할지 숨길지를 결정하도록 안내한다.
  • 8 결론: 회고적 평가에서 CDHF는 Copilot의 utility를 희생하지 않고 제안 수와 프로그래머의 소요 시간을 줄일 수 있는 것으로 나타났다.
  • 8 결론: 결론적인 평가를 위해서는 CDHF 적용 여부에 따른 Copilot 비교 전향적 연구가 필요하다.
  • 8 결론: 저자들은 CDHF가 유용하지 않은 제안을 걸러내는 filtering mechanism으로 기능하며 Copilot을 넘어서는 부정적 결과를 초래하지 않을 것으로 예상된다고 밝힌다.
  • 8 결론: 향후 연구에서는 프로그래머의 latent state를 예측 모델에 통합하고 CDHF 모델을 사용해 제안 순위를 매기는 방안을 조사할 예정이다.
  • 8 결론: 이 논문은 사용자 연구를 통해 CDHF의 효능을 검증하지 않는다.

A 확장된 관련 연구

관련 연구는 CDHF를 코드 추천 평가, human-feedback learning, collaborative filtering, interactive interfaces, algorithmic deferral의 맥락에 위치시킨다. CDHF는 language model을 업데이트하지 않고 실제 Copilot 사용 행태에서 얻은 암묵적 telemetry feedback을 활용한다.

  • A 확장된 관련 연구: 기존 연구는 Copilot의 효과에 대해 엇갈린 근거를 보고한다. 여기에는 주관적으로 인식된 생산성 향상, 코딩 반복 시간의 감소, 유의한 task-completion time 개선의 부재가 포함된다.
  • A 확장된 관련 연구: 오프라인 code-completion 평가와 달리, CDHF는 현재 사용 중인 code-recommendation system에서 실제 프로그래머의 행동을 활용한다.CDHF의 acceptance estimator는 custom-trained completion dataset이 아니라 Copilot telemetry에 기반한다.
  • A 확장된 관련 연구: Reinforcement learning from human feedback은 선호를 수집하고 reward model을 학습한 뒤 language model을 업데이트하지만, CDHF는 suggestion display만 유도한다.
  • A 확장된 관련 연구: CDHF는 명시적 선호 대신 암묵적으로 수집된 acceptance 또는 rejection telemetry를 사용하며, underlying language model의 업데이트를 피한다.
  • A 확장된 관련 연구: Collaborative filtering은 콘텐츠의 순위를 재조정하는 반면, CDHF는 code suggestion을 생성하고 순위를 매기는 두 과정을 모두 다뤄야 한다.
  • A 확장된 관련 연구: Algorithmic deferral는 인간과 AI 중 누가 수행할지 결정하기 위해 오류를 추정하는 반면, CDHF는 언제 지원을 제공할지 결정하기 위해 시간 비용을 추정한다.

B P∗의 도출

이 도출은 제안 표시의 기대 시간 영향을 검증, 작성, 편집 및 latency 비용과 같게 두어 제안 표시를 위한 threshold P*를 정의한다. 예측된 수락 확률이 이 threshold보다 낮으면 제안을 숨겨야 한다.

  • B P∗의 도출: 예측된 수락 P(A = accept|X, S, ϕ)가 P*보다 낮으면 제안을 표시하지 않아야 하며, P*보다 높으면 제안을 표시해야 한다.
  • B P∗의 도출: 이 도출은 수락된 제안의 편집 시간이 거부된 제안의 작성 시간보다 짧다고 가정한다.
  • B P∗의 도출: P*는 기대 검증 시간, latency, 거부된 제안의 작성 시간 및 수락된 제안의 편집 시간을 결합해 표시 threshold를 구성한다.
  • B P∗의 도출: 거부된 제안이 이후 작성에 아무런 이점을 제공하지 않는다는 추가 가정하에서 P*는 거부 사례의 작성 시간을 일반 작성 시간으로 대체하여 단순화된다.
  • B P∗의 도출: P*는 [0, 1]에서 유효한 확률이 반드시 되는 것은 아니므로, 확률 추정치가 아니라 의사결정 threshold로 기능한다.
  • B P∗의 도출: 이 모델은 프로그래머가 제안을 수락하거나 거부한다고 가정하며, 거부는 계속 입력함으로써 암묵적으로 발생한다.

C 모델 평가 및 분석

평가는 acceptance-prediction 모델, calibration, sample complexity, feature importance, 그리고 user study로의 transfer를 분석한다. Stage 2는 training data의 1%에서 0.69 AU-ROC, 25%에서 0.75 AU-ROC에 도달하며, predictor는 인과관계를 확립하기보다 programmer behavior와 상관된다.

  • Calibration: Stage 2 XGBoost 모델은 calibration이 양호한 것으로 보고된다.
  • Sample Complexity: Training data의 25%를 사용하면 stage 2 acceptance 모델에서 0.75 AU-ROC를 얻으며, 1% 또는 1688 samples를 사용했을 때의 0.69 AU-ROC와 비교된다.
  • Factors Influencing Programming Actions: 가장 중요한 두 feature는 Copilot의 suggestion confidence와 suggestion length이며, 이를 함께 사용하면 0.71 AUROC의 모델이 생성된다.
  • Factors Influencing Programming Actions: 최근 coding-session context와 textual properties도 acceptance behavior와 상관되며, suggestion이 '#' 문자를 포함하는지도 이에 해당한다.트리 앙상블에서 '#' feature는 8회 분할되었다.
  • Factors Influencing Programming Actions: Feature-importance 결과는 programmer behavior와의 상관관계를 기술하며, 인과적으로 해석해서는 안 된다.
  • Analysis of Suggestions: 21명의 참가자가 참여한 user study에서 수집한 accepted 및 rejected event 1029개를 대상으로 평가했을 때, 모델은 0.73 AU-ROC를 달성한다.
  • Analysis of Suggestions: 거부될 가능성이 가장 높은 suggestion은 작은 non-alphabetic completion과, 이미 입력 중인 programmer의 주의를 분산시킬 수 있는 midword completion 주변에 집중된다.

D 어떤 제안을 보여줄 것인가: 플롯

실험에서는 모델의 acceptance probability가 가장 높은 suggestion이 length distribution에서 어디에 위치하는지, 그리고 k=0, 1, 2, 3에서 suggestion length에 따라 acceptance probability가 어떻게 변하는지 살핀다. probability normalization 유무와 관계없이 동일한 추세가 나타난다.

  • D 어떤 제안을 보여줄 것인가: 플롯: 플롯은 acceptance probability가 가장 높은 suggestion의 length-percentile 위치와 suggestion length 증가에 따른 normalized acceptance probability를 모두 측정한다.각 example에서 raw acceptance probabilities는 해당 example의 length 전반에서 최댓값으로 정규화된다.
  • D 어떤 제안을 보여줄 것인가: 플롯: 정규화하지 않아도 관찰된 추세가 유지되므로, 플롯의 패턴이 각 example 내 probability 재스케일링만으로 생성된 것이 아님을 알 수 있다.raw probabilities를 정규화하지 않고 그대로 두었을 때에도 동일한 추세가 관찰된다고 기술한다.
  • D 어떤 제안을 보여줄 것인가: 플롯: 분석은 k=0, k=1, k=2, k=3을 다루며, 이는 docstring만 있는 context부터 docstring과 처음 세 solution lines가 함께 있는 context까지에 해당한다.Figures 10–13은 각 k 값에 대한 플롯을 별도로 보고한다.
Loading 2306.04930v3…