Local LLM 구축하기 · 18/30 · API와 문서 검색
모델을 비교할 질문을 미리 남겨 두면 교체나 업데이트 뒤에도 판단하기 편합니다. 잘 답했던 질문뿐 아니라 틀렸던 질문, 문서에 답이 없는 질문도 모아 보세요. 작은 평가표부터 만들어 검색과 답변을 따로 확인하겠습니다.
16~17편의 검색·답변 구성을 준비합니다. 자주 맡길 작업을 골라 모든 후보에 같은 질문과 자료를 사용합니다.
평가 질문 20개 만들기
| 묶음 | 문항 수 | 채점 기준 |
|---|---|---|
| 원문 요약 | 4 | 숫자·시각·고유명사 보존 |
| 정보 추출 | 4 | 필수 필드와 null 처리 |
| 문서 검색 | 4 | 정답 청크가 상위 후보에 포함 |
| 답할 수 없는 질문 | 4 | 없는 사실·전화번호를 만들지 않음 |
| 간단한 코드 수정 | 4 | 정해 둔 테스트를 실제 통과 |
개발하면서 자주 본 질문과 최종 비교에 쓸 질문을 나눠 둡니다. 학습에 사용한 문장을 그대로 평가하면 실사용 성능을 높게 볼 수 있어요. 비교할 모델에는 같은 자료와 채점 기준을 적용합니다.
채점 기준과 실행 조건
보관 기간은 14일을 맞히면 1점, 다른 수치를 만들면 0점으로 기록합니다. 문서에 없는 전화번호는 확인할 수 없다고 답해야 1점입니다. 문체 점수는 따로 둡니다. 중요한 사실을 틀린 결과를 말투 점수로 통과시키지 않습니다.
id,task,expected,model,context,passed,latency_seconds,note
backup-01,보관 기간,14일,,,,,
backup-02,담당자 전화번호,문서에 없음,,,,,
extract-01,담당자 추출,null,,,,,
search-01,백업 주기 검색,backup.txt#1,,,,,
ZIP의 CSV는 측정 결과가 들어 있지 않은 기록 양식입니다. 모델 태그와 ID, 양자화, num_ctx, 프롬프트 버전, 런타임 버전을 함께 적습니다. 비교 조건을 남겨 두어야 나중에 수치가 달라졌을 때 이유를 살펴볼 수 있습니다.
검색·생성·속도 따로 평가
Recall@k는 정답 근거가 상위 k개 안에 들어왔는지 보는 검색 지표입니다. 근거를 찾았는데 답이 틀렸다면 생성 단계와 지시를 살펴보세요. 근거부터 누락됐다면 청크나 임베딩, 키워드 검색의 조합을 먼저 검토합니다.
처음 적재하는 요청과 모델이 올라간 뒤의 반복 요청은 나눠 측정합니다. 평균과 함께 중앙값, 느렸던 구간도 남겨 보세요. 한 번만 실행했다면 단일 측정이라고 적고 작은 차이로 우열을 정하지 않습니다.
작업별 합격선
사람이 읽어 고치는 초안과 업무 시스템에 자동 입력하는 값은 허용할 수 있는 오류 범위가 다릅니다. 중요한 필드의 오류, 답하지 말아야 할 질문에 대한 답변, 인젝션에 따른 행동 변화는 따로 세어 둡니다.
평가 전에 합격선을 정합니다. 예를 들어 중요한 숫자 오류와 없는 정보 생성은 각각 0건으로 둘 수 있어요. 통과하지 못하면 모델을 바꾸는 것 외에 맡기는 작업의 범위를 줄이는 방법도 검토합니다.
참고 자료
문서·모델 태그 확인 기준: 2026년 10월 18일. 기본 실습 환경: Windows 11 x64.




답글 남기기