작업, 대상, 한도 정하기
팀에서 잘 아는 작업 하나를 정하세요. 절차 찾기, 회의록 요약, 초안 작성 등이 좋습니다. 첫 결과물은 각 질문, 원시 답변, 기대 출처, 사람의 판정을 모은 표로 만들 수 있습니다.
정보가 없을 때의 동작을 정하세요. 추가 설명을 요청하거나 정보 부재를 알리도록 합니다. 해당 분야를 잘 알고 수용 여부를 결정할 담당자를 지정하세요. 답변을 검증할 사람이 없다면 테스트로 유의미한 결론을 내릴 수 없습니다.
질문을 고르기 전에 문서 안정화하기
필요하고 허용된 문서를 준비하세요. 중복을 제거하고, 유효한 버전을 파악하며, 모순되는 부분을 찾아내세요. 각 문서에 식별자를 부여하고 기대되는 구절의 위치를 기록해 두세요.
Transformers는 문맥에서 추출한 답변과 문맥을 바탕으로 생성한 답변을 구분합니다. 두 경우 모두 올바른 구절이 실제로 제공되었는지 확인하세요. 파일을 폴더에 넣었다고 해서 소프트웨어가 파일을 모두 읽었거나 올바르게 선택했다는 뜻은 아닙니다.
가상 코퍼스와 스무 개의 테스트 질문
장비 대여 워크숍을 위한 가상 연습: PA와 PB가 유일한 출처이며, BriefGPU 서비스와는 무관합니다. 이 문서들을 어시스턴트에게 제공하고, 기대 답변을 알려주지 않은 채 각 질문을 던지세요.
PA — 사진 키트. 수령 최소 2일 전에 이름, 수령 날짜, 반납 날짜를 적어 양식을 보내세요. Louise가 예약을 확정합니다. 키트에는 기기 1대와 배터리 2개가 들어 있습니다. 수령 및 반납은 A 카운터에서, 월요일부터 금요일까지: 수령은 9시부터 12시까지, 반납은 17시 이전까지입니다. 반납 시 직원이 물품 수를 확인합니다.
PB — 오디오 키트. 수령 최소 하루 전에 이름, 수령 날짜, 반납 날짜를 적어 양식을 제출하세요. Malik이 예약을 확정합니다. 키트에는 마이크와 헤드폰이 포함되어 있습니다. 수령 및 반납은 B 카운터에서 월요일부터 금요일까지 가능하며, 수령은 14시부터 17시까지, 반납은 17시 전까지입니다. 직원이 반납 시 물품 수를 확인합니다.
질문 1~5는 사실 확인, 6~10은 절차 비교, 11~15는 추가 설명이 필요한 경우, 16~20은 정보가 없는 경우에 관한 것입니다. 충실한 바꿔 말하기는 인정하세요. 출력을 사람이 수정한 것은 모델의 성공으로 치지 않습니다.
| N° | 던질 질문 | 기대 답변 또는 동작 |
|---|---|---|
| 1 | 사진 키트는 누가 확정하나요? | PA에 따르면 Louise입니다. |
| 2 | 사진 키트에는 무엇이 들어 있나요? | PA에 따르면 카메라 한 대와 배터리 두 개입니다. |
| 3 | 오디오 키트는 어디에서 수령하나요? | PB에 따르면 B 카운터입니다. |
| 4 | 오디오 키트는 몇 시까지 반납해야 하나요? | PB에 따르면 월요일부터 금요일까지 17시 이전입니다. |
| 5 | 사진 키트를 예약하려면 어떤 항목을 적어야 하나요? | PA에 따르면 이름, 수령일, 반납일입니다. |
| 6 | 두 양식은 같은 정보를 요구하나요? | 네. PA와 PB 모두 이름과 수령일, 반납일을 요구합니다. |
| 7 | 어느 키트가 더 미리 신청해야 하나요? | 사진: 역일 기준 이틀, 오디오는 하루입니다. |
| 8 | 공통된 확인 절차와 반납 시간은 무엇인가요? | 품목 확인, 월요일부터 금요일까지 17시 이전 반납. |
| 9 | 같은 사람이 두 예약을 모두 확정하나요? | 아니요. 사진은 Louise, 오디오는 Malik입니다. |
| 10 | 화요일 10시에 A 카운터에서 두 키트를 모두 수령할 수 있나요? | 아니요. 사진은 A에서 9시부터 12시까지, 오디오는 B에서 14시부터 17시까지입니다. |
| 11 | 키트 확정은 누구에게 물어야 하나요? | 사진 키트인지 오디오 키트인지 먼저 물어봅니다. |
| 12 | 제 키트는 어느 카운터로 가야 하나요? | 어떤 키트인지 물어봅니다. |
| 13 | 화요일 15시에 제 키트를 수령할 수 있나요? | 키트를 확인합니다. 오디오는 가능, 사진은 시간대 밖입니다. |
| 14 | 제 키트에는 무엇이 들어 있어야 하나요? | 나열하기 전에 사진 키트인지 오디오 키트인지 물어봅니다. |
| 15 | 금요일에 키트를 수령하고 싶은데 하루 전이면 충분한가요? | 키트를 확인합니다. 오디오는 충분하고 사진은 부족합니다. |
| 16 | 대여 가격은 얼마인가요? | 코퍼스에는 가격이 나오지 않습니다. |
| 17 | 반납이 늦으면 어떤 페널티가 적용되나요? | 어떤 페널티도 문서화되어 있지 않으니 임의로 만들어내지 마세요. |
| 18 | 카메라 해상도는 어떻게 되나요? | 이 사양은 PA에 없습니다. |
| 19 | 다른 사람이 대신 장비를 수령할 수 있나요? | 제3자가 대신 수령할 수 있는지 여부는 명시되어 있지 않습니다. |
| 20 | Louise가 자리에 없을 때는 누가 대신하나요? | 대체 인력은 안내되어 있지 않습니다. |
구성을 확정하고 한 번의 요청으로 시작하기
호환되는 모델과 도구를 고른 뒤 그 버전과 라이선스를 확인하세요. 지시문, 문서 선택, 설정을 기록해 두세요. Transformers에서 max_new_tokens는 새로 생성되는 토큰 수를 제한하고, 샘플링은 출력 선택에 영향을 줍니다. 이 매개변수들을 그대로 유지하면 실행 간 결과를 비교할 수 있습니다.
필요한 메모리는 모델 파일만으로 결정되지 않습니다. 작업 데이터와 생성 캐시도 공간을 차지합니다. Transformers는 특히 컨텍스트가 길어질 때 캐시 비용을 설명합니다. 먼저 한 번의 요청으로 시작한 뒤 가장 긴 입력을 확인하세요.
사용자 수와 응답 길이를 동시에 늘리면 품질과 처리 용량이 뒤섞입니다. 24GB, 48GB, 80GB라는 기준이 특정 모델이나 여러 요청이 반드시 들어간다는 것을 보장하지는 않습니다.
예시 살펴보기: 두 가지 절차, 열여섯 개의 승인된 응답
위 기준표로 두 절차 PA와 PB를 평가한다고 가정해 봅시다. 출처와 기대 동작을 지킨 응답은 통과로 봅니다. 따라서 확인을 요청하는 것도 성공일 수 있습니다.
이 표는 가상의 예시입니다. 표를 만들기 위해 어떤 모델도 실행되지 않았습니다. 스무 개 중 열여섯 개가 승인되어 이 특정 집합에서는 80%를 보이지만, 다른 요청에서의 신뢰도를 추정한 것은 아닙니다. 지어낸 규칙 하나가 불완전한 응답보다 더 큰 비중을 차지할 수 있습니다.
이 시나리오에서 팀은 먼저 날조와 모호함을 살펴봅니다. 누락된 구절은 선택을 다시 검토해야 함을 뜻하고, 구절은 있지만 잘못 해석된 경우는 지시문이나 모델 쪽 문제를 가리킵니다. 메모리를 늘린다고 이런 오류가 자동으로 해결되지는 않습니다.
| 계열별 각 5문항 | 통과 | 검토 필요 |
|---|---|---|
| 단순 정보 | 5 | 이 예시에는 없음. |
| 유사 표현 | 4 | 부분적인 응답 하나. |
| 모호한 요청 | 3 | 근거 없는 가정 하나와 불필요한 거부 하나. |
| 누락된 정보 | 4 | 만들어낸 규칙 하나. |
| 합계 | 20개 중 16개 | 미통과 4건. |
각 판정의 이유를 설명하는 기록 남기기
원본 응답, 제공된 구절, 참조, 판정과 그 사유를 보관하세요. 문서를 잘못 고른 경우, 해석이 틀린 경우, 형식이 맞지 않는 경우를 구분하세요. "모델이 가끔 틀린다"는 식으로는 어떤 수정이 필요한지 알 수 없습니다.
다음으로 관찰된 소요 시간과 검토 작업량을 평가하되, 최초 로딩과 이후 실행을 구분하세요. 생성 결과가 달라지면 어려운 질문 몇 개를 반복하고 모든 출력을 보관하세요. 가장 좋은 것만 고르면 실패가 가려지고, 같은 입력만 반복하면 모든 실제 상황을 포괄하지 못합니다.
- 질문의 식별자와 정확한 문구.
- 문서 버전과 실제로 제공된 구절.
- 원본 응답과 표시된 참조.
- 사람의 판정과 간단한 근거.
- 실험 구성과 소요 시간 또는 메모리 관찰 내용.
변수 하나를 고친 뒤 잘 되던 것도 점검하기
문서, 구절 선택, 지시문, 모델 중 식별 가능한 변수 하나를 바꾸세요. 실패한 항목과 이미 통과한 여러 질문을 다시 실행하세요. 수정이 다른 사례를 나쁘게 만들 수 있으니 이전 출력을 보관해 두세요.
표에 있는 모든 응답을 포함할 때까지 지침을 조정하지 마세요. 그런 다음 새로운 질문 몇 가지를 준비하세요. 이 질문들은 이미 알고 있는 스무 개의 표현을 넘어서도 그 수정이 필요를 충족하는지 확인해 줍니다. 이 점검은 그 자체의 조건에 한정됩니다.
다음 단계를 정하고 테스트 기록을 챙기기
명확한 범위를 두고 결론을 내리세요. 참조 찾기, 검토할 초안 작성, 확인 요청 등입니다. 제외된 사례를 명시하세요. 성공한 데모가 회사 전체에 대해 올바른 응답을 보장하지는 않습니다.
감독 아래 시험을 이어가거나, 특정 원인 하나를 고치거나, 검토 비용이 원래 작업보다 크다면 중단하세요. 여러 요청을 동시에 처리하기 전에 개별 경로를 검증하고, 변화를 파악할 수 있도록 잘 아는 하위 집합을 보관하세요.
승인된 문서, 그리드, 출력물, 설정, 결정을 저장하세요. 대여는 생성뿐 아니라 평가와 복구까지 포괄해야 합니다. BriefGPU는 도구와 처리 방식을 고객이 선택하도록 하며 그 내용을 검사하지 않습니다. 결과에 대한 통제는 여전히 고객의 몫입니다.