진실은 필요할 때 직접. 미리 씹어 주지 않기

"포트폴리오를 질문에 붙여넣지 마. 뇌한테 들여다볼 수단을 주고, 필요할 때 직접 보게 해."

어시스턴트한테 context 를 주는 두 가지 방법

Pippa 한테 포트폴리오 질문을 하면 Pippa 는 포트폴리오를 알아야 해. 그걸 이루는 방법이 두 가지야. 끌리는 쪽은 context-by-copy. Keep 가 포트폴리오 전체를 텍스트로 직렬화해서 메시지 앞에 붙여 보내는 거지. 미리 씹어 놓은 prompt 라고 할까. Keep 는 이 방식을 거부했어. 대신 context-by-reference 를 써. Pippa 가 데이터가 실제로 필요해진 순간에, 인증된 read-only host tool(status, read, search)로 현재 선택된 scope 를 직접 읽는 거야. 포트폴리오 진실이 미리 씹힌 덩어리가 되어 메시지에 실려 가는 일은 없어.

미리 씹어 주기가 보기보다 나쁜 이유

포트폴리오를 prompt 에 복사해 넣는 게 단순해 보이지만, 조용한 문제 셋이 따라와. 첫째는 staleness. 복사된 스냅샷은 전송 순간에 얼어붙으니까, 대화가 길어지면 이미 움직인 숫자를 놓고 추론하게 돼. 둘째는 scope 누수 위험. prompt 에 쏟아부은 건 어느 scope 가 적용됐어야 하든 이미 context 안에 있어. 복사본은 live scoped 읽기와 달리 Dad, Mom, Family 의 경계를 몰라. 셋째는 낭비. 질문엔 숫자 하나면 충분한데 메시지마다 포트폴리오 전체를 밀어 넣는 거잖아. 필요할 때 읽기가 셋을 한 번에 고쳐. 신선하고, scope 를 지키고, 필요한 만큼만.

유능한 agent 한텐 context 를 가져올 tool 을 줘. context 를 미리 채워 넣지 말고. context 의 소비자가 뭘 언제 읽을지 스스로 정할 수 있는 존재라면, 얼어붙은 사본 대신 참조와 읽을 수단을 넘겨. 사본은 만들어지는 순간부터 낡기 시작하고, live 읽기가 강제해 주는 경계 앞에서 눈이 멀어. 원본이 변할 수 있거나 접근이 통제되는 데이터라면 참조가 사본을 이겨.

매번 신선하고, 매번 scope 안에서

Pippa 가 필요한 순간에 host adapter 로 직접 당겨 오는 구조 덕분에 좋은 성질 둘이 공짜로 따라와. 읽기는 언제나 현재 야. 대화를 시작하던 시점이 아니라 바로 지금의 포트폴리오를 비춰. 그리고 언제나 선택된 scope 를 지켜. Dad scope 에 있으면 live 읽기는 Dad 의 데이터만 돌려주고, Mom 의 상세 보유가 슬그머니 쓸려 들어오는 일은 없어. Track 1 에서 만났던 scope 경계가 매 읽기 순간마다 새로 강제되는 거야. prompt 사본 속에, 맞았든 틀렸든, 한 번 얼어붙으면 끝인 방식과는 달라.

compute-on-read 와 같은 본능이야. Family 총합은 읽을 때 합치고, live 가격은 읽을 때 얹었잖아. Sidekick context 는 그 원칙의 대화 버전이야. sync 를 맞춰 줘야 하는 사본을 만들지 말고, 필요할 때 live 원본을 읽어라. 앱 전체에 걸쳐 Keep 는 유지되는 사본보다 신선한 읽기를 골라. 사본은 consistency 빚이고, live 읽기는 빚이 없거든.

Code

미리 씹은 prompt 말고, tool 딸린 참조 (예시)·python

# 이건 아니야. 전송 순간 얼어붙는 사본을 prompt 에 붙인 꼴.
def ask_prechewed(question):
    snapshot = serialize_entire_portfolio()      # 만드는 순간부터 낡아
    return pippa.chat(f"{snapshot}\n\n{question}")  # scope 무시, 낭비

# 이거야. Pippa 한테 tool 을 쥐여 주고, 필요할 때 live scope 를 읽게 해.
def ask_on_demand(question, scope):
    return pippa.chat(
        question,
        tools=[host.status, host.read, host.search],  # read-only, live, scoped
        scope=scope,   # Dad scope 읽기는 Dad 데이터만 돌려줘
    )
# 데이터는 추론하는 순간에 신선하게 가져오고, scope 경계도 그대로 지켜져.

Exercise

호출하는 쪽이 데이터를 통째로 붙여넣어 주는 방식의 어시스턴트나 리포트 생성기를 하나 골라 봐. 그 사본이 끌고 오는 문제를 나열해 봐. staleness 는 언제 얼어붙는지, 과다 포함은 질문에 비해 얼마나 많이 보내는지, 경계 누수는 사본이 접근 scope 를 지키는지. 그다음 어시스턴트가 scoped 하고 read-only 인 tool 로 필요할 때 직접 가져오도록 다시 설계해 봐. 사본에서 참조로 바꾸면 세 문제가 각각 어떻게 되는지 적어 봐.

Hint

사본은 편한데 세 방향으로 동시에 틀려. tool 딸린 참조는 셋을 다 고쳐. 추론 시점에 읽으니 신선하고, 물어본 것만 가져오니 최소고, 읽기 자체가 경계를 강제하니 scope 도 지켜져. 대가는 tool 을 만들어야 한다는 건데, 그 대가로 붙여넣기가 절대 못 사는 정확성을 사는 거야.

어시스턴트한테 context 를 주는 두 가지 방법

미리 씹어 주기가 보기보다 나쁜 이유

매번 신선하고, 매번 scope 안에서

Code

External links

Exercise

Progress

댓글 0