모델이 자체 출처를 인용할 수 없게 만든 '두 번째 뇌' 구축

LLM-wiki 패턴 — Karpathy가 지난 4월부터 언급하며 확산시킨 방식 — 은 그 지지자들조차 스스로 문제점을 지적합니다. 바로 '쓰레기가 들어가면, 자신감 넘치는 합성물이 나온다(garbage in, confident synthesis out)'는 것입니다. 모델은 사용자의 메모를 읽고 개념 페이지를 작성하고, 이 페이지가 다음 처리의 원본 자료가 됩니다. 몇 세대(generations)가 지나자 지식 기반에는 아무도 말한 적 없는 것들로 가득 차게 됩니다. 통상적인 해결책은 더 좋은 프롬프트입니다. 저는 그것을 시도해 보았습니다. 동일한 지침에 대해 다섯 가지 방식으로 요청했을 때, 모델은 자신의 추론 과정에서 그 규칙을 정확하게 재진술했지만, 이내 정반대의 행동을 했습니다. 그래서 저는 질문하는 것을 멈췄습니다.

다섯 개의 게이트(gates)를 모두 코드로 구현했습니다. 텍스트에 문자 그대로 나타나지 않는 개념은 링크커(linker)가 보기 전에 버려집니다. 점수가 낮아지는 것이 아니라, '버려집니다(dropped)'입니다. 파생된 페이지는 새로운 개념을 발견할 수 없습니다. 시스템 자체의 출력물은 다음 세대의 원본 자료가 절대 되지 않습니다. 출처에서 정의되지 않는 개념은 페이지를 얻지 못합니다. 백 번 언급되었다고 해도 한 번도 정의되지 않은 것은 없습니다. 그래프는 사용자가 저장하기로 선택한 것들로 채워지고, 논의된 모든 것으로 채워지지 않습니다. write는 스크립트를 전혀 편집하는 것을 거부합니다.

대화 내용에 대한 개념 추출을 무력화시키는 것이 중요하지 않습니다. 만약 모델이 먼저 대화를 재작성할 수 있다면 말입니다 — 그리고 실제로 그렇게 시도했습니다, '추가 내용을 포함하여 스크립트를 재구성'하려 했습니다. 첫 번째 게이트는 엄격하지만 맹목적이지 않습니다. 배치 전체를 버리는 대신, 살아남은 개념들만 유지합니다. 실제 페이지에서는 15개 중 14개의 개념이 문자 그대로 나타났고, 만약 '전부 아니면 전무(all-or-nothing)' 방식이었다면 단 하나의 이탈된 항목 때문에 14개를 모두 날렸을 것입니다.

각 게이트에는 해당 게이트가 제거되었을 때 실패하는 테스트가 있습니다. 이것이 제가 다른 사람의 버전을 확인할 때 가장 먼저 점검할 부분입니다. 이 시스템은 RTX 4050 Mobile에서 9B 오케스트레이터와 CPU에 임베딩을 사용하여 구동되며, 이는 6 GB 메모리를 사용합니다. 왜냐하면 오케스트레이터가 이미 카드를 가득 채우기 때문에 검색(search) 기능이 그것과 경쟁해서는 안 되기 때문입니다. LLM-wiki 가이드는 24 GB 또는 64 GB Mac에서 구동하도록 요구합니다. 하지만 이 시스템은 4 GB에서도 작동합니다. 빈 카드, 데스크톱을 iGPU에 연결하여 측정한 결과, 컨텍스트가 35k일 때 9B 모델은 5.6 GB를 사용했고, 같은 컨텍스트의 4B 모델은 3.7 GB를 사용했습니다. 이 4B 모델 하나로 세 가지 역할을 모두 수행할 수 있습니다.

대화가 나빠지고 다른 것은 아무것도 변하지 않는데도, 그 이유는 게이트(gates)가 모델의 판단이 아니기 때문입니다. 제가 직접 실행해 보고서야 알게 된 것들입니다. 모델을 끊는 것이 어떻게 거짓말하게 만드는지 보여줍니다. 반복 검색 가드(repeat-search guard)는 [STOP]을 반환하곤 했습니다. 아무것도 남지 않은 모델은

