코드로 하는 정책: LLM이 로봇 프로그램 짜기

코드로 하는 정책: LLM이 로봇 프로그램 짜기

코드를 쓰도록 학습된 대형 언어 모델에게 "자연어 지시 → 로봇 정책 코드" 예시 몇 개를 보여 주면, 새 지시에 맞는 파이썬 프로그램을 스스로 짜서 로봇을 움직입니다. 추가 학습 없이 공간 추론 · 피드백 루프 · "더 빨리" 같은 모호한 말의 수치화까지 해내며, LLM을 로봇의 '계획자'에서 '프로그래머'로 끌어올린 논문입니다.

들어가기 전에

이 해설은 아래 내용을 안다고 보고 씁니다. 처음이라면 먼저 읽고 오면 수식과 손계산을 훨씬 쉽게 따라올 수 있습니다.

• 말한 대로가 아니라 할 수 있는 대로 (SayCan) — LLM의 '쓸모' 점수와 가치 함수의 '지금 가능' 확률을 곱해 로봇이 긴 자연어 지시를 수행하게 한 방법
• 생각의 사슬 프롬프팅 (Chain-of-Thought) — 예시에 풀이 과정을 넣기만 해도 큰 언어 모델의 추론 성능이 크게 오른다는 논문

한눈에 보기

• 이전 방법이 LLM을 "기술 이름을 순서대로 고르는 계획자"로만 썼을 때 무엇을 못 했는지 압니다.
• 언어 모델 프로그램(LMP)이 힌트(Hints)와 예시(Examples) 두 가지로 이루어진 프롬프트에서 어떻게 만들어지는지 압니다.
• 정의되지 않은 함수를 재귀적으로 채워 넣는 계층적 코드 생성의 동작과 효과(HumanEval 39.8% P@1)를 압니다.
• 코드로 추론하면 자연어 · 생각의 사슬보다 공간 · 기하 계산이 왜 정확한지, 작은 숫자로 직접 확인합니다.
• 이 방식이 어디까지 되고, 어디서 막히는지(인식 API · 제어 기본 동작의 범위)를 압니다.

초록 (번역)

코드 완성으로 학습된 대형 언어 모델(LLM)은 독스트링으로부터 간단한 파이썬 프로그램을 합성할 수 있다는 것이 알려져 있습니다[1]. 우리는 이처럼 코드를 쓰는 LLM을, 자연어 명령이 주어졌을 때 로봇 정책 코드를 작성하는 용도로 다시 쓸 수 있음을 발견했습니다. 구체적으로, 정책 코드는 인식 결과(예: 물체 검출기[2], [3]의 출력)를 처리하는 함수나 피드백 루프를 표현하고, 제어 기본 동작 API의 매개변수를 정할 수 있습니다. 예시 언어 명령 몇 개(주석 형식)와 그에 대응하는 정책 코드를 입력으로 주면(퓨샷 프롬프트), LLM은 새 명령을 받아 API 호출을 스스로 다시 조합해 그에 맞는 새 정책 코드를 생성합니다. 고전적인 논리 구조를 이어 붙이고 산술을 위해 서드파티 라이브러리(예: NumPy, Shapely)를 참조함으로써, 이렇게 쓰인 LLM은 (i) 공간 · 기하 추론을 보이고, (ii) 새 지시로 일반화하며, (iii) 모호한 표현("더 빨리")에 맥락에 따라 정확한 값(예: 속도)을 정해 주는(즉, 행동 상식을 갖춘) 로봇 정책을 작성할 수 있습니다. 이 논문은 Code as Policies를 제시합니다. 이는 언어 모델이 생성한 프로그램(LMP)을 로봇 중심으로 정식화한 것으로, 반응형 정책(예: 임피던스 제어기)과 경유점 기반 정책(비전 기반 집어 놓기, 궤적 기반 제어)을 표현할 수 있으며, 여러 실제 로봇 플랫폼에서 시연했습니다. 이 방법의 핵심은 계층적 코드 생성(정의되지 않은 함수를 재귀적으로 정의하기)을 프롬프트로 유도하는 것으로, 이는 더 복잡한 코드를 작성할 수 있게 할 뿐 아니라 HumanEval[1] 벤치마크에서 문제의 39.8%를 풀어 최고 성능을 끌어올립니다. 코드와 영상은 code-as-policies.github.io 에서 볼 수 있습니다.

