이 기사는 개인 개발 중인 아키텍처

VLTE-BPTM v1.6 (alpha)의 설계 사상과, 현 시점에서 측정된 성능을 「한계점 포함」하여 공유하는 것입니다. 완성품 발표가 아닙니다. 오히려 「여기까지 측정되었고, 이 부분은 아직 미확립되었다」라는 현재 위치 그 자체를 기사의 주제로 하고 있습니다.

TL;DR

• 자연어 입력을 **64bit의 Thought Code (라우팅 키)**로 변환하여, 「어떻게 생각할지」를 결정하는 경량화된 전단 레이어(Front-end layer)를 만들고 있다.
• 설계의 핵심은 책임의 분리 (Separation of Concerns): 의미 이해 / 처리 경로 선택 / Unit 실행 / 답변 생성을 별개의 컴포넌트로 계약(Contract)을 통해 구분한다. Router를 지식 모델이나 답변 모델로 비대화시키지 않는다.
• 효과가 명확하게 나타나는 부분은 **「LLM을 호출하기 전에 호출할지 말지를 결정하는 것」**이다. 인사와 같은 입력에서는 무거운 LLM 호출 (4~6초)을 통째로 회피할 수 있어, 차원이 다른 속도를 보여준다.
• 반면 답변 본문의 정확성 (semantic answer quality)에 대한 독립적인 평가는 현재 0건으로, 미확립 상태이다. Route 선택 정밀도 또한 분포 내(In-distribution)에서는 높지만, 교차 평가(Cross-evaluation)에서는 떨어진다. 이 기사에서는 그 부분을 숨기지 않는다.

1. 동기: 「전부 LLM에 던지는 것」에 대한 위화감

현재 LLM 애플리케이션의 주류는 가공되지 않은 프롬프트를 그대로 모델에 전달하여, 분류도 판단도 생성도 하나의 모델이 수행하는 구성입니다. 이는 강력하지만, 설계자로서 두 가지 우려되는 점이 있었습니다.

하나는 비용 배분의 거칠음입니다. 「안녕하세요」도 「이 설계를 다각도로 검증하여 대안을 3가지 제시해줘」도, 똑같이 무거운 모델에 동일하게 흘러갑니다. 전자에 추론 예산을 할당할 필요는 없을 것입니다.

또 다른 하나는 판단의 불투명성입니다. 「왜 이 입력을 이렇게 처리했는가」가 모델 내부에 녹아 있어, 로그로서 외부에서 추적할 수 없습니다.

VLTE-BPTM은 이 두 가지 점에 대해 「LLM의 전단에 얇은 사고 상태 레이어를 둔다」는 접근 방식으로 답하고자 합니다.

2. 전체상

처리는 하나의 파이프라인으로서 흐릅니다.

input
-> active_bits # 입력에서 발생하는 비트
-> selected_units # 어떤 사고 Unit을 사용할지
...

설계상 가장 중요하게 여기는 것은 다음의 책임 경계입니다 (Semantic Routing Architecture v0.1 기준).

• 의미 추출 모델은 답변을 생성하지 않는다.
• 처리 Router는 원문 프롬프트를 해석하지 않는다 (검증된 의미 Packet만을 받는다).
• Core는 의미 내용을 생성하지 않는다. Unit과 실행 순서를 구성할 뿐이다.
• 답변 LLM이 지식 추론과 문장 생성을 담당한다.
• 불확실성은 숨기지 않고, 재해석(re-analysis) · 명확화(clarify) · 상위 처리 클래스로 보낸다.
• 출력 및 평가 결과를 자동 학습에 사용하지 않는다.

포인트는 각각이 「하지 않는 것」으로 정의되어 있다는 점입니다. Router에 지식을 갖게 하지 않고, Core에 문장을 쓰게 하지 않습니다. 비대화를 계약으로 금지함으로써 각 층을 독립적으로 평가하고 교체할 수 있도록 하고 있습니다.

3. 실제로 구동하면 어떻게 되는가

이 설계를 리뷰해 주세요를 입력했을 때의 실제 출력(발췌)은 다음과 같습니다.