스크립트 프롬프트에 한 문장 — “대화가 무언가를 정의하는 것이 아니라, 문장 중간에 언급하는 것” — 을 추가하는 것만으로도 동일한 스크립트에서 2개의 개념을 10개로 늘리는 결과를 얻었습니다. 6 GB가 일정을 결정하며, 모델만이 아닙니다. 요약 모델과 추출 모델은 동시에 카드(GPU 메모리)에 올라갈 수 없기 때문에, 작업이 페이지별로 번갈아 가며 진행되지 않습니다: 모든 요약은 4B 모델이 로드되는 동안 실행되고, 그 다음 모든 추출은 9B 모델이 로드될 때 실행됩니다. 페이지당 전환을 했다면 20페이지에 대해 40번의 모델 로드가 필요했을 것입니다. 타이머는 메커니즘이 아니라 기본값입니다 — 작업(pass)은 명령이며, --dry-run은 모델에 손대지 않고 볼트가 무엇을 얼마나 빚지고 있는지 계산합니다. 기존 볼트를 사용하는 경우 설치 시 한 번 실행하면 밤까지 기다릴 필요가 없습니다. 해결되지 않은 링크는 폐기되지 않고 유지됩니다. 아무 곳도 가리키지 않는 링크 목록이 성장 대기열(growth queue)입니다 — “여기는 아무 데도 가지 않는다”고 말하는 같은 행들이 “볼트가 계속 도달하려는 것이 이것이다”라고 말합니다. 그리고 페이지가 마침내 작성되면, 이전에 쓰인 모든 링크가 단일 SQL 업데이트로 살아납니다: 228개의 링크가 0.55ms 만에 처리되고 파일은 하나도 다시 쓰이지 않았습니다. 더 큰 카드가 얼마나 가치가 있는지 생각보다 적게, 그리고 예상치 못한 곳에서 알 수 있습니다. 대화 모델(conversation model)에 사용하는 것이 좋습니다 — 그것이 더 나은 모델이 더 나은 답변을 생성하는 유일한 역할입니다. 24 GB에서는 27B급의 Q4 빌드가 컨텍스트를 남기고 들어맞습니다. 추출이나 요약 기능을 업그레이드하는 것은 거의 의미가 없습니다. 둘 다 전송 작업(transport jobs)입니다: 텍스트에 나타나는 개념을 복사하고, 이 페이지가 무엇인지 말하는 것입니다. 둘 다 온도(temperature): 0으로 실행되므로 샘플링 매개변수가 전혀 필요하지 않습니다 — 같은 페이지는 동일한 개념을 생성해야 합니다. 더 큰 모델은 그 작업을 더 느리게, 그리고 더 정확하게 수행합니다. 컨텍스트가 더 많다고 해서 자동으로 더 좋은 것도 아닙니다. 사용 중인 대화 모델은 약 32k를 유지하며 이를 넘어서기 때문에, 여유 공간은 더 큰 창(window)에 들어가는 것보다 모델을 편안하게 맞추는 데 사용됩니다.

