프롬프트·RAG·파인튜닝 선택: 답변 실패 원인으로 판단하는 방법

프롬프트, RAG, 파인튜닝 중 무엇을 고를지는 지금 답변이 왜 틀리는지를 보고 정하는 게 맞습니다. 지시나 예시가 불명확하면 프롬프트를 고치고, 답에 필요한 외부 근거가 부족하면 RAG를 검토하세요. 작업이 명확하고 정답 데이터를 확보할 수 있다면 파인튜닝으로 반복 작업을 학습시키는 방안도 고려할 만합니다. 어느 기술이 더 낫냐는 질문으로 시작하면 방향을 잡기 어려워요.

세 방법은 서로 배타적이지 않습니다. 검색한 자료를 프롬프트에 넣고, 그 자료를 활용하는 작업을 파인튜닝으로 학습시키는 구성도 가능하거든요. 그래서 저는 더 복잡한 기술로 넘어가기 전에 실패한 답변부터 들여다보길 권합니다. 모델이 지시를 오해했는지, 근거를 받지 못했는지, 근거가 있는데도 작업을 해내지 못했는지에 따라 다음 실험이 완전히 달라지기 때문이에요.

세 방법은 각각 무엇을 바꾸나요

프롬프트는 재학습 없이 지시·예시·문맥을 바꾸는 방법입니다. 출력 형식이나 판단 기준이 모호하다면 가장 먼저 손볼 곳이 여기예요. RAG는 질문과 관련된 외부 자료를 검색해 모델 입력에 덧붙이는 방식이라, 사내 문서를 바탕으로 답해야 할 때 후보에 오릅니다. 다만 문서가 작고 입력 한도 안에 들어온다면 전체 문서를 그냥 넣어 주는 방식과도 비교해 보세요.

흔히 놓치는 부분이 있는데, 검색을 붙였다고 프롬프트 설계가 끝나지는 않습니다. 근거를 우선하라는 지시, 자료가 부족하거나 서로 충돌할 때 어떻게 처리할지에 대한 규칙은 여전히 필요해요. Microsoft의 RAG 프롬프트 문서도 관련 자료를 찾은 뒤의 지시 설계를 따로 다루고 있습니다.

이 글에서 말하는 파인튜닝은 정답이 붙은 데이터로 모델 가중치를 조정하는 지도 학습입니다. 말투를 맞추는 데만 쓰는 게 아니라 분류·요약·정보 추출에도 쓰이죠. 입력에 근거를 더하는 RAG와는 손대는 대상 자체가 다르다는 점을 기억해 두면 헷갈릴 일이 줄어요.

정답 근거를 직접 넣었을 때와 검색했을 때를 나눠 보세요

출발점은 실제 업무를 대표하는 질문과 기대 답변을 고정해 두는 일입니다. 답변이 그럴듯해 보이는지만으로는 나아졌는지 판단하기 어렵거든요. 반드시 들어가야 할 정보와 지켜야 할 형식도 미리 정해 두는 편이 좋습니다. 그다음 같은 모델과 현재 프롬프트를 기준으로 아래 순서대로 비교해 보세요.

1. 현재 구성의 답변을 기록해 기준 성능을 잡습니다.
2. 사람이 확인한 정답 근거를 직접 넣고 답변을 확인합니다.
3. 같은 질문에 검색 결과를 넣어 답변을 비교합니다.
4. 이후에는 지시문·제공 문맥·검색 구성 중 하나씩 바꿉니다.

이 순서를 권하는 이유는 2번과 3번의 차이가 원인을 꽤 분명하게 갈라 주기 때문이에요. 정답 근거를 직접 넣었을 때만 좋아진다면 검색 과정부터 의심할 근거가 생깁니다. 필요한 구간을 놓쳤는지, 다른 버전의 문서를 가져왔는지, 불필요한 내용이 섞였는지 확인해 보세요. 반대로 양쪽 모두 실패한다면 지시가 명확한지, 문맥을 어떻게 배치하고 활용했는지, 모델이 그 작업을 해낼 수 있는지를 점검할 차례입니다.

검색이 성공했다고 답변이 성공한 건 아니니, 둘은 따로 판단해야 해요.

오류 코드·API 이름·버전 문자열이 중요한 질문을 예로 들어 볼게요. 이런 경우 의미가 비슷한 문서는 찾았는데 정작 정답 근거는 놓칠 수 있습니다. 이럴 땐 정확한 문자열 일치를 보완해 주는 키워드 검색을 검토할 만해요. 한편 올바른 버전의 근거가 입력에 들어 있는데도 답변이 다른 버전의 설명을 따른다면, 문제는 검색이 아니라 그 이후의 생성 과정에 있습니다. 어느 쪽이든 질문 하나의 결과로 원인을 확정하지는 마세요. 고정해 둔 질문 묶음에서 같은 실패가 반복되는지 보는 쪽이 타당합니다.

파인튜닝은 언제 꺼내 들어야 할까요

프롬프트와 근거 제공을 다 조정했는데도 같은 유형의 오류가 남는다면, 그때 파인튜닝 실험을 검토합니다. 가장 먼저 볼 것은 작업이 명확한지, 정답 데이터의 품질이 괜찮은지예요. Google의 지도 파인튜닝 문서에서도 명확한 작업과 라벨 데이터를 선택 조건으로 설명합니다. 학습 데이터는 실제 서비스 입력을 반영해야 해요. 운영에서 질문과 검색 문서를 함께 넣는 구조라면 학습 데이터도 그 구성을 따르는지 따져 봐야 합니다.

비교할 때는 학습에 쓰지 않은 동일한 평가 질문을 써야 공정합니다. 답변 품질, 지연, 요청당 비용을 기록하고 별도로 드는 학습비도 계산에 넣으세요. 검색 처리와 입력 길이, 요청량까지 함께 봐야 운영 비용을 제대로 비교할 수 있습니다.

모든 작업에 통하는 최소 데이터 수나 비용 순위를 미리 정해 두기는 어렵습니다. 결국 남은 오류를 얼마나 줄였는지, 그 개선에 비용이 얼마나 들었는지로 결정하게 돼요. 이때 과거 연구에서 나온 성과를 최신 모델의 성능으로 일반화하지 않도록 주의하세요.