{
"thought_code": { "value": "0x3E70C407151C4398", "width": 64, "role": "external_routing_key" },
"metrics": { "active_bit_count": 26, "active_bit_density": 0.40625, "selected_unit_count": 3 },
...

「리뷰해줘」라는 입력에 대해, Horizontal Mesh의 승자가 verify가 되어, 최종적으로 LLM에 전달할 지시서 (llm_order)가 「결론 전에 전제·리스크·근거를 확인하라」는 verify 모드의 명령이 됩니다. 어떤 입력이 어떤 비트를 세우고, 어떤 Unit을 승리하게 하며, 어떤 지시서가 되었는지를 전부 JSON으로 추적할 수 있습니다. 이 추적 가능성(Traceability)이 동기의 두 번째 점(불투명성)에 대한 해답입니다.

참고로 0x3E70C407151C4398와 같은 Thought Code는 어디까지나 **외부 라우팅 키 (external routing key)**이며, 의미 좌표가 아닙니다. Unit 내부의 16×16 또한 의미 맵이 아니라 활성 버퍼(active buffer)입니다 (이 부분을 오해하기 쉬우므로 사양서에 명기하고 있습니다).

4. 성능: 나타나고 있는 부분과, 나타나지 않는 부분

여기가 본 기사의 핵심입니다. 구분해야 할 지표가 3가지 있습니다.

4.1 속도: 「부르지 않는 것」이 가장 효과적

앞단에서 「이것은 LLM이 불필요함」이라고 판단할 수 있는 입력은, 무거운 모델 호출을 통째로 스킵합니다. 실측치 (로컬의 gemma-4-12b에 대한 router 유/무 비교):

이 수치는 「Router 자체가 빠른 것」이 아니라 「LLM을 부르지 않고 해결했기」 때문이라고 솔직하게 밝혀둡니다. 모델이 똑똑해진 것이 아닙니다. Adapter 자체의 오버헤드는 1회 호출당 0.0002~0.186 ms 정도로, 판단 레이어(layer)로서는 충분히 경량입니다.

4.2 route 선택 정밀도: 분포 내(In-distribution)는 높고, 교차 평가(Cross-evaluation)는 떨어진다

동결된 회귀 스위트(regression suite)에서는 높은 값이 나옵니다.

• frozen regression: 25/25 = 1.00 (raw accuracy, macro-F1 1.0) - foundation anchors: 58/58 = 1.00

단, 이는 「학습 및 조정에 사용한 분포의 내부」에서의 이야기입니다. 별개의 계통인 fixture에 교차 적용하면 떨어집니다.

• Core를 Router 경계 fixture에 적용: 9/25 = 0.36 (macro-F1 0.364, 95% Wilson 0.20–0.56) - 비(non)-grouped holdout: 26/30 = 0.867 (Wilson 0.70–0.95) - 반복 CV: 0.769 (데이터 포인트가 비독립적이므로 신뢰 구간은 산출하지 않음)

고정 fixture의 100%를 「일반적인 정밀도」라고 홍보해서는 안 된다는 것을 스스로에 대한 경계로서 사양서에 명기하고 있습니다.

4.3 답변 품질: 미확립 (이것이 솔직한 현재 위치)

그리고 가장 중요한 단서입니다.

independent_case_count = 0
status = not_established

답변 본문 자체의 정답 여부를 독립적으로 blind 평가한 데이터는 현 시점에서 0건입니다. 측정되고 있는 것은 주로 경로 선택의 정밀도이며, 「나온 답이 옳은가」는 아직 확립되지 않았습니다. 이 부분을 속이면 기사 전체의 신뢰가 무너지기 때문에, 첫 TL;DR부터 명시하고 있습니다.

5. 무엇에 쓸 수 있는가 (그리고 아직 쓸 수 없는 것)

지금 바로 가치가 있는 사용법:

• LLM 전단의 비용 게이트 (Cost gate). 「부를 것/부르지 않을 것」, 「가벼운 모델/무거운 모델」을 결정적인 규칙으로 분류합니다. - 입력 처리의 감사 로그 (Audit log). 어떤 입력이 어떻게 판단되었는지 JSON으로 완전히 추적할 수 있습니다. - 지시서 (llm_order)의 명시적인 제약 주입 (예: 클라우드 출력을 학습에 사용하지 않음을 구조적으로 강제).

아직 맡길 수 없는 것:

• 답변의 정답 여부를 보장하는 것 (독립 평가가 0건).
• 학습 분포 외부에서의 route 정밀도 (교차 평가에서 0.36까지 떨어지는 구간이 있음).

즉, 현재의 정확한 위치는 「답변을 똑똑하게 만드는 장치」가 아니라 「LLM을 언제, 어떻게 호출할지를 결정하는, 추적 가능한 전단 레이어 (layer)」입니다.

6. 앞으로

설계는 「하나의 Router에 전부 집약하지 않는다」는 방향으로 3개 트랙으로 나누어 독립 평가를 진행할 예정입니다.

• Pattern Language Model: 생문(raw text)에서 최소 의미 신호를 추출 (답변은 생성하지 않음) - Processing Router: 의미 패킷(Packet)으로부터 처리 경로와 예산을 결정 (생 프롬프트는 보지 않음) - LLM Integration: 기존 Core / Runtime / tool을 연결하여 전체 품질과 비용을 평가

직근의 최우선 과제는, 4.3에서 공란으로 남아 있는 답변 품질의 독립 blind 평가를 시작하는 것입니다. 그 부분이 채워져야 비로소 「성능」이라고 당당히 말할 수 있다고 생각합니다.

마치며

이 기사를 「완성된 고성능 시스템의 발표」가 아니라 「설계 사상과, 솔직한 성능의 현재 위치」로서 작성한 이유는, 자체 제작 아키텍처에서 가장 속이기 쉬운 부분이 성능을 이야기하는 방식이라고 생각하기 때문입니다. 나오고 있는 숫자(속도)와, 나오지 않고 있는 숫자(답변 품질)를 동일한 열량으로 나열하는 것 —— 그 자체를 하나의 실천으로서 공유할 수 있다면 좋겠습니다.

피드백 환영합니다. 특히 「책임 분리 (Separation of Concerns)의 경계 설정 방법」과 「답변 품질을 어떻게 독립적으로 평가할 것인가」에 대해 의견을 주시면 감사하겠습니다.

Discussion