조건에 맞는 레시피 50개를 SQL로 거르는 건 통과/탈락일 뿐 순위가 아니다. 가까운 것을 빠르게 찾은 다음, 그중 무엇을 어떤 순서로 모델에게 먹이느냐가 답을 가른다. 랭킹·rerank·주입·환각의 기록.
모델은 갈아끼울 수 있지만, 한 도메인의 데이터를 정제·태깅·검증·평가·grounding으로 길들여 온 게이트는 복제하기 어렵다. "데이터가 8할" 시리즈를 닫으며 — 데이터 공정이 곧 durable moat이자 출처 규율이다.
LLM이 유창하게 답한다고 맞는 건 아니다. 그럴듯한 허구를 막으려면 판단을 검증 가능한 도메인 사실에 묶어야 한다. 한국어 식문화에서 제철·구성 같은 사실에 LLM 판단을 grounding해 온, 유창함과 정확함을 가르는 게이트의 기록.
AI 품질에서 가장 위험한 문장은 "좋아진 것 같다"이다. 규칙 하나, 판단자 하나를 바꿀 때마다 같은 잣대로 다시 재고 회귀를 먼저 잡는 일 — 한국어 도메인 코퍼스에서 "좋아졌다"를 주장이 아니라 측정으로 바꾼 eval 하네스 이야기.
생성형 AI의 출력은 유창하지만 그게 곧 정확함은 아니다. 더 똑똑한 생성 대신, 우리는 LLM을 판단자 자리로 옮겼다. 코퍼스에 그럴듯한 허구가 쌓이지 않도록 생성과 판정을 분리하고, 판정을 데이터 승격 게이트로 세운 기록.
"데이터가 8할"은 누구나 말한다. 정작 그 8할이 무엇으로 이루어졌는지는 잘 말하지 않는다. 한국어 식문화 도메인에서 우리가 매일 굴리는 정제·태깅·검증·평가·grounding이라는 데이터 공정의 해부도, 그리고 이를 한 편씩 펼칠 시리즈의 출발점.
정적 RAG는 '지금 무엇이 유사한가'는 답해도 '지금 무엇이 여전히 유효한가'는 답하지 못한다. 메모리 감쇠를 currency와 supersession으로 다루는, 살아있는 컨텍스트 인프라에 대한 우리의 관점.
규칙에서 그리디+재시도까지, 식단 엔진을 네 세대 다시 썼다. 매번 측정이 재작성을 강제했고, 코어에서 LLM을 빼 결정론으로 짠 이유 — 우리가 AI를 '어디에 쓰지 않을지'부터 설계하는 방식.
한국어 식문화 도메인에 LLM을 붙이는 일의 병목은 모델 선택이 아니라 코퍼스 품질이었다. 레시피 데이터를 정제·태깅·검증하고, LLM의 역할을 생성자에서 판단자로 옮긴 밥비서 도메인 적응의 기록.
데모에서 잘 돌던 AI도 제품에 들어오면 무너집니다. 빠름·정확·비용·자연스러움이 동시에 성립해야 하기 때문입니다. 밥비서를 매일 운영하며 LLM을 생성자에서 판단자로 옮긴, 운영이 만든 차이의 기록입니다.