무엇을 풀었나

로봇이 말을 알아들으려면 단어를 실제 세계의 물체 · 지각 · 행동과 이어야 합니다. 이것을 그라운딩(grounding)이라고 합니다.

예전 방법은 두 갈래였습니다. 하나는 문장을 문법적으로 분석해 의미 표현을 뽑는 방식인데, 처음 보는 지시에 약했습니다. 다른 하나는 언어에서 행동까지 끝에서 끝까지(end-to-end) 학습하는 방식인데, 실제 로봇 데이터가 아주 많이 필요했습니다.

LLM이 나오자 SayCan 같은 연구가 LLM으로 "단계 계획"을 세우고, 미리 학습해 둔 기술(skill) 목록에서 하나씩 고르게 했습니다. 그런데 이 구조에서는 LLM이 지각-행동 피드백 루프에 직접 손을 댈 수 없습니다. 그래서 다음과 같은 일이 어렵습니다.

• "사과를 오렌지 위에 놓아" → "오렌지가 보이면 사과를 놓아"처럼 피드백 방식을 바꾸기
• "더 빨리 움직여", "더 세게 밀어" 같은 상식을 제어 값에 반영하기
• "사과를 조금 왼쪽으로" 같은 공간 관계를 이해하기

예를 들어 "콜라 캔을 조금 오른쪽으로"라는 지시에 계획자형 LLM은 "1. 집기 2. 조금 오른쪽으로 이동 3. 놓기"를 냅니다. 이것은 "조금 오른쪽으로 옮기기"라는 기술이 이미 있다고 가정합니다. 새 기술이 필요할 때마다 데이터를 모으고 다시 학습해야 하니, 데이터 부담이 기술 습득 쪽으로 옮겨 갔을 뿐입니다.

이 논문의 질문은 이것입니다. LLM을 기술 순서 고르기보다 더 깊은 곳, 즉 정책 논리와 제어까지 쓰게 할 수 있을까? 답은 "코드를 쓰게 하자"입니다.

핵심 아이디어

1. 언어 모델 프로그램(LMP) — 지시를 코드로 번역하기

한 문장 직관: 신입 개발자에게 사내 함수 목록(import 문)과 "이런 요청엔 이렇게 짰다"는 예시 몇 개를 보여 주면, 비슷한 새 요청도 그 함수들을 조합해 짜 오는 것과 같습니다(해설용 비유).

단계별 설명

