정말 아름다운 가이드임. 여러 페이지의 탭 전환 애니메이션이 특히 마음에 들었음
나는 grammar-constrained generation을 꽤 잘 이해한다고 생각했는데 (llama.cpp grammar 구현에 몇 가지 기여도 했음), 그래도 이 가이드에서 새로운 통찰을 얻었음
구조화된 출력은 LLM 엔진의 가장 과소평가된 기능 중 하나라고 생각함. 문법 제약 덕분에 LLM을 더 큰 파이프라인(예: tool-calling agent)의 일부로 안정적으로 사용할 수 있음
출력이 의미적으로 틀릴 수는 있어도 문법적으로는 항상 올바름. 특히 로컬 모델을 사용할 때 이 점이 매우 중요함
예를 들어 Jart의 Raspberry Pi 기반 스팸 필터 예시처럼, TinyLlama 모델에 "yes" 또는 "no"만 출력하도록 grammar를 적용하면, 작은 하드웨어에서도 안정적으로 동작함
모델이 다른 출력을 내고 싶을 때는 어떻게 되는지, llamafile 내부에서 처리하는 게 나은지 아니면 외부 래퍼에서 하는 게 나은지 궁금함. 재시도 설정이나 JSON 범위 지정은 어떻게 하는지도 알고 싶음
Outlines가 스택 내에서 정확히 어떤 역할을 하는지 잘 모르겠음. 대형 모델 제공자들이 제공하는 structured output API와 비슷한 건지, 혹은 BAML 같은 프로젝트와 비교할 수 있는지 궁금함
DFybOGeGDS 논문의 canonical filtering 부분이 pretokenization을 고려하지 않은 것 같음. pretokenization regex를 실제로 반영한 canonical generation 연구가 있는지 알고 싶음
“다른 참고자료”라더니 이미 가이드에 다 있는 라이브러리 목록을 다시 나열한 것 같음
정말 보물창고 같음. Automata 기반 제약은 흥미로운 주제임
잘 정리된 가이드임. Guidance & llguidance 최적화에 대해 더 알고 싶다면 우리가 작성한 짧은 논문을 참고하면 좋음
논문을 읽은 저자 중 한 명임. 특히 dense token mask를 위한 slicing 구현이 인상적이었음
이 가이드는 사람들이 주로 쓰는 두 가지 방법을 잘 다룸. 다만 constrained generation은 원래 LLM의 분포와 달라질 수 있음
예를 들어 LLM이 긴 구조적 객체를 생성할 때 ‘…’ 같은 패턴을 선호하는데, 제약된 생성은 이를 강제로 닫는 따옴표 등으로 보정해 오히려 잘못된 결과를 낼 수 있음
반면 resampling은 유효한 결과가 나올 때까지 반복하므로 더 안정적임
또 schema 오류를 문맥에 추가해가며 길이를 늘리는 것보다, 단순히 재시도하는 편이 품질과 비용 면에서 낫다고 생각함
하이브리드 접근도 가능함. 먼저 비제약 생성(unconstrained)을 시도하고, 실패한 경우에만 제약 생성(constrained)을 적용하는 방식임
SoTA 모델(Opus, Gemini 등)이 여전히 output schema enforcement가 필요한지 궁금함
요즘 모델들은 JSON이나 코드 생성 시 거의 문법 오류가 없는데, 내부적으로는 여전히 schema 검증을 하는지 알고 싶음
작은 모델에는 구조화된 생성이 필요하다는 건 이해함
스키마가 복잡할수록 LLM이 카운팅에 약하기 때문에 여전히 유용함. 모델이 좋아졌어도 확률적 특성 때문에 완벽하지 않음
최신 모델도 종종 json\n 같은 불필요한 토큰을 붙이는 경우가 있어서, 여전히 JSON 응답 스키마를 지정하는 게 안전함
구조화된 출력을 강제하면 성능 저하가 생김. 경우에 따라 2~3배 느려질 수 있음. 상황에 따라 감수할 만한 비용인지 판단해야 함
정말 놀라운 가이드임. 1년 전에 이런 자료가 있었다면 좋았을 것 같음. 주변 사람들에게 꼭 공유할 예정임
Hacker News 의견들
정말 아름다운 가이드임. 여러 페이지의 탭 전환 애니메이션이 특히 마음에 들었음
나는 grammar-constrained generation을 꽤 잘 이해한다고 생각했는데 (llama.cpp grammar 구현에 몇 가지 기여도 했음), 그래도 이 가이드에서 새로운 통찰을 얻었음
구조화된 출력은 LLM 엔진의 가장 과소평가된 기능 중 하나라고 생각함. 문법 제약 덕분에 LLM을 더 큰 파이프라인(예: tool-calling agent)의 일부로 안정적으로 사용할 수 있음
출력이 의미적으로 틀릴 수는 있어도 문법적으로는 항상 올바름. 특히 로컬 모델을 사용할 때 이 점이 매우 중요함
예를 들어 Jart의 Raspberry Pi 기반 스팸 필터 예시처럼, TinyLlama 모델에
"yes"또는"no"만 출력하도록 grammar를 적용하면, 작은 하드웨어에서도 안정적으로 동작함정말 훌륭한 가이드임. 나는 박사 과정에서 structured generation 연구를 했는데, 관심 있는 사람들을 위해 몇 가지 자료를 공유함
라이브러리로는 Outlines, Guidance, XGrammar가 있음
논문으로는 Efficient Guided Generation for Large Language Models, Automata-based constraints for language model decoding, Pitfalls, Subtleties, and Techniques in Automata-Based Subword-Level Constrained Generation를 추천함
블로그 글로는 LLM Decoding with Regex Constraints과 Coalescence: making LLM inference 5x faster가 있음
잘 정리된 가이드임. Guidance & llguidance 최적화에 대해 더 알고 싶다면 우리가 작성한 짧은 논문을 참고하면 좋음
이 가이드는 사람들이 주로 쓰는 두 가지 방법을 잘 다룸. 다만 constrained generation은 원래 LLM의 분포와 달라질 수 있음
예를 들어 LLM이 긴 구조적 객체를 생성할 때 ‘…’ 같은 패턴을 선호하는데, 제약된 생성은 이를 강제로 닫는 따옴표 등으로 보정해 오히려 잘못된 결과를 낼 수 있음
반면 resampling은 유효한 결과가 나올 때까지 반복하므로 더 안정적임
또 schema 오류를 문맥에 추가해가며 길이를 늘리는 것보다, 단순히 재시도하는 편이 품질과 비용 면에서 낫다고 생각함
SoTA 모델(Opus, Gemini 등)이 여전히 output schema enforcement가 필요한지 궁금함
요즘 모델들은 JSON이나 코드 생성 시 거의 문법 오류가 없는데, 내부적으로는 여전히 schema 검증을 하는지 알고 싶음
작은 모델에는 구조화된 생성이 필요하다는 건 이해함
json\n같은 불필요한 토큰을 붙이는 경우가 있어서, 여전히 JSON 응답 스키마를 지정하는 게 안전함구조화된 출력을 강제하면 성능 저하가 생김. 경우에 따라 2~3배 느려질 수 있음. 상황에 따라 감수할 만한 비용인지 판단해야 함
정말 놀라운 가이드임. 1년 전에 이런 자료가 있었다면 좋았을 것 같음. 주변 사람들에게 꼭 공유할 예정임
좋은 가이드임. 특히 masked decoding 다이어그램이 마음에 듦
JSON보다 더 신뢰성 있고 파싱이 쉬운 출력 포맷이 있을지 궁금함. YAML이나 TOML은 각각 단점이 있지만, 토큰 수나 비용 면에서 나을 수도 있을 것 같음
문서/쿡북 페이지의 기술 스택이 궁금함. MkDocs나 GitBook 같지 않은데, 어떤 걸 썼는지 알고 싶음