“프롬프트·학습데이터·LLM 모델 성능(아키텍처/규모)” 3요소 관점은 **부분적으로는 맞지만, 업계/연구에서 널리 쓰는 프레임으로는 ‘불충분’**한 편이야.
보통은 성능을 **(1) 모델, (2) 데이터, (3) 학습(알고리즘/최적화), (4) 추론(디코딩/툴/컨텍스트), (5) 프롬프트/시스템, (6) 평가(벤치/지표)**처럼 더 분해해서 봐. 아래에 “적절성 판단”과 “다양한 분석 관점(널리 통용)”을 결과 위주로 정리해줄게.
1) 3요소 관점(프롬프트·데이터·모델)이 적절한가?
적절한 점(왜 많이들 이렇게 말하나)
- 현업에서 성능 문제의 가장 큰 레버를 빠르게 설명하기 좋음
- 프롬프트(입력 설계)로 즉시 개선
- 데이터(학습/파인튜닝/RAG 코퍼스)로 도메인 적합성 개선
- 모델(더 강한 베이스/더 큰 모델/더 좋은 계열)로 상한선 상승
한계(이 3개만으로는 설명이 안 되는 부분)
- 학습(Training) 방법(예: SFT/RLHF/DPO, optimizer, schedule, 정규화, 데이터 혼합 비율) 차이가 큰데 3요소에 명시적으로 안 잡힘
- 추론(Inference) 설정(temperature/top-p, 길이 제한, self-consistency, reranking, tool-use, 컨텍스트 길이)만 바꿔도 성능이 크게 바뀜
- 평가(Evaluation) 설계가 다르면 “성능”의 의미가 달라짐(정확도 vs 안정성/편향/환각/비용/지연)
- 실제 제품에서는 RAG/툴/메모리/가드레일 등 “시스템”이 모델보다 성능을 좌우하는 경우가 흔함
결론: 3요소는 입문/커뮤니케이션용으로는 타당, 하지만 “성능 원인 분석”이나 “개선 로드맵”으로는 항목이 부족하다고 보는 게 널리 통용되는 관점이야.
2) 널리 통용되는 분석 프레임(관점)들
A. 스케일링 법칙(Scaling laws) 관점: 성능은 모델·데이터·컴퓨트의 함수
- 연구 커뮤니티에서 매우 널리 인용되는 프레임: 성능은 모델 파라미터 수, 데이터 토큰 수, 학습 컴퓨트에 대해 power-law로 개선.
- 특히 “무작정 모델만 키우기 vs 데이터도 같이 키우기” 논쟁에서 많이 씀.
- Kaplan 계열(2020)과 Chinchilla(Hoffmann et al., 2022) 이후 “데이터를 충분히 먹여야” 같은 얘기가 일반화됨.
- 너의 3요소 중 “모델/데이터”는 들어가지만, 컴퓨트/학습 셋업이 빠져서 설명력이 줄어듦.
참고(스케일링 법칙 개요/리뷰):
- Epoch AI: Scaling laws literature review https://epoch.ai/blog/scaling-laws-literature-review
- (Kaplan/Chinchilla 요약 강의 슬라이드) UMD Scaling laws PDF https://www.cs.umd.edu/~miyyer/cs685/slides/scaling_laws.pdf
B. “모델 개발 관점” 4~6분해: Model / Data / Training / Inference(+Prompting) / Evaluation
현업·연구 모두에서 원인분석할 때 많이 쓰는 분해야.
- Model: 아키텍처, 파라미터, 컨텍스트 길이, 토크나이저 등
- Data: 사전학습 코퍼스 품질/중복/오염, 지시튜닝 데이터, 도메인데이터, RAG 지식베이스
- Training: 학습 목표, RLHF/DPO, 하이퍼파라미터, 데이터 믹스, 안전튜닝
- Inference: 디코딩 전략, 샘플링, rerank, self-consistency, tool calling, 시스템 프롬프트
- Prompting: 프롬프트 템플릿, 예시, 역할/제약, 구조화 출력
- Evaluation: 벤치마크 선택, 오염(benchmark leakage), 자동평가 vs 사람평가, 지표(정확/비용/지연/안전)
“프롬프트·데이터·모델”은 이 중 일부만 잡는 셈이라, 성능 영향요인 전체를 설명하는 ‘표준’에 가깝진 않다고 보는 게 자연스러움.
평가 프레임워크/벤치(널리 인용):
- Stanford HELM(홀리스틱 평가) https://crfm.stanford.edu/helm/
- “하나의 점수”가 아니라 다양한 시나리오/지표로 보는 관점이 확산된 근거 중 하나.
C. “LLM 시스템(제품) 관점”: 모델보다 파이프라인이 성능을 좌우
요즘 실무에서 특히 강함.
- 성능 = LLM + RAG(검색/인덱싱/리랭킹) + 툴 실행 + 프롬프트 템플릿 + 후처리/검증 + 가드레일 + 캐시/메모리
- 여기서는 “학습데이터”보다 운영 데이터(지식베이스)품질이나 검색 품질이 더 큰 병목이 되기도 함.
D. 평가/측정 관점(“성능”의 정의를 먼저 고정)
“성능에 영향을 끼친다”를 말하려면, 무엇을 성능으로 보는지(정확도/환각/견고성/편향/비용/지연)를 고정해야 한다는 관점이 널리 퍼져있어.
- 예: temperature를 올리면 창의성은 늘지만 사실성은 떨어질 수 있음 → 단일 성능축이 아님
참고(평가 실무 가이드류 예시):
- Microsoft 평가 지표 목록(개요) https://learn.microsoft.com/en-us/ai/playbook/technology-guidance/generative-ai/working-with-llms/evaluation/list-of-eval-metrics
- HELM도 같은 맥락(다차원 평가)
3) 네가 본 자료를 “적절하게” 만들려면(권장 수정안)
3요소를 유지하되, 보통은 이렇게 보강하면 통용성이 올라가:
- (권장) 모델 / 데이터 / 학습(컴퓨트 포함) / 추론·프롬프트 / 평가
- 프롬프트는 추론단(inference)과 함께 묶는 경우가 많음(“test-time compute/strategy”)
RAG QA / 사내 이메일·업무자료 기반 “자료작성·반박자료 작성” 기준으로, 성능(정확성·근거성·재현성)에 가장 큰 영향 레버 Top 5는 보통 아래 순서로 잡히는 경우가 많아.
Top 5 레버
- 지식베이스 품질(원문 품질/정규화/권한)
- 최신본/정본(source of truth) 정리, 중복·버전 혼재 제거, 문서 메타데이터(작성일/부서/프로젝트/보안등급) 확실히.
- “답이 틀림”의 상당수가 모델 문제가 아니라 원문이 애매/상충/구버전이라 생김.
- 검색(Retrieval) 품질: 인덱싱·청킹·쿼리·리랭킹
- 청크 단위(너무 크면 잡음, 너무 작으면 문맥 손실), 섹션 기반 청킹, 표/메일 스레드 처리.
- 하이브리드 검색(BM25+벡터), 리랭커 적용, top-k/score threshold 튜닝이 체감 성능을 크게 좌우.
- 근거-중심 생성 규칙(프롬프트/출력 포맷)
- “문서 근거 없으면 모른다고 말하기”, “각 주장 옆에 인용(문서명/날짜/섹션/링크) 붙이기”, “반박은 상대 주장→반박근거→리스크 순서”처럼 템플릿을 강제.
- 환각을 줄이고, 검토·승인 프로세스가 쉬워짐.
- 컨텍스트 구성(무엇을 넣고 무엇을 버릴지)
- top-k를 무작정 늘리기보다: 중복 제거, 서로 상충 문서 동시 제시, “최신/권한 높은 문서 우선” 같은 정책.
- 이메일/업무자료는 특히 시간순/스레드 구조를 유지해서 넣는 게 효과 큼.
- 평가·피드백 루프(정답 기준/테스트셋/관측)
- 자주 나오는 질문/자료작성 시나리오 50~200개만이라도 골드셋(정답+근거문서) 만들어 회귀테스트.
- 실패 유형(검색 실패 vs 근거는 있는데 요약 실패 vs 상충 처리 실패)을 태깅하면 개선 속도가 확 빨라짐.
댓글
댓글 쓰기