에이전트에게 기하학적 계산을 맡기지 마세요

나는 에이전트(agent)에게 한 줌의 포스트잇을 연결선이 있는 마인드맵으로 변환해 달라고 요청했습니다. 38초 후, 에이전트는 마인드맵을 구축했습니다. 중앙에 허브가 있고, 그 주변에 5개의 가지가 있으며, 허브에서 각 가지로 향하는 화살표가 있는 형태였습니다. 5개의 가지는 완벽한 원형 위에 일정한 간격으로 배치되어 있었고, 첫 번째 가지는 정중앙 상단에 위치해 있었습니다. 내가 이야기하고 싶은 것은 일어나지 않은 부분입니다. 에이전트는 그 원을 만들기 위해 단 하나의 좌표(coordinate)도 계산하지 않았습니다.

그 차이가 바로 핵심 업무입니다. 에이전트가 작동하는 도구를 만들 때, 에이전트를 더 똑똑하게 만들고 싶은 유혹에 빠지기 쉽습니다. 더 긴 프롬프트(prompt), 좋은 레이아웃의 더 많은 예시, 간격에 대한 몇 가지 규칙 등을 추가하는 식이죠. 그것은 잘못된 레버(lever)입니다. 올바른 레버는 에이전트가 호출할 수 있는 결정론적 프리미티브(deterministic primitive)입니다. 그래야 구조가 근사치(approximated)가 아닌 정확하고 재현 가능한(reproducible) 형태로 나옵니다. 에이전트는 의도(intent)를 제공하고, 도구는 정밀도(precision)를 제공합니다. 당신의 작업은 이 둘을 연결한 다음, 뒤로 물러나는 것입니다.

모델에게 수학을 맡겼을 때의 모습

언어 모델(language model)에게 빈 캔버스와 5개의 상자로 이루어진 원을 만들어 달라는 요청을 주면, 모델은 기쁘게 5쌍의 x와 y 좌표를 내뱉을 것입니다. 그것들은 그럴싸해 보일 것입니다. 하지만 그것들은 부동 소수점(floating-point)을 눈대중으로 맞출 때 항상 발생하는 특유의 방식으로 틀리게 됩니다. 간격은 어긋나고, 반지름은 방황하며, 5개 중 2개는 서로 너무 가까워지고, 다음 주에 같은 프롬프트를 사용하면 원에 가까운 또 다른 형태가 생성됩니다. 모델은 상자들이 원 위에 있어야 한다는 '사실'을 결정하는 데는 능숙합니다. 하지만 상자들을 그 위치에 배치하는 삼각법(trigonometry)에는 서툽니다. 왜냐하면 모델은 삼각법을 수행하는 것이 아니라, 삼각법처럼 읽히는 숫자를 예측(predicting)하고 있기 때문입니다.

더 많은 토큰을 사용하여 이 문제를 임시방편으로 덮을 수 있습니다. 단계별로 추론(reason step by step)하도록 요청하거나, 공식을 제공하거나, 중심점과 반지름을 알려주는 식입니다. 이제 당신은 모델이 매번 0이 아닌 오차율(non-zero error rate)을 가진 채로, 산문(prose)을 통해 사인(sine)과 코사인(cosine)을 느릿느릿 실행하도록 비용을 지불하고 있는 것입니다. 출력은 여전히 재현 가능(reproducible)하지 않습니다. 왜냐하면 다음 요청이 동일한 산술 연산을 처음부터 다시 도출하고 다르게 반올림하기 때문입니다. 당신은 확률적 시스템(probabilistic system)에게 계산기(calculator)를 흉내 내도록 가르치는 데 당신의 영리함 예산(cleverness budget)을 낭비한 것입니다.

모델이 절대 건드려서는 안 되는 부분을 프리미티브(primitive)가 수행합니다

대안은 에이전트에게 하나의 도구(tool)를 건네주는 것입니다: 이 요소 ID(element ids)들을 원형으로 배치하라는 것입니다. 순수 코드인 이 도구는 ID를 가져와 실제 수학을 사용하여 링(ring) 위의 중심점을 계산하고, 정확한 위치를 작성합니다. 에이전트는 각도(angle)를 전혀 보지 못합니다. 에이전트는 요소의 이름을 지정하고, 원하는 모양의 이름을 지정할 뿐입니다. 그리드(Grid), 행(row), 열(column), 원(circle)과 같이 말이죠. 기하학(geometry)은 매번 동일한 답을 반환하는 함수에 의해 결정됩니다.

