빠른 LLM이 가르쳐준 '가정(Assumptions)'에 대하여

복잡한 작업에 저렴하고 빠른 LLM을 한 시간 동안 돌려보았습니다. 실패하지 않았습니다.

대부분의 사람들은 성능이 낮은 모델이 긴 작업에서 실패한다고 생각합니다. 중간에 흐름을 놓치거나 포기해 버린다고 말이죠. 하지만 이 모델은 궤도를 유지했습니다. 제가 산출물(deliverables) 목록을 제공했기 때문입니다.

저는 이 산출물 목록이 정확성을 높여줄 것이라고 생각했습니다. 틀렸습니다.

한 연구에 따르면 산출물은 모델을 더 정확하게 만드는 것이 아니라, 더 검증 가능하게(verifiable) 만듭니다. 모델이 자신의 작업 과정을 더 잘 기록하게 하여, 사용자가 확인할 수 있는 증거를 남기게 하는 것입니다.

소프트웨어에는 두 가지 유형의 오류가 있습니다:

• 실행 오류(Execution errors): 쉼표를 잘못 찍거나 엣지 케이스를 놓치는 경우입니다. 이는 테스트와 린팅(linting)으로 해결할 수 있습니다.
• 가정 오류(Assumption errors): 경계선을 잘못된 위치에 설정하는 경우입니다. 이는 훨씬 고치기 어렵습니다.

프로세스는 실행 오류를 해결하는 데 도움이 됩니다. 하지만 가정 오류를 해결해주지는 않습니다. 만약 당신과 모델이 같은 사각지대(blind spot)를 공유하고 있다면, 당신의 검토 또한 실패할 것입니다.

AI는 이러한 오류의 계산법을 바꿉니다.

과거에는 사람이 천천히 실수를 저질렀습니다. 덕분에 알아차릴 시간이 있었죠. 하지만 이제 AI는 빠르게 실수를 저지릅니다. 모델은 당신이 알아차리기도 전에 단 하나의 잘못된 가정을 바탕으로 3시간 분량의 완벽해 보이는 코드를 쌓아 올릴 수 있습니다.

모델이 유능해 보일수록 당신은 더 신뢰하게 됩니다. 더 오래 실행하도록 내버려 두고, 확인하는 횟수도 줄입니다. 이것은 함정입니다. 잘못된 가정은 경고등을 켜지 않습니다. 너무 늦을 때까지 그저 진전이 있는 것처럼 보일 뿐입니다.

업계는 더 많은 프로세스로 이를 해결하려 합니다. 더 많은 스펙(specs)과 계획을 추가합니다. 이는 그저 오버헤드(overhead)를 늘릴 뿐입니다. 가정의 문제를 해결하기 위해 실행 도구를 사용하는 셈입니다.

우리는 모델이 얼마나 자주 맞히는지를 측정하는 것을 멈춰야 합니다. 대신, 잘못된 가정이 발견되기 전까지 얼마나 오래 지속되는지를 측정해야 합니다.

운영 환경에서는 이를 MTTD: Mean Time To Detect(평균 탐지 시간)라고 부릅니다.

모든 오류를 막을 수는 없습니다. 우리가 할 수 있는 것은 오류를 수정하는 비용을 낮추는 것뿐입니다. 이를 위해서는 오류를 조기에 발견해야 합니다.

목표는 단순히 더 똑똑한 모델을 찾는 것이 아닙니다. 목표는 당신이 여전히 통제권을 유지해야 하는 지점이 어디인지 결정하는 것입니다.

Source: https://dev.to/g_correa/what-a-fast-llm-taught-me-about-assumptions-oe

Optional learning community: https://t.me/GyaanSetuAi