Operator: 답변만으로는 충분하지 않을 때
요약
Operator는 Underpass Kernel의 메모리 프로토콜(KMP)을 정밀하게 운용하기 위해 설계된 컴팩트한 특화 모델입니다. 범용 모델의 한계를 극복하고, 메모리 상태를 기반으로 검증 가능하며 감사 가능한 액션을 실행하는 에이전트 보조 역할을 수행합니다.
핵심 포인트
- KMP 프로토콜 운용을 위한 컴팩트 모델 개발
- 범용 모델의 추론 관성을 극복하고 정밀한 액션 실행 지향
- 메인 모델의 업무를 분담하여 메모리 운용의 정확도 향상
- 검증 가능하고 감사 가능한 도구 호출(tool_call) 생성
Operator는 Underpass Kernel의 메모리 프로토콜인 **Kernel Memory Protocol (KMP)**를 운용하기 위해 제가 훈련시키고 있는 컴팩트한 모델입니다.
KMP는 외부 표준이 아닙니다. 이는 메모리를 읽고, 그 안을 이동하며, 검증 가능한 방식으로 새로운 정보를 기록하기 위해 제가 Underpass 내부에서 정의하고 있는 계약(contract)입니다.
Operator는 KMP를 사용하기 어렵기 때문에 탄생한 것이 아닙니다. KMP는 MCP 또는 타입이 지정된 API(typed API)를 통해 에이전트, 인간, 그리고 도구들이 사용할 수 있도록 설계되었습니다.
Operator는 구체적인 관찰로부터 탄생했습니다. LongMemEval 또는 MemoryArena와 같은 벤치마크에서 GPT-4o는 질문을 이해할 수는 있었지만, 그럼에도 불구하고 작업(operation)에는 실패할 수 있었습니다. MCP 도구를 선택하고, 정확한 참조를 복사하며, 커서(cursor)를 준수하고, 예산을 유지하거나 유효한 증거와 함께 관계를 작성하는 것은 부차적인 세부 사항이 아닙니다. 그것들은 결과의 일부입니다.
또한 범용 모델(general-purpose models)에서 나타나는 전형적인 관성, 즉 질문을 다시 생각하려는 경향이 나타납니다. Operator는 그 반대를 추구합니다. 가시적인 상태(visible state)를 취하고 다음 KMP 액션을 방출하는 것입니다.
이것이 제가 측정하고자 하는 가설입니다: 컴팩트한 모델이 해당 계약을 운용하는 엄격한 부분을 학습할 수 있는가 하는 점입니다.
시스템이 프로토콜이나 API에 따라 작동할 때, 거의 정답에 가까운 액션은 도움이 되지 않습니다. 호출(call)은 반드시 유효해야 합니다.
그 지점에 Operator가 등장합니다.
아이디어
아이디어는 간단합니다: 에이전트 시스템의 모든 결정이 반드시 개방형 추론(open reasoning)일 필요는 없다는 것입니다.
메인 모델은 작업을 이해하고, 증거를 해석하며, 최종 답변을 생성할 수 있습니다. Operator는 더 좁은 영역을 차지합니다: 가시적인 상태로부터 실행하기에 적합한 다음 KMP 액션이 무엇인지 결정합니다.
Operator는 메인 모델을 대체하는 것이 아닙니다. 메인 모델로부터 구체적인 업무의 일부, 즉 까다로운 시나리오에서 정밀하게 메모리를 운용하는 업무를 덜어주는 것입니다.
중요한 점은 이러한 운용이 자유로운 답변 내에서의 직관이 아니게 된다는 것입니다. 그것은 검증 가능하고, 훈련 가능하며, 감사 가능한(auditable) 액션이 됩니다.
Operator란 무엇인가
Operator는 다음과 같습니다:
- KMP를 조작하는 데 특화된 컴팩트한 모델 (compact model);
- 가시적인 메모리 상태(visible state of memory)로부터 다음 액션을 예측하는 예측기 (predictor);
- 참조(references), 커서(cursors), 허용된 도구(permitted tools), 예산(budget), 차원(dimensions) 및 이전 관찰 사항(observations)과 함께 작동하는 구성 요소;
- 제한된 액션(bounded actions)의 발행자:
tool_call,prepared_tool_call,stop또는escalate; - 실험실 시뮬레이션이 아닌 실제 MCP/KMP 계약(contract)에 대해 훈련된 모델.
발행할 수 있는 도구(tools)에는 다음이 포함됩니다:
kernel_ingest;kernel_write_memory;kernel_wake;kernel_ask;kernel_goto;kernel_near;kernel_rewind;kernel_forward;kernel_trace;kernel_inspect.
무엇이 아닌가
Operator는 다음과 같은 것이 아닙니다:
- Underpass Kernel;
- KMP;
- 질의응답(question-answer) 모델;
- 자율 에이전트 (autonomous agent);
- 일반 추론기 (general reasoner);
- 독자(reader)의 대체재;
- 메모리의 최종 의미를 결정하는 주체;
- 벤치마크를 암기하기 위한 임시방편(ad hoc) 솔루션;
- 벡터 데이터베이스 (vector database).
또한 KMP를 사용하기 위해 반드시 필요한 레이어도 아닙니다. 유능한 모델은 MCP를 통해 직접 KMP를 조작할 수 있습니다.
Operator가 무엇을 보고 무엇을 발행하는가
Operator는 문제의 모든 것을 보지 않습니다. 그것이 핵심입니다.
Operator의 세계는 메인 모델의 세계보다 더 제한적입니다. 처음부터 해석하기 위해 전체 대화를 전달받지 않습니다. 대신 구조화된 상태(structured state), 즉 다음 단계를 결정하는 데 필요한 메모리 및 계약의 일부를 전달받습니다.
이 상태에는 운영 목표(operational goal), 알려진 참조, 커서, 차원, 허용된 도구, 남은 예산 및 이전 관찰 사항이 포함될 수 있습니다.
모든 것의 의미를 결정할 필요는 없습니다. 지금 무엇을 해야 할지를 결정해야 합니다.
이를 통해 단 하나의 액션을 생성합니다. 본질적으로 축소된 실제 샘플은 다음과 같습니다:
가시적 상태 (VISIBLE STATE)
목표: ref_0001 주변 확장
모드: 읽기 (read)
...
출력은 설명이 아닙니다. 사용자에 대한 답변도 아닙니다. 그것은 액션입니다.
KMP와 어떻게 결합되는가
KMP가 계약 (contract)입니다.
MCP는 에이전트(agent)를 위한 도구(tools)로서 해당 계약을 노출하는 방식입니다.
Operator는 단지 다음 행동을 제안할 뿐입니다.
Operator는 별도의 프라이빗 API를 가지고 있지 않습니다. Underpass Kernel의 뒤편에서 몰래 동작하지도 않습니다. MCP를 통해 어떤 에이전트라도 사용할 법한 동일한 계약에 기반하여 행동 (actions)을 발행합니다.
가시적 상태 (visible state) + 목표 (goal) + 예산 (budget)
-> Operator
-> KMP/MCP 행동 (action)
...
학습 방법
Operator는 최종적인 질문과 답변으로 학습되지 않습니다. 운영 결정 (operational decisions)을 통해 학습됩니다.
학습은 운영 궤적 (operation trajectories)으로부터 시작됩니다:
가시적 상태 (visible state) -> 기대되는 행동 (expected action)
가시적 상태는 Operator가 해당 단계에서 사용할 수 있는 메모리의 부분입니다: 운영 목표, 알려진 참조 (references), 커서 (cursors), 허용된 도구 (tools), 예산 (budget) 및 이전 관찰 사항 (observations).
기대되는 행동은 해당 상태에 대한 올바른 결정입니다: 참조를 검사하거나, 시간 창 (temporal window)을 확장하거나, 충분한 증거가 확보되었으므로 중단하거나, 개방형 추론 (open reasoning)이 필요하므로 에스컬레이션(escalate)하거나, 준비된 쓰기 (write)를 발행하는 것 등입니다.
각 궤적은 세 개의 메시지를 가진 하나의 SFT (Supervised Fine-Tuning) 행으로 변환됩니다:
system -> MCP/KMP 계약, 허용된 도구 및 출력 규칙
user -> 메모리의 가시적 상태 (visible state)
assistant -> 엄격한 JSON 형식의 기대되는 행동 (expected action)
그 후, 해당 형식을 바탕으로 Qwen/Qwen2.5-0.5B-Instruct 모델을 LoRA SFT를 통해 미세 조정 (fine-tuning)합니다. Qwen은 벤치마크 (benchmark)에 답하는 법을 배우는 것이 아닙니다. 작업을 처음부터 다시 해결하지 않는 법과, 자신이 보고 있는 상태로부터 유효한 다음 KMP 행동을 발행하는 법을 배웁니다.
LoRA를 사용하면 모델 전체를 재학습시키지 않고도 이러한 조정을 수행할 수 있습니다. Qwen의 베이스 모델은 동결 (frozen)된 상태로 유지되며, 일부 레이어 위에 가벼운 어댑터 (adapters)를 학습시킵니다. 이 어댑터들이 가시적 상태를 읽고, 계약을 준수하며, 올바른 JSON을 발행하는 KMP의 운영 패턴을 학습합니다.
이러한 학습을 측정 가능하게 만들기 위해, 데이터셋 (dataset)은 매우 엄격하게 제어되어야 합니다:
- 모델에게 보이는 참조(references)는
ref_0001,ref_0002,about_0001과 같이 불투명(opaque)해야 합니다; user는 벤치마크의 기대 답변, 목표 행동(target action), 숨겨진 메모리(hidden memory), 또는 모델이 보아서는 안 되는 도구 출력(tool outputs)을 포함해서는 안 됩니다;- 시스템 프롬프트(system prompt)에는 실제 MCP/KMP 스키마(schema)가 포함되어야 합니다;
- 학습 프롬프트(training prompt)와 서비스 프롬프트(serving prompt)는 동일해야 합니다;
- 중복된 행이나 모델에게 보이는 충돌(collisions)이 있는 행은 거부됩니다;
- 각 행동(action)은 학습에 들어가기 전 계약(contract)에 따라 검증됩니다.
이러한 규칙이 없다면, 평가 결과는 더 이상 Operator를 측정하는 것이 아니게 됩니다. 데이터 유출(data leakage), 학습과 서비스 간의 괴리(divergence), 또는 도메인 이름의 암기(memorization)를 측정하고 있을 수도 있습니다.
평가 방법
학습 후, LoRA 어댑터(adapter)를 평가 세트(evaluation set)에 실행합니다.
각 행에 대해, Operator는 가시적인 상태(visible state)를 전달받고 단 하나의 행동을 생성해야 합니다. 이것이 일반적인 LLM의 자유로운 답변(free-form response)과의 차이점입니다. 여기서는 출력을 검증할 수 있습니다.
프로세스는 predictions.jsonl과 summary.json을 생성합니다. 그런 다음 평가기(evaluator)가 각 예측(prediction)을 기대되는 행동(expected action)과 비교합니다.
주요 지표(metrics)는 다음과 같습니다:
- 파싱 (parsing): 출력이 기대되는 형태의 유효한 JSON인지 여부;
- 올바른 도구 (correct tool): 기대되는 도구를 선택했는지 여부;
- 유효한 계약 (valid contract): 행동이 파싱되며 최소 규칙을 준수하는지 여부;
- 정확한 인자 (exact arguments): 참조(references), 커서(cursors), 제한(limits), 필드(fields)가 일치하는지 여부;
- 계약 커버리지 (contract coverage): 선언된 프로필이 명시된 내용을 충족하는지 여부;
- 실제 리플레이 (real replay): MCP를 통해 Underpass Kernel에서 행동이 실제로 실행되는지 여부.
마지막 지표는 자기기만(self-deception)을 방지하는 지표입니다. JSON이 올바르게 보일지라도 실제 커널(kernel)에서는 실패할 수 있습니다. 만약 거기서 실패한다면, 그 행동은 쓸모가 없는 것입니다.
제가 찾고 있는 발표 가능한 주장(publishable claim)은 다음과 같습니다:
Operator는 가시적인 메모리 상태로부터 Kernel Memory Protocol (KMP)의 제한된 행동을 엄격한 계약 (strict contract) 및 MCP를 통한 Underpass Kernel에 대한 실제 리플레이 (replay)와 함께 예측합니다.
왜 Qwen 0.5B인가
Qwen 0.5B는 Operator의 가설, 즉 오픈 모델을 좁고 검증 가능한 작업에 특화시키는 전략에 부합합니다.
Operator는 에세이를 쓰거나 전체 장애(incident)를 해결할 필요가 없습니다. 대신 다음을 수행해야 합니다:
- 구조화된 상태를 살펴보기;
- 유한한 목록에서 행동을 선택하기;
- 유효한 논거를 구축하기;
- 중단하거나 확장하기.
이것이 Qwen이 좋은 기반이 되는 이유입니다:
- 오픈 모델이며 독점적인 API에 의존하지 않고 학습할 수 있습니다;
- 지시사항을 따르고 구조화된 출력 (structured outputs)을 생성하도록 준비되어 있습니다;
- 실험을 인프라 문제로 만들지 않고도 LoRA로 미세 조정 (fine-tuning)할 수 있을 만큼 충분히 컴팩트합니다.
저는 Operator가 범용 모델보다 더 똑똑하다는 것을 증명하려는 것이 아닙니다. 오픈 모델이자 컴팩트한 모델이 엄격한 계약을 운영하는 법을 배울 수 있는지 확인하고자 합니다.
평가를 통해 배운 점
평가 또한 기만적일 수 있습니다.
평가자는 너무 유사한 행동을 수용할 수 있습니다. 만약 평가자가 Stop(reason=NoCandidate)를 기대했는데, 단지 둘 다 stop이라는 이유로 Stop(reason=AnswerReady)를 수용한다면, 겉보기 정확도 (apparent accuracy)는 올라가지만 의미론적 (semantics)으로는 틀린 것이 됩니다.
커서 (cursors)에서도 같은 일이 발생할 수 있습니다. 도구는 올바를 수 있지만 커서가 틀릴 수 있습니다. KMP에서 이것은 단순한 디테일이 아닙니다. 행동 자체를 바꿔버립니다.
또 다른 가능한 오류는 모델에게 보아서는 안 될 정보, 즉 최종 답변, 미래의 참조, 목표 세션 또는 도메인 이름을 가르치는 것입니다.
그렇기 때문에 정확도를 논하기 전에 계약 (contract)에 대해 먼저 이야기해야 합니다.
현재 상태
파이프라인은 이미 존재합니다: SFT 준비, 불투명한 참조 (opaque references), 학습과 서비스 간의 일치성, LoRA 미세 조정, 예측, 평가 및 MCP를 통한 리플레이.
남은 과제는 이를 강화하는 것입니다: 훈련 세트 (training set)를 확장 및 다양화하고, 거의 정확한 호출 (near-correct calls)에서의 오류를 줄이며, Underpass Kernel에 실제로 로드된 메모리에 대해 리플레이 (replay)를 검증하는 것입니다.
이것은 종이 위의 아이디어가 아닙니다. 훈련 중인 시스템입니다.
결론
Operator는 다른 모델들과 경쟁하려 하지 않습니다.
다른 위치를 차지하고자 합니다.
질문은 더 구체적입니다: 만약 메모리 프로토콜 (memory protocol)이 잘 정의되어 있다면, 소형 모델 (compact model)이 이를 규율 있게 조작하는 법을 배울 수 있을까요?
Underpass Kernel은 메모리를 읽고, 순회하고, 쓰고, 감사할 수 있는 구조로 변환합니다.
KMP는 계약 (contract)을 정의합니다.
Operator는 이를 실행하는 법을 배우려고 시도합니다.
리소스
- Underpass Kernel: https://github.com/underpass-ai/rehydration-kernel
- Operator trainer: https://github.com/underpass-ai/underpass-kmp-operator-trainer
- Qwen2.5 0.5B Instruct: https://huggingface.co/Qwen/Qwen2.5-0.5B-Instruct
- LoRA: https://arxiv.org/abs/2106.09685
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기