Llm

LLM의 컨텍스트 윈도우는 계속 커지고 있습니다. 그런데 실무에서는 이상한 장면이 자주 나옵니다. 자료를 더 많이 넣었는데 답이 더 좋아지기는커녕, 엉뚱한 파일을 집거나 이미 결정한 사항을 다시 뒤집는 경우입니다. 이 현상을 최근 실무권에서는 컨텍스트 로트(context rot) 라는 말로 자주 부릅니다. 중요한 점은 이 표현이 엄밀한 학술 용어라기보다, 긴 문맥이 쌓일수록 모델의 주의력과 일관성이 서서히 망가지는 현상을 묶어 부르는 실무 용어라는 점입니다. 더보기

로컬 LLM을 이야기할 때 대부분의 출발점은 Ollama입니다. 설치가 간단하고 바로 써볼 수 있기 때문입니다. 그런데 이번 영상은 질문 자체를 바꿉니다. 내 PC에서 모델이 돌아가느냐 가 아니라, 여러 요청을 계속 받아내는 서빙 엔진으로도 효율적인가 를 봐야 한다는 것입니다. 영상은 vLLM의 강점이 바로 그 지점, 즉 KV Cache 메모리 관리와 다중 요청 스케줄링에서 나온다고 설명합니다. 근거 영상 중요한 것은 숫자를 그대로 외우는 것이 아니라, 왜 어떤 환경에서는 차이가 거의 없고 어떤 환경에서는 크게 벌어지는지 를 이해하는 것입니다. 영상 도입부는 Red Hat의 2025년 8월 8일 벤치마크를 인용해 vLLM의 높은 TPS와 낮은 지연시간을 언급하지만, 뒤에서 보여주는 자체 테스트에서는 단일 요청에서는 큰 차이가 없고 동시 요청 환경에서 우위가 커진다고 정리합니다. 이 글은 바로 그 차이를 만든 구조를 따라가 보려는 글입니다. 근거 영상 더보기

2026년 3월 20일 OpenAI Developers에 올라온 Designing delightful frontends with GPT-5.4 의 핵심은 단순히 “GPT-5.4가 더 예쁜 화면을 만든다"가 아닙니다. 더 정확히는, GPT-5.4는 이미지를 보고 판단하고, UI를 구현하고, 다시 실행해 검증하는 루프 가 이전보다 훨씬 자연스러워졌고, 그 루프를 살리는 프롬프트 구조가 따로 있다는 이야기입니다. 이 글은 같은 달 3월 5일 공개된 Introducing GPT-5.4 와 함께 읽으면서, OpenAI가 왜 시각 참조, 디자인 제약, 낮은 reasoning, 실제 콘텐츠, Playwright 검증을 한 세트로 묶어 이야기하는지 정리합니다. 포인트는 “길게 지시하면 잘 만든다"가 아니라, 좋은 프런트엔드가 나오도록 작업면 자체를 설계하는 것 입니다. 더보기

LLM 기능을 제품에 붙이기 시작하면 금방 같은 문제가 반복됩니다. 프롬프트가 정말 좋아졌는지, 모델을 바꾸면 회귀가 생기는지, RAG나 에이전트가 위험한 입력에서 무너지는지, 이 세 가지를 사람 눈으로만 계속 확인하기가 어렵습니다. Promptfoo 는 바로 이 지점을 겨냥합니다. 프롬프트 품질 평가와 보안 레드팀을 YAML 설정과 CLI 중심으로 묶어서, “감으로 확인하는 LLM 개발"을 “반복 가능한 테스트"로 바꾸는 도구입니다. 이 글에서는 Promptfoo를 단순한 프롬프트 비교기가 아니라, eval 과 redteam 이라는 두 개의 운영 루프를 가진 LLM 테스트 하니스 로 보는 관점으로 정리합니다. 더보기

OpenRAG는 문서 지식 기반 AI 응용 프로그램을 구축하기 위한 종합적인 RAG(Retrieval-Augmented Generation) 플랫폼입니다. Langflow의 시각적 워크플로우 빌더, OpenSearch의 확장 가능한 검색 엔진, Docling의 강력한 문서 처리 기능을 하나로 통합하여 개발자가 복잡한 RAG 시스템을 신속하게 구축할 수 있도록 지원합니다. 이 글에서는 OpenRAG의 핵심 아키텍처, 주요 기능, 그리고 실제 구현 방법을 살펴보겠습니다. 더보기

Chain-of-Thought(CoT) 는 정확도를 올리지만, 추론 토큰이 길어질수록 지연과 비용이 함께 증가합니다. 이 논문은 이 문제를 “모델 가중치"가 아니라 “시스템 프롬프트"에 추론 규칙을 컴파일하는 방식으로 풀며, 이를 Prompt-Level Distillation(PLD) 이라고 정의합니다 (근거: https://arxiv.org/html/2602.21103v1#S1, https://arxiv.org/html/2602.21103v1#S3). 더보기

당신이 회사에서 가장 비싼 고액 연봉의 컨설턴트를 고용했다고 상상해보세요. 그런데 100페이지짜리 방대한 PDF 문서를 그 컨설턴트 앞에 던져주며 “이걸 읽고 요약해줘"라고 요청합니다. 비싼 시간당 비용을 내면서 말이죠. 이것이 지금 대부분의 AI 서비스가 범하고 있는 실수입니다. 대용량 파일을 고성능 AI 모델에 직접 업로드하면 비용은 폭등하고, 정작 중요한 핵심 내용은 누락되기 쉽습니다. 더 나은 방법이 있습니다. 두 개의 AI 시스템을 역할 분담시키는 것입니다. 저렴하고 빠른 AI가 파일을 읽고 요약하면, 고성능 AI가 그 요약만 받아서 정확한 답변을 제공합니다. 이 글에서는 왜 파일 직접 업로드가 문제인지, 그리고 두 개의 AI를 활용해 비용을 절감하고 성능을 향상시키는 구체적인 방법을 소개합니다. 더보기