전체 글 (411) 썸네일형 리스트형 Kubernetes Probe 완전정리 — Liveness·Readiness·Startup 설계와 흔한 오설정 CrashLoopBackOff를 파고들다 보면 결국 probe에 도착합니다. 앱은 멀쩡한데 kubelet이 계속 죽이고 있거나, 반대로 죽은 앱에 트래픽이 계속 꽂히고 있거나. 앞선 글에서 재시작 루프와 OOM을 다뤘지만, 재시작을 유발하는 쪽은 정작 정리하지 않았습니다. 이 글이 그 자리를 채웁니다. 세 probe의 역할 차이부터 필드 기본값, 실무에서 반복되는 오설정, 종료 흐름과의 상호작용까지 한 번에 정리합니다.핵심 요약세 probe는 각각 다른 질문에 답합니다. Liveness는 "죽었나", Readiness는 "지금 받아도 되나", Startup은 "아직 뜨는 중인가"입니다. 하나로 뭉치면 반드시 사고가 납니다.Liveness probe에 의존성 확인을 넣지 마십시오. DB가 흔들리면 전체 파.. RAG 평가 파이프라인 — 골든 셋 구축과 회귀 테스트 앞선 글들에서 하이브리드 검색, 리랭커, 임베딩 모델 선택을 다루면서 매번 같은 말로 끝맺었습니다. "골든 셋으로 측정하고 도입하십시오." 그런데 그 골든 셋을 어떻게 만드는지는 한 번도 쓰지 않았습니다. 이 글이 그 빚을 갚습니다. 질문 100개를 어디서 구하고, 정답을 어떻게 붙이고, 그걸 어떻게 CI에 넣어 다음 배포가 검색 품질을 깎아먹는 순간 빨간불이 켜지게 만드는지 — 처음부터 끝까지 정리합니다.핵심 요약평가 파이프라인이 없으면 RAG 튜닝은 되돌아옵니다. 지난주에 좋아 보였던 변경이 이번 주 변경으로 상쇄되는데 아무도 모릅니다.검색과 생성을 반드시 분리해 측정하십시오. 최종 답변만 보면 검색이 못 가져온 건지 LLM이 못 읽은 건지 구분할 수 없습니다.골든 셋은 50개면 시작할 수 있고, 1.. vLLM Structured Outputs 완전정리 — JSON Schema·Regex·Grammar로 출력 형식 강제하기 LLM에 "JSON으로만 답해"라고 아무리 강하게 써도 열 번에 한 번은 앞에 설명이 붙거나 마지막 중괄호가 빠집니다. 파서는 그 한 번에 터지고, 재시도 로직이 붙고, 재시도가 또 실패합니다. 프롬프트로는 형식을 보장할 수 없습니다. 형식은 요청 사항이 아니라 디코딩 단계에서 강제해야 하는 제약이기 때문입니다. vLLM의 Structured Outputs는 바로 그 지점을 건드립니다. 이 글은 다섯 가지 제약 방식, 백엔드 선택, 스키마 함정, 성능 비용을 실전 기준으로 정리합니다.핵심 요약구조화 출력은 프롬프트 기법이 아니라 로짓 마스킹입니다. 매 토큰마다 문법상 불가능한 토큰을 후보에서 제거하므로 형식 위반이 구조적으로 불가능해집니다.제약은 다섯 가지입니다 — choice, regex, json, .. 이전 1 2 3 4 ··· 137 다음