에이전트가 지름길을 택하지 않고 도구를 사용했다는 것을 제가 어떻게 아는지 알려드리겠습니다. 원형 레이아웃(circle layout)은 시작 각도가 12시 방향인 마이너스 90도이기 때문에 기본적으로 첫 번째 요소를 상단에 배치합니다. 마인드맵에서 에이전트가 우연히 가장 먼저 추가한 브랜치(branch)는 정확히 상단 중앙에 위치했습니다. 만약 모델이 좌표를 추측하고 있었다면, 첫 번째 브랜치는 그럴듯한 숫자가 가리키는 아무 곳에나 놓였을 것이며, 그곳이 정확히 상단일 확률은 거의 없습니다. 상단 배치는 지문(fingerprint)과 같습니다. 이는 프리미티브(primitive)의 결정론적(deterministic) 기본값이 드러난 것이며, 구조가 모델에 의해 서술된 것이 아니라 코드로 계산되었다는 증거입니다.

커넥터(connectors)들은 반대편 관점에서도 동일한 점을 시사합니다. 에이전트는 두 좌표 사이의 선을 그리는 대신, 두 끝점의 이름을 지정함으로써 허브(hub)에서 각 분기(branch)로 화살표를 그렸습니다. 화살표는 요소들에 결합(bind)됩니다. 나중에 링(ring)이 움직일 때, 화살표들은 스스로 경로를 재설정(re-route)합니다. 왜냐하면 화살표는 결코 위치에 관한 것이 아니었기 때문입니다. 화살표는 관계(relationships)에 관한 것이었으며, 도구(tool)가 픽셀이 어디로 갈지를 처리하는 동안 에이전트가 표현해야 할 정확한 대상은 바로 이 관계입니다.

일반적인 형태

이것은 사실 캔버스(canvases)에 관한 것이 아닙니다. 에이전트가 제어하는 모든 것에서 에이전트와 도구 사이에 어디에 선을 그을 것인가에 관한 문제입니다. 에이전트가 수행하는 작업들을 살펴보고 분류해 보십시오. 어떤 것이 판단(judgment)이고, 어떤 것이 판단의 탈을 쓴 산술(arithmetic)입니까? 링 위에 배치하는 것은 산술입니다. 박스 열을 공통된 가장자리에 맞추거나, 간격을 균등하게 배분하거나, 그리드(grid)에 스냅(snapping)하거나, 두 앵커(anchors) 사이에 선을 연결하는 것도 마찬가지입니다. 이 모든 작업에는 함수(function)가 계산할 수 있는 단 하나의 정답이 존재하며, 모델(model)은 이를 근사(approximate)할 수 있을 뿐입니다.

이러한 작업들을 각각 결정론적 기본 단위(deterministic primitive)로 밀어 넣으면, 에이전트는 동시에 더 짧아지고, 저렴해지며, 더 신뢰할 수 있게 됩니다. 에이전트의 프롬프트(prompt)는 더 이상 간격 규칙을 담지 않아도 됩니다. 에이전트의 출력(output)은 실행 시마다 표류(drifting)하지 않습니다. 에이전트의 역할은 자신이 진정으로 잘하는 부분, 즉 상황을 읽고 의도(intent)를 선택하는 부분으로 축소됩니다. 이것들을 주제별로 클러스터링(cluster)하십시오. 이를 2x2 매트릭스(matrix)로 만드십시오. 이것들을 흐름(flow)으로 배치하십시오. 에이전트는 호출(call)의 순간에 어떤 구성(composition)이 필요한지 결정하고, 기본 단위(primitives)들이 그 구성을 정확하게 만듭니다.

따라서 에이전트가 사용하도록 당신이 만들고 있는 모든 도구에 대해 제가 던질 질문은, 다소 투박한 질문입니다. 현재 에이전트가 함수를 호출하는 대신 토큰(tokens)을 사용하여 수동으로 수행하고 있는 작업 중 무엇이 있습니까? 찾아낸 작업 하나하나가 에이전트가 결코 요청받아서는 안 되었을 기하학(geometry)을 수행하고 있는 지점입니다. 에이전트로부터 기하학을 가져가십시오. 대신 나침반을 주고, 그것이 방향을 가리키게 하십시오.

실제 사례로 사용된 것은 truffleagent.com/easel에서 운영되는 에이전트 기반 캔버스인 Easel입니다. 여기서 설명하는 레이아웃 프리미티브 (layout primitive)는 원 (circle), 그리드 (grid), 행 (row), 열 (column) 모드를 갖춘 arrange 도구입니다. 이는 제가 운영하는 플랫폼이자 github.com/ghostwright/phantom에서 오픈 소스로 제공되는 Phantom을 기반으로 구축되었습니다.