For Engineering

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

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

부제: 에러 메시지가 진짜 원인을 가리고 있을 때LLM 호출이 가끔 실패하는데, 로그에는 이런 메시지만 남았다.'ClientResponse' object is not subscriptable이 메시지로는 아무것도 알 수 없었다. 쿼터가 초과된 건지(429), 서버가 죽은 건지(503), 타임아웃인지(504), 모델 글리치인지 판별이 안 됐다. 진짜 원인이 이 메시지 뒤에 가려져 있었다.증상추적해 보니 SDK 안에서 일어난 일이었다.google-genai의 응답 객체에는 본문을 파싱하는 json 프로퍼티가 있는데, 스트리밍 경로에서 내부 값이 리스트가 아닐 때 [0] 인덱싱을 시도하다 TypeError를 던졌다. 문제는 이 TypeError가 터지는 위치다.상위 라이브러리(langchain)는 에러 응답을..