LLM 자동 발견은 병렬 초기화로 성능을 2~21% 끌어올린다

무엇인가

LLM을 최적화기로 쓰는 자동 발견(discovery) 하네스는 목표를 자연어로 제시하고 과거 해답들을 문맥에 넣어 반복 개선하는 방식으로 알고리즘, 프롬프트, 약물 후보 등을 찾아낸다. 문제는 어떤 하네스 설계가 좋은지, 그리고 문맥에 쌓이는 과거 iterate 집단(population)이 최종 성공에 어떤 영향을 주는지가 체계적으로 규명되지 않았다는 점이다. 이 논문은 그 관계를 12종 하네스, 5개 과제, 여러 LLM 조합에서 실증하고, 결국 초기 후보군의 품질이 성패를 가른다는 결론에 도달한다.

어떻게 동작하나

방법의 뼈대는 OPRO 프레임워크를 일반화해 만든 Modular라는 12종 하네스다. LLM 변이(mutation) 전략 4가지와 부모 샘플링 전략 3가지를 조합해 하네스 설계 공간을 넓게 노출시킨다. 실험 과제는 멀티클라우드 데이터 전송 비용 최적화(CloudCast), 스팟 인스턴스 마감 기한 스케줄링(Can't Be Late), 단위 정사각형 안에 지름이 다른 원 26개를 겹치지 않게 배치하는 Circle Packing, 도시 100개를 한 번씩 도는 최단 경로(TSP), GSM8K 점수를 최대화하는 지시문 프롬프트 탐색이다. 평가 지표는 세 가지다. 궤적 내 최고 점수, 토큰 소비량, 그리고 다양성이다. 특히 비용을 발견 평가 횟수가 아니라 토큰 수로 측정한 것이 중요한데, 하네스마다 한 번의 발견을 만드는 데 쓰는 추론 연산량이 달라 평가 횟수 비교는 공정하지 않기 때문이다. 다양성은 발견들을 문장 임베딩 모델(all-MiniLM-L6-v2, 코드 과제는 nomic-ai/CodeRankEmbed)로 임베딩한 뒤 평균 쌍별 코사인 유사도를 1에서 뺀 값으로 정의한다.

무엇과 다른가

첫 번째 실험은 순차 대 병렬이다. 문맥을 전혀 갱신하지 않고 같은 시드에서 독립적으로 병렬 샘플링만 하는 방식과 12개 순차 하네스를 같은 토큰 예산으로 비교했다. 결과는 어느 한쪽의 압승이 아니다. TSP에서는 병렬이 순차 하네스들에 뒤졌고, Circle Packing에서는 반대로 병렬이 앞섰다. 과제마다 최고 성능을 내는 Modular 변형이 달라진다는 점도 확인된다. 저자들은 이를 두고 하네스 기반 발견이 견고하지 않다(brittle)고 표현한다. 즉 문맥 지식은 분명 중요하지만, 그 문맥을 어떻게 큐레이션하고 관리할지가 과제와 LLM에 종속적이라는 것이다. 그리고 순차 궤적에서는 새 후보의 다양성이 진행될수록 급격히 떨어지는 모드 붕괴(mode collapse)가 공통 실패 모드로 나타난다.

어떻게 쓰나

그렇다면 더 많이 탐색하면 해결될까. 저자들은 최신 하네스인 ShinkaEvolve, OpenEvolve, optimize_anything을 같은 조건에서 비교한다. 이들은 평균적으로 더 다양한 발견을 만들어내지만, 다양성이 낮은 Modular 변형보다 성능이 떨어지는 경우가 많았다. 하네스 설계를 고정한 채 다양성 유지 개입만 적용한 실험도 마찬가지다. 코사인 유사도 임계값(0.95, 0.8)으로 신규 후보를 거부하거나, LLM-Judge(Gemini 3.5 Flash)가 유의미한 차이가 없다고 판정하면 거부하거나, 단순 중복 제거를 하는 세 가지 방식 모두 다양성은 늘렸지만 성능 효과는 일관되지 않았고 일부 설정에서는 오히려 성능을 해쳤다. 대신 저자들이 찾은 신호는 따로 있다. 한 궤적의 첫 15개 발견 점수가 그 궤적의 최종 최대 점수를 예측한다는 것이다.

전제와 한계

여기서 제안 방법이 나온다. 전체 예산 중 일부 비율 r을 병렬 탐색에 투입해 후보 풀을 만들고, 코사인 유사도 임계값을 적용한 그리디 선택으로 크기 m=15의 초기 population을 큐레이션한 다음, 그 population으로 순차 하네스를 warm-start하는 것이다. 고유 후보가 부족하면 중복을 제거한 상위 성능 후보로 남은 슬롯을 채운다. r=0은 초기화 없는 순수 순차, r=1은 순수 병렬에 해당하는데, 0<r<1인 초기화가 두 극단을 모두 앞선다. 초기 population의 다양성 수준 s를 1(그리디), 0.98, 0.95, 0.8로 바꿔보면 그리디가 대체로 좋지만 초기 풀에 중복이 많을 때는 s=0.98이 더 나았다. 반대로 s<0.98처럼 훨씬 다양하게 큐레이션하면 평균 population 성능이 떨어져 이후 발견 점수도 낮아진다. 정확 중복과 아주 근접한 중복만 걸러내는 최소 필터링이면 충분하다는 결론이다.

초기화 예산은 얼마로 잡아야 하는가. 저자들은 병렬 발견의 품질이 일정 시점에 수렴한다는 관찰에 기대어, 예산을 한꺼번에 쓰지 않고 배치 단위로 병렬 탐색을 돌리며 수렴을 감지하는 기준을 제안한다. 이렇게 감지된 수렴 지점이 실제로 최고 성능을 내는 초기화 예산과 일치했고, 같은 과제 기준이 여러 LLM에 걸쳐 통했다. 최신 하네스에 이 명시적 초기화를 적용한 실험에서는 모든 (과제, LLM) 조합에서 초기화 이후 발견 점수가 2%에서 21%까지 올랐다. 저자들은 기존 하네스가 스스로 고성능 궤적을 암묵적으로 초기화하지 못한다고 지적한다.

개발자 관점에서 실무적으로 쓸 수 있는 지점은 명확하다. LLM으로 프롬프트나 알고리즘을 반복 개선하는 루프를 직접 돌린다면, 예산 전부를 순차 개선에 넣지 말고 앞부분 일부를 독립 병렬 샘플링에 떼어 초기 후보 품질을 끌어올린 뒤 순차 단계로 넘어가는 편이 낫다. 다양성 유지 트릭을 무조건 붙이는 것은 답이 아니다. 또한 하네스 간 비교를 할 때는 평가 횟수가 아니라 토큰 기준으로 맞춰야 공정하다. 초기 population 크기, 유사도 임계값, 초기화 비율 같은 값은 과제별로 튜닝이 필요하다.

한계도 분명하다. 이 연구는 문맥(in-context) 지식의 영향만 다뤘고, LLM의 파라메트릭 지식이 발견 품질에 미치는 영향은 향후 과제로 남긴다. 병렬 발견의 성능 상한을 사전에 알 수 없다는 점, 그리고 발견 과제에 대해 모델의 파라메트릭 지식을 정량화하기 어렵다는 점도 전제로 깔려 있다. 저자들은 희귀한 지식 영역에 속한 발견 목표를 LLM이 잘하는 영역의 언어로 다시 표현하는 것(예: 알고리즘 설계 문제를 희귀 언어가 아니라 대중적인 프로그래밍 언어로 표현)이 도움이 될 수 있다고 덧붙인다.