공부한 내용을 그냥 주제별로 모아두면 금방 흩어졌다. 그래서 이번에는 개념을 어떻게 실습 가능한 설계 기준으로 바꿀 수 있는지에 맞춰 다시 묶어봤다. 처음에는 RAG, OCR, Agent, 평가 지표를 각각 따로 봤다. 그런데 작은 예제를 직접 만들어보면 질문이 바뀐다. “이 개념이 무엇인가”보다 “이 개념을 어디에 붙여야 실패를 줄일 수 있는가”가...

LLM 서비스를 처음 볼 때는 모델 호출 API를 중심으로 생각했다. 그런데 작은 실습으로 흐름을 다시 만들어보니, 실제 차이는 모델보다 데이터 흐름, 상태 관리, 저장소 분리, 평가 위치에서 더 많이 났다. 같은 LLM을 사용해도 원문을 어떻게 보관하는지, 검색 결과를 어떻게 남기는지, 평가를 어느 단계에서 수행하는지에 따라 서비스의 신뢰도가 달라...

Agent를 공부하면서 처음에는 “LLM이 도구를 쓰면 Agent”라고 생각했다. 그런데 흐름을 직접 나눠보니 도구 호출은 시작일 뿐이었다. 실제로 중요한 것은 도구를 언제 부를지, 결과를 어떻게 검증할지, 여러 역할을 나눌 때 latency와 비용을 어떻게 감당할지였다. flowchart LR W["Workflow<br/>순서가 고...

LLM 서비스 평가를 정리하면서 남은 생각은 “평가 지표가 많다”가 아니었다. 같은 출력도 무엇을 보려는지에 따라 지표가 달라진다는 점이었다. 요약 품질을 볼 때와 업무 리포트 품질을 볼 때, RAG 답변의 근거성을 볼 때는 평가 질문이 다르다. flowchart TD O["LLM Output<br/>요약, 리포트, QA 답변"] -...

RAG 평가에서 가장 많이 헷갈린 부분은 “답변이 틀렸다”를 하나의 실패로 보는 습관이었다. 답변이 틀린 이유는 두 가지로 나뉜다. 검색이 근거를 못 찾았거나, 검색은 맞았는데 생성이 근거를 잘못 썼거나. 이 둘을 나누지 않으면 개선 방향도 흐려진다. flowchart LR Q["Question"] --> RET["Retrieval<...

금융 RAG를 보면서 계속 걸렸던 지점은 근거의 종류가 너무 다르다는 점이었다. 증권 리포트는 길고 정적이다. 뉴스는 짧고 최신성이 중요하다. 표 데이터는 숫자와 단위가 중요하고, 그래프는 추세를 담는다. 이 네 가지를 같은 chunk로 취급하면 답변은 자연스러워도 근거가 흐려진다. flowchart LR A["Analyst Report<...

RAG를 처음 볼 때는 vector DB에 문서를 넣고 질문하면 되는 구조로 이해했다. 그런데 구현 흐름을 단계별로 나눠보니 실제 품질 차이는 그 앞뒤에서 많이 났다. 문서를 어떻게 자르는지, 질문을 어떻게 바꾸는지, 검색 결과를 어떻게 재정렬하는지, 그리고 무엇을 기준으로 평가하는지에 따라 같은 LLM을 써도 결과가 달라진다. flowchart ...

처음에는 PDF 처리를 단순하게 봤다. 파일을 넣고, parser로 텍스트를 뽑고, 그 텍스트를 RAG에 넣으면 된다고 생각했다. 문서 처리 흐름을 다시 그려보면서 생각이 바뀌었다. PDF/OCR에서 어려운 지점은 “읽는 것”보다 “읽은 결과를 어떤 구조로 남길 것인가”에 있었다. 본문, 표, 그림, 수식, 페이지 번호, caption, sectio...

3.STUDY는 교육 과정이나 프로젝트에 직접 묶이지 않는 개인 학습 글을 모아두는 공간이다. 1.TIL은 수업과 과정 기반 기록, 2.PROJECT는 프로젝트 결과와 회고, 3.STUDY는 AI 엔지니어링 주제를 따로 공부하며 정리한 글로 구분한다. 카테고리 구조 3.STUDY 3-1.PYTHON 3-2.RAG 3-3....

모델 ID만 최신으로 바꿨는데 결과가 더 나빠지는 경험을 했다면, 버그가 아니다. 프롬프트를 그대로 둔 게 문제다. 2026년 상반기에 나온 Claude Opus 4.8과 GPT-5.5는 약속이라도 한 듯 같은 방향으로 진화했다. 그리고 두 회사 모두 공식 문서에서 비슷한 말을 한다 — “예전 프롬프트는 이제 오히려 방해가 된다.” 이 글의 테제는...