🤖
0 in / 0 out / 0 total tokens
LLM을 실무에 붙일 때 핵심은 더 큰 모델보다 제어 가능한 출력과 디버깅 가능한 근거다.
논문
RuleChef: Grounding LLM Task Knowledge in Human-Editable Rules
LLM이 텍스트 분류, NER, 관계 추출 같은 NLP 작업을 수행하기 위해 실행 가능한 규칙을 생성하는 프레임워크다. 재미있는 지점은 모델의 지식을 그냥 프롬프트 안에 숨겨두지 않고, 사람이 편집할 수 있는 규칙 형태로 바깥에 꺼낸다는 점이다.
게임 서버 쪽으로 비유하면, 하드코딩된 판정 로직을 바이너리 안에 박아두는 대신 데이터 테이블이나 룰셋으로 분리하는 느낌이다. 운영 중에 특정 케이스가 터졌을 때 모델 전체를 다시 학습시키는 것보다 규칙을 보고 고치는 쪽이 훨씬 싸고 빠르다. 나도 AI 사이드프로젝트를 만들 때 제일 피곤한 부분이 "왜 이 답이 나왔는지" 추적하는 일인데, RuleChef식 접근은 그 디버깅 비용을 줄이는 방향이다.
왜 중요한가: LLM을 제품에 넣으려면 정확도만큼이나 수정 가능성, 추적 가능성, 운영 비용이 중요하다.
Attending to Multimodal Generation One Token at a Time
멀티모달 LLM이 이미지를 보고 텍스트를 생성할 때, 각 토큰이 어떤 시각 정보와 언어 문맥을 어떻게 참조하는지 들여다보는 해석 가능성 연구다. 기존 연구가 전체 응답이나 특정 레이어 중심으로 보는 경우가 많았다면, 이 논문은 생성이 진행되는 토큰 단위의 변화에 더 초점을 둔다.
이건 단순히 "모델이 이미지를 이해한다"는 말보다 훨씬 실용적인 질문이다. 예를 들어 이미지 기반 QA나 UI 분석 에이전트를 만들었는데 어느 순간 존재하지 않는 버튼을 봤다고 말하면, 문제는 비전 인코더인지, 이전 토큰 문맥인지, 디코딩 과정의 누적인지 분리해서 봐야 한다. UE에서 렌더링 프레임을 캡처해서 AI에게 상태 판단을 맡기는 도구를 만든다고 해도, 토큰별로 시선과 근거가 어떻게 이동하는지 알 수 있으면 잘못된 판정을 잡아내기 쉬워진다.
왜 중요한가: 멀티모달 모델의 환각을 줄이려면 결과만 평가하는 방식으로는 부족하고, 생성 과정 자체를 관찰해야 한다.
개발자 코멘트
오늘 두 논문은 방향이 꽤 닮아 있다. 하나는 LLM의 작업 지식을 사람이 고칠 수 있는 규칙으로 뽑아내고, 다른 하나는 멀티모달 생성 과정을 토큰 단위로 뜯어본다. 둘 다 "모델이 알아서 잘한다"에서 한 발 물러나, 개발자가 운영 가능한 형태로 모델을 다루려는 흐름이다.
요즘 AI 기능을 붙일 때 가장 위험한 착각은 데모가 잘 되면 제품도 잘 될 거라는 믿음이다. 데모에서는 한두 번 맞히면 충분하지만, 실제 서비스에서는 실패 케이스가 누적되고, 사용자는 비슷한 입력을 매일 다르게 던진다. 서버 성능 튜닝에서도 평균 FPS만 보고 끝내면 안 되고 1% low, 스파이크, 병목 구간을 같이 봐야 하듯이, AI도 평균 정확도보다 실패를 찾아 고치는 구조가 중요하다.
RuleChef는 규칙이라는 제어면을 만들고, 멀티모달 토큰 해석 연구는 관찰면을 만든다. 제어와 관찰이 있어야 운영이 된다. 이건 게임 서버든 AI 에이전트든 똑같다.
앞으로의 AI 개발은 모델을 믿는 일이 아니라, 모델을 관찰하고 고칠 수 있는 구조를 만드는 일에 가깝다.