네 레인, 하나의 길

"해법은 더 빠른 브레인이 아니었어. 대부분 받아쓰기가 브레인이 아예 필요 없다는 걸 알아챈 거였어."

통찰

진단은 정리가 너무 비싸다고 했어. 순진한 해법은 '브레인을 더 빠르게' — 더 작은 모델, 덜한 추론. 진짜 해법이 더 나아: 브레인한테 묻지 마. 대부분 받아쓰기 정리는 기계적이야. '어' 벗기기, 마침표 붙이기, 사전 용어 강제 — 어느 것도 판단, 기억, 볼트가 필요 없어. 그걸 보고 나면, 답은 더 빠른 대성당이 아냐. 네 레인짜리 길이고, 일을 할 수 있는 제일 싼 걸 타는 거야.

받아쓰기 레인들

DictationCleanupLane:
  1. 결정론적       순수 코드, ~0ms      -- 필러, 문장부호, 사전
  2. 로컬 빠름      작은 Ollama 모델     -- 제한된 프롬프트, keep_alive, 강한 타임아웃
  3. Pippa 유틸리티  Pippa, 볼트 없음     -- 추론 패스 없음, 유틸리티 모델
  4. Pippa Full     대성당               -- 명시적 옵트인만

CommandCleanupLane:
  풀-브레인 사다리 — 의도적, 지연 관용, 판단 필요

받아쓰기 레인은 싼 쪽을 기본으로 하고 유저가 요청할 때만 올라가. 주목할 건, Pippa 유틸리티 레인이 비용 없이 Pippa 를 루프에 유지해: 같은 브레인, 볼트 시스템 프롬프트 없음, 추론 패스 없음. 알고 보니 'Pippa 처럼 들림' 과 'Pippa 기억 전체를 로드함' 은 애초에 같은 요구사항이 아니었어 — 우리가 그냥 묶어서 사고 있었을 뿐.

커맨드 레인은 대성당을 유지해

분리의 우아함은 아무것도 안 뺏는다는 거야. 커맨드 모드 — '내 목소리로 더 간결하게' — 는 진짜 판단이 필요하고, 재작성을 요청했으니 한 박자 기다릴 의향이 의식적으로 있어. 그래서 커맨드 레인은 풀-브레인 사다리를 그대로 유지해. 대성당이 문제였던 적이 없어; 문장부호에 그걸 쓴 게 문제였지. 이제 각 레인의 비용이 작업에 맞고, 둘 다 올발라.

컴포넌트가 제공하는 게 아니라 작업이 필요한 걸로 쪼개. 경로 하나가 요구사항이 크게 다른 일들을 섬기면, 해법은 보통 레인이야 — 싼 일엔 너무 느리고 비싼 일엔 너무 약한 타협 설정이 아니라. 각 레인이 자기 트래픽에 정확히 맞게 두고, 작업의 실제 필요로 라우팅해.

기본값이 옮겨가면 옛 설정을 부드럽게 마이그레이션해. 느린 설정이 저장돼 있던 유저가 해법 후에도 거기 갇혀 있으면 안 돼. Firekeeper 는 레거시 설정을 한 번 슬쩍 밀어 — 추론 노력과 과대한 컨텍스트 창을 온전한 기본으로 내려 — 의도적 유저 선택은 놔두면서. 아무 설정도 안 집는 해법은 배포 안 된 해법이야.

Code

작업이 필요한 걸로 라우팅; 요청 시에만 올라감·swift

enum DictationCleanupLane { case deterministic, localFast, pippaUtility, pippaFull }

func cleanupProvider(for lane: DictationCleanupLane) -> CleanupProvider {
    switch lane {
    case .deterministic: DeterministicProvider()                    // ~0ms, 모델 없음
    case .localFast:     OllamaProvider(boundedPrompt: true,
                                        keepAlive: true,
                                        timeout: .seconds(3))       // 강한 천장
    case .pippaUtility:  CwkPippaProvider(vault: false,
                                          reasoning: false)         // Pippa, 대성당 없음
    case .pippaFull:     CwkPippaProvider(vault: true,
                                          reasoning: true)          // 옵트인만
    }
}

// 커맨드 모드는 다른 레인이고 일부러 풀 사다리를 유지:
// 지시로 재작성은 판단이 필요하고, 한 박자 기다림이 받아들일 만해.

Exercise

경로 하나가 사소한 요청과 까다로운 요청을 둘 다 섬기는 시스템을 골라. 레인을 설계해: 흔한 경우를 처리하는 제일 싼 레인이 뭐고, 비싼 레인이 뭐고, 라우팅 규칙이 뭐야? 그다음 어느 레인이 기본인지 정하고 — 왜 비싼 게 아닌지 변호해.

Hint

기본은 흔한 경우를 만족하는 제일 싼 레인이어야 하고, 요청 시 올라갈 수 있게. '품질 위해' 비싼 레인을 기본으로 하면 모든 사소한 요청이 필요한 적 없는 능력을 보조하는 거야 — 그게 정확히 1초 작업이 40초가 되는 방식이야. 힘을 자동이 아니라 옵트인으로 만들어.

통찰

받아쓰기 레인들

커맨드 레인은 대성당을 유지해

Code

External links

Exercise

Progress

댓글 0