진정으로 잠재력을 끌어낼 수 있는 여분의 VRAM 제약은 전체 설계가 이를 우회하는 방식에 있습니다. 분석과 대화는 동시에 상주할 수 없기 때문에 유지보수 작업이 밤에 진행됩니다. 두 가지 모두를 위한 공간이 있다면 금고(vault)가 유휴 상태일 때 언제든지 실행될 수 있을 것입니다. 현재 아무것도 그렇게 하지 못합니다. 이것은 설정 변경이 아니라 유지보수 루프의 변화입니다. 의도적으로 컨텍스트를 작게 유지하는 방식: 각 페이지는 자체 모델 컨텍스트에서 읽힙니다. 10페이지가 한 번에 들어가는 것이 아닙니다. 긴 문서는 소형 모델이 텍스트를 파악하는 능력을 저하시키며, 함께 읽은 페이지들은 서로 영향을 미칩니다(bleed into each other). 계층 간에는 단지 구절(passages)만 교차합니다. 리더는 전체 페이지를 보지만, 플래너는 절대 보지 못하며, 수천 개의 토큰 대신 페이지당 150~300개의 토큰을 받습니다. 이것이 플래너가 가득 차기 전에 여러 라운드를 실행할 수 있게 하는 요소입니다. 검색은 어떤 페이지 본문에도 도달하기 전에 요약 계층에서 중단됩니다. 히트(hit)마다 해당 페이지가 무엇인지 한 줄로 설명하며, 5개의 히트에 약 75토큰이 할당되고, 이것이 보통 답안이 됩니다. 본문 수준의 검색은 요약본을 통해 페이지가 관련성이 있다는 것은 보여주었지만 내용을 담고 있지 않을 때만 발생합니다. 그리고 링크 그래프는 텍스트로 렌더링됩니다. 그래프 자체는 기계가 읽을 수 있지만, LLM이 읽는 형태는 아니므로 구조를 글로 풀어씁니다: 무엇이 무엇에 연결되는지, 어떤 이름이 아예 페이지로 해결되지 않는지 등을 말입니다. 모델은 페이지 더미가 아니라 금고의 모양(shape)을 얻게 됩니다.

무엇을 하지 못하는가: 이 시스템은 주장을 검증하지 않습니다. 검색은 페이지를 찾을 뿐, 그 내용을 판단하지는 않습니다. 게이트(gates)는 새로운 자료를 발명하는 것을 막지만, 저장한 내용이 올바른지에 대해서는 아무것도 말해주지 않습니다. 그리고 솔직한 한계점: 제 금고는 46개의 파일로 구성되어 있습니다. 게이트는 테스트로 커버되어 있어 메커니즘 자체에는 의문이 없지만,

반드시 로컬에 머무를 필요는 없습니다. Open WebUI는 OpenAI 기반 제공업체와 Anthropic에 연결되며, 유지보수 역할은 역할별 제공업체 플래그를 사용하므로, 최첨단 모델(frontier model)로 대화를 진행하고 카드(card)에서 추출 작업을 수행할 수 있습니다. 만약 누군가 게이트 메커니즘이 약한 모델을 위한 우회책이라고 말한다면 저는 이 부분에 반대 의견을 제시하겠습니다: 이는 코드 안에 있기 때문에, 답변하는 모든 것을 붙잡아 둡니다. 27B 모델은 9B 모델보다 적은 확인 과정을 필요로 하는 것이 아니라—단지 실패하는 경우가 더 적다는 것 자체가 문제입니다. 왜냐하면 당신은 의심하기를 멈추기 때문입니다. 아직 MCP 서버는 없지만, 이것을 공백으로 남겨두기보다는 이유를 설명할 가치가 있습니다: 도구 파일(tool file)만이 전체 대화를 볼 수 있는 유일한 경로이며, 이는 전사 기록 캡처(transcript capture)가 기반하고 있는 것입니다. MCP로 포장하면 일곱 가지 기본 요소는 작동하지만, 그중 하나의 메커니즘은 작동하지 않으며, 이것이 네 번째 게이트의 근거를 무너뜨립니다. 만약 누군가가 전사 기록보다 Claude Desktop에 이 기능을 더 원한다면, 그것은 짧은 작업일 것입니다. MIT. 레포지토리: https://github.com/farukhanci/the-sentinel 웹 리서치(web-research) 부분에는 보조 서비스가 있습니다. 이는 페이지를 검색하고 읽으며, 유지하는 모든 구절은 출처가 된 페이지와 단어별로 확인됩니다—의역은 제외되므로, 구절 내에서의 조작(fabrication)은 구조적으로 불가능합니다. 그 구절들로부터 작성된 글은 검사되지 않으며, 바로 여기서 테스트 중 한 번 가짜 인용이 나타났습니다. 더 흥미로운 부분이 필요하다면 README에서 링크를 확인하세요. /u/dimensionof0 님이 제출함 [링크] [댓글]