For Engineering

[프롬프트] Gemini System Prompt 고정 캐싱 전략

부제: 캐시를 살리려고 시스템 프롬프트를 통째로 고정한 이야기이 프로젝트는 Gemini를 기준으로 만들었다. Gemini는 다른 모델과 다른 구석이 몇 있는데, 그중 캐싱과 시스템 프롬프트 다루는 방식이 설계를 꽤 바꿔놨다. 그 얘기다.Gemini 캐시는 접두사로 동작한다Gemini의 implicit caching은 요청의 앞에서부터(prefix) 같은 부분을 찾아 재사용한다. 순서는 대략 system_instruction → tools → 대화 내용 이다.여기서 중요한 성질이 하나 있다. 앞쪽이 1바이트라도 바뀌면 그 뒤 전체가 캐시 미스다. 접두사 매칭이니 처음 달라지는 지점부터는 전부 새로 계산한다.그러니 캐시를 살리고 싶으면 맨 앞의 system_instruction을 절대 건드리면 안 된다.처음..

부제: LLM이 읽기 전에 쓰지 못하게 막기캘린더를 다루는 에이전트에서 가끔 사고가 났다. 모델이 기존 일정을 읽지 않고 바로 일정을 만들거나 고쳤다. 그러면 두 가지 문제가 생긴다.이미 있는 약속과 겹치는 시간에 새 일정을 덮어쓴다.수정·삭제할 때 event_id를 실제로 모르니 그럴듯한 값을 지어낸다(환각).문제프롬프트와 도구 설명(docstring)에 "먼저 조회하라"고 적어도 회귀가 반복됐다. 지시는 권고일 뿐이라, 모델이 안 지키면 그만이다.여기서 Claude Code의 패턴이 떠올랐다. Claude Code는 파일을 Write하기 전에 그 파일을 Read하지 않았으면 시스템이 거부한다. 지시가 아니라 도구 레이어에서 강제하는 방식이다. 이걸 우리 도구 레이어에 옮겨오기로 했다.정리한 방식 — ..

부제: 시스템 프롬프트가 안 먹힐 때 — 생성 지점에 한 번 더먼저 이건 자주 쓰는 기술이 아니라 치트키에 가깝다. 시스템 프롬프트로 안 되는 게 확인됐을 때, 마지막에 꺼내는 카드다. 남발하면 부작용이 있어서, 왜 통하는지와 언제 쓰면 안 되는지를 같이 적는다.증상대화가 길어지면 봇의 말투가 흐트러졌다. 응답 옆에 괄호로 부연을 달거나((이건 좀 우려돼요)), 무대지시처럼 상황을 설명하거나, 시스템 내레이션조로 사용자를 진단하듯 말했다. 원래 페르소나에서 벗어난, 이른바 OOC(out-of-character)다.시스템 프롬프트 맨 위에 말투 규칙을 분명히 적어 뒀는데도 그랬다.왜 생기나대화가 길어질수록, 생성 지점에서 시스템 프롬프트까지의 거리가 멀어진다.1턴째: 시스템 프롬프트 → 사용자 메시지 (가..

부제: 이미 아는 건 다시 추출하지 않게 — 프로필을 미리 알려주기 대화에서 장기기억을 뽑아내는 단계가 있다. 대화를 읽고 "사용자에 대해 새로 알게 된 것"을 추려 저장하는 LLM 한 패스다. 여기서 사용자 이름 같은 게 자꾸 중복으로 들어왔다.배경 — 기억에도 종류가 있다저장하는 기억을 둘로 나눠 뒀다.정체성(identity): 천천히 변하는 특성 (직업, 알레르기 같은)에피소드(episodic): 시점에 묶인 경험 (어제 10km 뛴 것, 오늘 기분)이 구분은 인지심리학의 의미기억/일화기억 구분(Tulving (1972), Episodic and Semantic Memory — 일화기억과 의미기억의 구분.)에서 가져왔다. 그런데 이름·생일·성별 같은 건 둘 중 어디일까. 이건 "경험"이 아니라 프로..

이번 글은 성공담이 아니라 해보고 접은 이야기다. 그래도 왜 접었는지가 남으면 다음에 같은 길을 덜 헤맬 것 같아 적는다.아이디어에이전트가 사용자의 장기기억(메모리)을 참고해 답한다. 문제는 "언제 기억을 다시 불러오고 갱신할까"다. 가장 단순한 방법은 매 채팅마다 부르는 것이다. 확실하지만 무식하다.그래서 이런 생각을 했다. 사용자가 축구 이야기를 하다가 영양제로 넘어가는 것처럼 문맥(주제)이 바뀌는 순간에만 기억을 갱신하면 되지 않을까. 문맥이 그대로면 굳이 다시 부를 필요가 없다.문맥 변화는 임베딩으로 잡으려 했다. 최근 대화쌍 3개와 사용자의 최신 입력을 임베딩해서 유사도를 재고, 유사도가 충분히 낮으면 "주제가 바뀌었다"고 판단하는 식이다.무엇이 막혔나현실의 유사도 값이 뒤죽박죽이었다. 주제가 ..

도구를 쓰는 멀티턴 대화에서, 모델이 가끔 이상한 행동을 했다. 자기 thinking(추론) 채널 안에 generate_placeholder_thoughts 같은, 실제로 존재하지 않는 도구를 호출하는 흉내를 냈다. 어디에도 정의한 적 없는 도구였다.배경 — thought signature가 뭔가Gemini는 도구 호출(functionCall)에 thought signature라는 암호화된 토큰을 붙여 준다. 이건 직전 턴의 추론을 이어가기 위한 일종의 앵커다. 다음 턴에 이 signature를 그대로 돌려보내면, 모델이 "내가 방금 무슨 생각을 하고 있었지"를 이어받는다.문제는 우리 쪽 코드에 있었다.증상대화 상태를 체크포인트에 저장하기 전에, 이 signature를 떼어내고 있었다. signature..

참고자료 : https://pytorch.kr/hub/pytorch_vision_vgg/ 모델 구성 class VGG11(nn.Module): def __init__(self): super(VGG11, self).__init__() self.conv1 = nn.Sequential( nn.Conv2d(in_channels=3, out_channels=64, padding=1, kernel_size=3), nn.ReLU(), nn.MaxPool2d(kernel_size=2, padding=0, stride=2) ) self.conv2 = nn.Sequential( nn.Conv2d(in_channels=64, out_channels=128, padding=1, kernel_size=3), nn.ReLU(),..