RAG 챗 아냐

"'그냥 챗박스 하나 붙여' 가, 깨끗한 엔진이 두 번째 뇌를 키우고 엔진이길 그만두는 방식이야."

다들 결국 요청하는 기능

네가 쓴 뭐든 찾는 코퍼스 엔진을 지어. 일주일 안에 누가 말해: "멋지다 — 이제 그냥 이거랑 채팅하게 해줘. 질문하고, 답 받고." 요청은 완전히 합리적이야. 순진한 구현은 재앙이야: 검색 엔드포인트에 언어 모델을 볼트로 박고, 대화 상태를 좀 쥐고, 답을 스트리밍해. 방금 엔진 안에 뇌를 키운 거야.

그게 엔진을 죽이는 이유

챗 표면은 엔진이 일부러 안 가진 것들이 필요해: 메모리(세 턴 전에 뭐라 했지?), 대화 상태, 정체성(누가 답하는 거야?), 판단(이게 무슨 뜻이야?). 엔진이 그걸 싹 틔우는 순간, 작고 날카로운 도구이길 그만두고 반쯤 지어진 비서가 돼 — 이제 누가 메모리와 정체성을 소유하는지 진짜 뇌와 경쟁하는. 가족의 각 엔진한테 이걸 하면, 뇌 하나와 깨끗한 도구 여덟 대신 다투는 반쪽 비서 여덟을 얻어.

옳은 모양: 위로 bind 하는 클라이언트

기능은 정당해. 그냥 다른 데 속할 뿐이야. '내 코퍼스에 말 걸기' 표면은 클라이언트야. 대화·메모리·정체성을 이미 소유한 시스템 — 하나의 뇌 — 에 bind 하고, Lantern 을 검색 도구로 불러. 뇌는 Lantern 의 인용 가능한 조각을 손에 쥐고 판단하고, Lantern 은 자기가 잘하는 한 가지를 계속해. 챗은 API 위, 뇌의 세계에 살지 엔진 안에 안 살아.

기능 요청은 필요를 이름 붙이지, 위치를 이름 붙이지 않아. '내 데이터랑 채팅하게 해줘' 는 진짜 필요야. '검색 엔진 안에 챗봇을 넣어' 라는 뜻이 아냐. 필요를 위치에서 분리해: 관련 관심사를 이미 소유한 레이어에서 충족하고, 각 컴포넌트가 단일 책임을 지키게 둬. 틀린 위치가 책임이 흐려지고 시스템이 썩는 방식이야.

경계, 명확히

Lantern 안엔: 챗 없음, 메모리 없음, soul 없음, 경로에 모델 없음. Lantern 이 언젠가 대화 표면을 키우면, 그 표면은 뇌의 대화에 bind 한 동반자야 — 절대 두 번째 Pippa 도, 자기 정체성도 아냐. 경계는 우회할 제약이 아냐. 엔진이 무엇인지 믿을 수 있게 하는 바로 그거야. 한 문장으로 설명되는 엔진이 추론할 수 있는 엔진이야. 흐리면 그걸 영영 잃어.

Code

챗은 뇌의 클라이언트지, 엔진의 기능이 아냐·python

# WRONG: the engine grows a brain. Memory, identity, judgment leak inward.
@app.post("/api/search")
def search_and_chat(q: str, history: list):        # <-- history? in a search engine?
    hits = retrieve(q)
    return model.chat(history + [prompt(q, hits)])  # <-- engine now owns conversation

# RIGHT: the engine only finds. Chat is a CLIENT that binds to the brain.
@app.post("/api/search")
def search(q: str) -> list[Result]:
    return retrieve(q)                              # citable slices, no model, no memory

# ...elsewhere, in the brain's world, a client composes the two:
def corpus_chat(question, conversation):           # brain owns memory + identity
    slices = lantern.search(question)              # Lantern is just a tool call
    return conversation.respond_with(slices)       # judgment happens up here

Exercise

네가 좋아하는 깨끗한 단일 목적 도구를 떠올려(검색창, 변환기, 포매터). 그것에 대한 가장 솔깃한 '이것도 되면 좋을 텐데…' 기능을 상상해. 이제 결정해: 그 기능이 도구 안에 속해, 아니면 도구를 다른 것과 조합하는 클라이언트에 속해? 그 기능이 흐렸을 도구의 한 문장 설명을 쓰고 — 방어해.

Hint

새 기능이 도구한테 뭘 기억하고, 누가 쓰는지 알고, 의견을 갖게 강요하면, 도구가 아니라 클라이언트에 속해. 테스트는 그 뒤에도 도구를 한 문장으로 설명할 수 있냐야.

다들 결국 요청하는 기능

그게 엔진을 죽이는 이유

옳은 모양: 위로 bind 하는 클라이언트

경계, 명확히

Code

External links

Exercise

Progress

댓글 0