1. 프롬프트에 힌트를 넣습니다. 어떤 API를 쓸 수 있는지 알려 주는 import 문과 타입 힌트입니다. 예: from utils import get_pos, put_first_on_second.
2. 프롬프트에 예시를 넣습니다. 자연어 지시를 주석(# ...)으로 쓰고, 바로 아래에 그 지시를 푸는 코드를 둡니다.
3. 새 지시를 주석 형식으로 끝에 붙입니다.
4. LLM이 이어지는 파이썬 코드를 토큰 단위로 생성합니다. 논문은 별도 언급이 없으면 OpenAI Codex code-davinci-002를 온도 0(탐욕적 디코딩) 으로 씁니다.
5. 생성된 코드를 로봇 쪽에서 실행합니다. 지시와 응답을 프롬프트에 계속 이어 붙이면 "방금 한 거 되돌려" 같은 이전 맥락 참조도 됩니다(LMP 세션).

논문은 LMP를 "언어 모델이 생성해 시스템에서 실행하는 모든 프로그램"으로 넓게 정의합니다. Code as Policies는 그중 (i) 지각 입력에 반응하고, (ii) 제어 기본 동작 API의 매개변수를 정하며, (iii) 로봇에서 바로 실행되는 LMP입니다.

수식 (해설용 정식화 — 논문에는 수식이 없어 이 글에서 정리한 것)

기호 풀이

핵심은 $\theta$를 전혀 학습하지 않는다는 점입니다. 바뀌는 것은 프롬프트 $P$뿐입니다.

숫자로 해 보기 (해설용 예 — 논문 수치 아님)

프롬프트 예시에 "보라색 그릇을 왼쪽으로 → get_pos('purple bowl') + [-0.3, 0]"이 있다고 합시다. 새 지시가 "빨간 블록을 조금 오른쪽으로"입니다.

1. LLM은 예시의 패턴을 따라 target_pos = get_pos('red block') + [0.1, 0]을 씁니다(논문에 실제로 나오는 생성 예입니다).
2. 빨간 블록이 $(0.20, 0.40)$에 있다면 목표는 $(0.20 + 0.1,\ 0.40) = (0.30, 0.40)$입니다.
3. "왼쪽으로"는 0.3, "조금"은 0.1로 크기를 스스로 조절했습니다. 예시에 "조금"이라는 말이 없었는데도 그렇습니다.

왜 이렇게 했나

자연어 계획 대신 코드를 출력하게 한 이유는, 코드가 순서 · 조건(if/else) · 반복(for/while) 같은 논리 구조와 정확한 숫자를 함께 담을 수 있기 때문입니다. 미리 학습한 기술 목록이 아니라 제어 API를 직접 조합하므로 "조금 오른쪽으로 옮기기" 같은 기술을 따로 학습할 필요가 없습니다.

2. 라이브러리와 이름 짓기 — 모델이 이미 아는 것을 빌려 쓰기

한 문장 직관: 계산기를 쓸 줄 아는 사람에게 암산을 시키지 않는 것처럼, 좌표 계산은 NumPy에 맡깁니다(해설용 비유).

단계별 설명

1. 서드파티 라이브러리: 코드 LLM은 학습 중에 NumPy · Shapely 같은 유명 라이브러리 사용법을 많이 봤습니다. 그래서 "가장 왼쪽 점", "중심", "가장 가까운 점"을 NumPy 한 줄로 씁니다.
2. 퍼스트파티 라이브러리: 로봇 회사 내부 API처럼 학습 데이터에 없는 함수도, 이름이 의미 있고 힌트 · 예시에 나오면 잘 씁니다.
3. 이름이 곧 설명서: 변수명 끝의 _np는 NumPy 배열이라는 비공식 타입 힌트입니다. get_obj_bbox_xyxy라는 이름만 보고 LLM은 반환값이 축 정렬 경계 상자의 최소 · 최대 xy 좌표라고 추론해 넓이 계산 코드를 맞게 짰습니다.

수식 (논문 예시 코드의 "가장 가까운 점")

NumPy로는 pts_np[np.argmin(np.sum((pts_np - pt_np)**2, axis=1))]입니다.

기호 풀이

• $\mathbf{p}_j$: 후보 점들(pts_np의 $j$번째 행)
• $\mathbf{q}$: 기준 점(pt_np)
• $k$: 좌표 축(2차원이면 x, y)
• $\arg\min_j$: 값을 가장 작게 만드는 $j$

숫자로 해 보기 (해설용 예)

후보 점 $(0,0),\ (1,2),\ (3,1)$, 기준 점 $(2,2)$라 합시다.

1. 차이: $(-2,-2),\ (-1,0),\ (1,-1)$
2. 제곱합: $8,\ 1,\ 2$
3. 가장 작은 값은 1, 즉 $j^{*}=1$ → 답 $(1,2)$

LLM이 이 세 단계를 "머릿속"에서 계산할 필요가 없습니다. 코드만 맞으면 파이썬이 정확히 계산합니다. 이 차이가 결과의 표 IV(코드 98% 대 생각의 사슬 58%)로 나타납니다.

왜 이렇게 했나

LLM은 "어느 쪽이 더 오른쪽인가" 같은 관계는 말로도 어느 정도 추론하지만, 여러 단계의 정밀한 수치 계산에서 자주 틀립니다. 계산을 인터프리터에 넘기면 LLM은 "어떤 계산을 할지"만 정하면 됩니다.

3. 계층적 코드 생성 — 없는 함수는 나중에 짓기

한 문장 직관: 큰 보고서를 쓸 때 목차와 "여기 표 하나"라는 자리만 먼저 잡고, 표는 나중에 채우는 방식입니다(해설용 비유).

단계별 설명

1. 상위 LMP가 코드를 생성합니다. 이때 아직 정의되지 않은 함수를 자유롭게 호출해도 됩니다. 예: get_objs_bigger_than_area_th(names, 0.2).
2. 생성된 코드의 추상 구문 트리(AST) 를 분석해, 현재 범위에 없는 함수 이름을 찾습니다.
3. 함수 생성 전용 LMP에 "# define function: get_objs_bigger_than_area_th(obj_names, bbox_area_th)."를 주고 몸체를 짜게 합니다.
4. 그 몸체 안에도 없는 함수(get_obj_bbox_area)가 있으면 같은 과정을 되풀이합니다. 깊이 우선으로 내려갑니다.
5. 만든 함수를 범위에 추가하고, 이후 LMP가 다시 쓸 수 있게 쌓아 둡니다. 시간이 갈수록 자기만의 라이브러리가 생깁니다.

수식 (해설용 — 재귀 구조를 식으로 쓴 것)

• $f$: 만들어야 할 함수의 이름 · 인자
• $\mathrm{LMP}_{\text{fgen}}(f)$: 함수 생성 LMP가 쓴 $f$의 몸체
• $\mathrm{Undef}(\cdot)$: 그 코드 안에서 호출하지만 아직 정의되지 않은 함수들의 집합
• 재귀는 $\mathrm{Undef}$가 빈 집합이 되면 멈춥니다.

숫자로 해 보기 (해설용 예)

지시: "넓이가 0.2보다 큰 블록만 골라 줘". 블록 A의 경계 상자가 $(x_1,y_1,x_2,y_2) = (0, 0, 0.5, 0.5)$, 블록 B가 $(0, 0, 0.4, 0.4)$라 합시다.

1. 상위 코드: get_objs_bigger_than_area_th(['A','B'], 0.2) → 정의 없음
2. 1단계 생성: [n for n in names if get_obj_bbox_area(n) > th] → get_obj_bbox_area 정의 없음
3. 2단계 생성: (x2 - x1) * (y2 - y1) → 더 이상 없는 함수 없음, 재귀 끝
4. 실행: A의 넓이 $0.5 \times 0.5 = 0.25 > 0.2$ (선택), B는 $0.4 \times 0.4 = 0.16$ (제외) → 답 ['A']

왜 이렇게 했나

모든 논리를 한 함수에 "평평하게" 몰아 쓰면 길고 여러 겹인 코드에서 LLM이 쉽게 틀립니다. 함수를 쪼개 각 부분을 따로 생성하면 읽기도 쉽고 정답률도 오릅니다. 논문은 설명적인 변수명을 쓰는 계층적 생성을 함수형 프로그래밍을 통한 생각의 사슬(chain of thought)의 변형으로 볼 수 있다고 말합니다.

4. 코드가 곧 정책 — 피드백 루프와 반응형 제어기

한 문장 직관: 내비게이션이 "500m 앞 우회전"을 한 번 말하고 끝나는 게 아니라, 계속 위치를 확인하며 다시 안내하는 것처럼, 코드 안의 while 문이 지각과 행동을 반복해서 잇습니다(해설용 비유).

단계별 설명

1. 인식 API(MDETR · ViLD 같은 개방 어휘 물체 검출기)가 물체 이름 · 위치 · 경계 상자를 돌려줍니다.
2. 코드가 그 값을 계산 · 비교합니다.
3. 결과로 제어 API의 매개변수(목표 위치, 속도)를 정합니다.
4. while 루프로 조건이 만족될 때까지 1~3을 반복합니다. 논문 예: "빨간 블록이 파란 그릇 왼쪽에 있는 동안 5cm씩 오른쪽으로" → while get_pos('red block')[0] < get_pos('blue bowl')[0]: .... 프롬프트 예시에 while 문이 없었는데도 이렇게 썼습니다.
5. 더 낮은 수준에서는 반응형 제어기 자체를 씁니다. 부록에서 CartPole 막대 세우기 PD 제어기와 끝단 임피던스 제어기를 제로샷으로 생성했습니다.

수식 (부록 F에서 LMP가 생성한 제어기 코드를 식으로 옮긴 것)

CartPole PD 제어:

끝단 임피던스 제어:

기호 풀이

논문은 이 임피던스 제어기가 PyBullet에서 UR5e를 움직이지만, 코리올리 힘과 중력 보상은 하지 않는 단순화된 형태라고 밝힙니다. 이득 이름에 _mat을 붙여야 행렬로, _x를 붙여야 관절이 아닌 끝단 이득으로 다뤘다고 합니다.

숫자로 해 보기 (해설용 예)

PD 제어: $\theta = 0.05$, $\dot\theta = -0.1$, $k_p = k_d = 1$이면 $u = 0.05 - 0.1 = -0.05 < 0$ → 방향 0(왼쪽).

피드백 루프: 빨간 블록 x = 0.10, 파란 그릇 x = 0.22, 한 번에 0.05씩 이동.

1. 0.10 < 0.22 → 이동 후 0.15
2. 0.15 < 0.22 → 0.20
3. 0.20 < 0.22 → 0.25
4. 0.25 < 0.22 아님 → 멈춤. 총 3번 움직였습니다.

왜 이렇게 했나

정책을 신경망 대신 코드로 두면 해석할 수 있습니다. 사람이 읽고 고치고 재사용할 수 있습니다. 또 인식 모델이나 제어 알고리즘이 좋아지면 그대로 LMP 정책의 능력도 올라갑니다. 대신 실행 전 안전 점검을 둡니다. 코드에 import 문, __로 시작하는 특수 변수, exec · eval 호출이 없는지 확인한 뒤, 쓸 수 있는 API만 담은 globals와 빈 locals로 파이썬 exec를 호출합니다.

5. 처리 흐름

123456789101112flowchart LR
    U["사용자 지시<br/>(주석 형식)"] --> P["프롬프트 조립<br/>힌트 + 예시 + 이전 세션"]
    P --> L["코드 작성 LLM<br/>온도 0"]
    L --> A["AST 분석<br/>정의 안 된 함수 찾기"]
    A -->|"있음"| F["함수 생성 LMP<br/>깊이 우선 재귀"]
    F --> A
    A -->|"없음"| S["안전 점검<br/>import · __ · exec/eval 금지"]
    S --> E["exec 실행"]
    E --> V["인식 API<br/>MDETR · ViLD"]
    V --> E
    E --> C["제어 API<br/>집어 놓기 · 속도 · 궤적"]
    C --> R["로봇 동작"]

결과

모든 수치는 논문이 보고한 값입니다.

RoboCodeGen (로봇 주제 함수 생성 37문제, 사람이 쓴 단위 테스트 통과율 %, 논문 표 I)

• 코드 전용 모델(Codex)이 대체로 낫고, 같은 계열에서는 큰 모델이 낫습니다(규모 법칙).
• 계층적 생성이 모든 모델에서 더 좋았습니다.
• 다섯 가지 일반화 유형 중 계층적 생성은 생산성(Productivity), 즉 예시보다 더 길고 층이 많은 코드가 필요한 경우에 가장 크게 도움이 됐습니다. 다만 이 향상은 두 davinci 모델에서만 나타나고 cushman에서는 없었습니다. 논문은 일정 수준의 코드 능력이 먼저 있어야 계층적 생성이 효과를 낸다고 해석합니다.

HumanEval (일반 코딩 문제 164개, 통과율 %, 논문 표 II · V, code-davinci-002)

• P@N은 온도 0.8로 N개를 뽑았을 때의 정답 기준입니다. 프롬프트에는 예시 2개만 넣었고, 계층적 프롬프트의 차이는 평균을 직접 계산하는 대신 아직 없는 get_mean을 부르는 것뿐이었습니다.
• 164문제 중 6.5%에서 실제로 계층적 생성이 일어났고, 그 문제들에서 평평한 두 방식은 44%, 계층적 방식은 56%를 맞혔습니다.
• 논문은 여러 개를 뽑아 고르는 방식은 단위 테스트 없이 바로 행동해야 하는 LMP에 실용적이지 않으므로, LMP에서는 항상 온도 0을 쓴다고 밝힙니다.

코드 추론 대 자연어 추론 (정답률 %, 논문 표 IV)

위치 고르기는 모든 좌표가 정답에서 1cm 안이면 정답으로 셌습니다.

시뮬레이션 탁상 조작 (과제당 50회 시도 성공률 %, 논문 표 III)

UR5e 팔과 Robotiq 2F85 그리퍼로 색깔 블록 10개 · 그릇 10개를 다룹니다. 기존 장기 과제 8개와 새로 만든 공간 · 기하 과제 6개가 있습니다. SA/UA는 본 · 못 본 속성, SI/UI는 본 · 못 본 지시입니다. CLIPort는 시연 3만 개로 모방 학습한 정책입니다.

• 본 속성 · 지시에서는 CaP가 과제마다 시연 1개씩만 프롬프트로 받고도 지도 학습한 CLIPort와 비슷하게 겨룹니다.
• 못 본 속성에서는 CLIPort가 크게 떨어지고, LLM 기반 방법은 비슷한 성능을 유지합니다.
• 자연어 계획자는 정밀한 수치 계산이 필요한 공간 · 기하 과제에는 적용할 수 없습니다.

실제 로봇 시연 (정량 평가 없음)

• UR5e 팔로 화이트보드에 도형 그리기(경유점 생성, MDETR 인식)
• UR5e 팔 + 흡착 그리퍼 + 손목 Intel Realsense D435 카메라로 장난감 집어 놓기
• 이동 베이스 + 7자유도 팔 로봇(Everyday Robots)으로 실제 주방에서 이동 · 조작(ViLD 인식)

왜 중요한가 · 이후 영향

• LLM의 역할을 계획에서 프로그래밍으로 넓혔습니다. 기술 이름을 고르는 데서 멈추지 않고 조건 · 반복 · 수치를 담은 정책 자체를 씁니다.
• 추가 데이터 · 학습이 없습니다. 새 로봇에는 그 로봇의 인식 · 제어 API를 힌트로 주면 됩니다. 논문은 같은 과제를 쓸 수 있는 API에 따라 다르게 수행하는 "교차 구현(cross-embodied)" 계획도 보이지만, 아직 불안정하다고 덧붙입니다.
• 해석 가능한 정책. 실패하면 코드를 읽고 어디가 틀렸는지 볼 수 있습니다.
• (이 글의 해설, 원문 밖 내용) 이후 VoxPoser처럼 LLM이 코드를 써서 로봇 행동을 구성하는 연구들이 이 흐름을 이어 갔습니다.

한계 · 주의할 점

• 인식 API가 설명할 수 있는 것까지만 됩니다. 논문 예: 궤적이 "울퉁불퉁한지", "더 C자 모양인지"를 판단해 주는 시각-언어 모델은 아직 없습니다.
• 제어 기본 동작이 정해져 있어야 합니다. 프롬프트가 넘치지 않게 조절할 수 있는 매개변수는 몇 개뿐입니다.
• 예시와 수준이 다른 지시에 약합니다. 예시보다 훨씬 길고 복잡하거나 추상 수준이 다른 지시("블록으로 집을 지어")는 어렵습니다.
• 실행 가능성을 따지지 않습니다. 모든 지시가 실행 가능하다고 가정하며, 응답이 맞는지 미리 알 수 없습니다.
• 복잡한 제어는 아직입니다. 생성한 제어기는 단순하며, 실행 결과를 보고 이득을 조정하는 기능은 없습니다.
• 현실 실패의 상당수는 검출 오류입니다. MDETR이 "block"보다 "square"라는 단어로 블록을 더 잘 찾는 등 시각-언어 모델에도 프롬프트 조정이 필요했습니다.

이어서 읽을 것

• 앞: SayCan — LLM이 기술 목록에서 고르는 계획자 방식, 이 논문이 넘어서려는 기준
• 앞: 생각의 사슬 — 표 IV에서 비교한 단계별 자연어 추론
• 앞: ReAct — 추론과 행동(도구 호출)을 번갈아 하는 LLM 에이전트
• 뒤: VoxPoser — LLM이 코드로 3차원 가치 지도를 만들어 궤적을 계획
• 뒤: RT-1 — 반대 방향, 대규모 시연으로 학습한 끝에서 끝까지 로봇 정책
• 뒤: PaLM-E — 시각 입력을 언어 모델에 직접 넣는 몸을 가진 멀티모달 모델
• 기초: Modern Robotics — 야코비안 · 임피던스 제어 등 로봇 제어 기초 (이 섹션 105번 항목)

용어 정리

스스로 점검

1. SayCan 같은 "계획자형 LLM"과 Code as Policies의 가장 큰 차이는 무엇인가요? 답: 계획자형은 미리 학습된 기술 이름을 순서대로 고를 뿐이라, "조금 오른쪽으로" 같은 새 동작에는 새 기술 학습이 필요합니다. CaP는 인식 결과를 계산하고 제어 API의 매개변수를 직접 정하는 코드를 써서, 피드백 루프와 정밀한 수치를 추가 학습 없이 표현합니다.

2. 계층적 코드 생성은 어떻게 동작하고, 어떤 경우에 가장 도움이 됐나요? 답: 생성된 코드의 AST에서 정의되지 않은 함수를 찾아 함수 생성 LMP로 몸체를 짓고, 그 안에서도 같은 일을 깊이 우선으로 반복합니다. 예시보다 길고 층이 많은 코드가 필요한 생산성 일반화에서 가장 크게 도움이 됐고, HumanEval P@1을 34.9%에서 39.8%로 올렸습니다.

3. 공간 추론 과제에서 코드가 생각의 사슬보다 정확했던 이유는 무엇인가요? 답: 생각의 사슬은 관계 · 순서 추론은 하지만 정밀한 다단계 수치 계산에서 틀립니다. 코드는 계산을 파이썬과 NumPy에 맡기므로, LLM은 어떤 계산을 할지만 정하면 됩니다. 표 IV에서 전체 정답률이 생각의 사슬 58%, 코드 98%였습니다.

다음에 볼 것

이 글을 이해했다면 이어서 보면 좋은 항목입니다.

• RT-1: 실제 로봇 제어를 위한 로보틱스 트랜스포머 — 시연 13만 건으로 학습한 트랜스포머가 700여 개 지시를 97%로 수행하고 새 상황에도 일반화합니다

출처

• 원문: arxiv.org/abs/2209.07753 (2022 · Jacky Liang 외)