먼저 읽기
PDF 요약용 로컬 AI, 메모리를 사기 전에 문서부터 확인하세요
PDF를 넣었는데 엉뚱한 요약이 돌아오면 모델이 작아서 그렇다고 생각하기 쉽습니다. 그러나 표의 숫자가 추출 과정에서 뒤섞였거나 스캔 이미지가 제대로 읽히지 않은 것일 수 있습니다. 장비를 고르기 전에 문서 한 개가 답변이 되기까지의 길을 따라가 보겠습니다.
한 페이지를 복사해보는 것부터
대표 PDF에서 문장과 표가 함께 있는 페이지를 골라 텍스트 편집기에 복사해보세요. 읽는 순서가 자연스럽고 숫자가 원래 항목 옆에 남아 있는지 확인합니다. 복사가 안 되는 스캔 문서라면 OCR이나 시각 입력을 처리하는 경로가 필요할 수 있습니다. 이 단계가 잘못되면 뒤에서 모델을 바꿔도 없는 문장을 복구해주지는 못합니다. 특히 금액과 날짜가 중요한 자료는 요약 문장의 자연스러움보다 추출된 숫자의 정확성을 먼저 봐야 합니다. 민감한 원문 대신 구조가 비슷한 공개 자료로 초기 설정을 시험하면 불필요한 노출 위험도 줄일 수 있습니다.
책 전체 요약과 질문 하나는 다릅니다
전체 흐름을 요약하고 싶은 경우와 특정 계약 조건 하나를 찾는 경우는 입력을 구성하는 방식이 다릅니다. 모든 페이지를 매번 보내는 대신 관련 부분을 찾은 뒤 답하게 하는 방식도 있습니다. 흔히 RAG라고 부르는 검색 결합 방식입니다. 다만 검색이 중요한 문단을 놓치면 답변 모델이 좋아도 틀릴 수 있습니다. 반대로 장별 요약을 합칠 때는 장 사이의 조건이나 예외가 빠질 수 있습니다. 무엇을 묻는지 먼저 정하고 그에 맞춰 원문이 전달되는지 봐야 합니다. 문서 개수가 많다는 사실만으로 긴 문맥을 최대치로 켜야 한다는 결론은 나오지 않습니다.
긴 문서를 넣을수록 먼저 기다리는 시간이 보입니다
짧은 대화에서는 답변이 술술 나와도 긴 문서를 넣으면 첫 글자까지 오래 걸릴 수 있습니다. 파일을 읽고 텍스트를 준비하는 시간, 모델이 입력을 처리하는 시간, 답변을 만드는 시간이 더해지기 때문입니다. 우리 사이트의 프리필 비교는 이 가운데 모델 입력 처리의 예상 체감을 보는 도구이지 PDF 추출 전체를 재현하는 도구는 아닙니다. 이 차이를 알고 쓰면 비교가 쉬워집니다. 실제 앱에서는 업로드부터 답변 완료까지도 기록하고, 원문을 이미 준비한 상태의 요청과 나눠보세요. 어디에서 기다리는지 알아야 CPU나 GPU, 모델 설정 중 바꿀 대상을 고를 수 있습니다.
정답을 아는 질문 세 개를 남깁니다
이 문서를 요약해달라는 요청만으로는 설정을 비교하기 어렵습니다. 날짜 하나, 표의 숫자 하나, 본문에 없는 내용 하나를 물어보세요. 앞의 두 질문은 원문과 대조하고, 마지막 질문에서는 모른다고 답하는지 확인합니다. 근거 위치도 함께 요구하되 페이지 번호가 그럴듯하다고 믿지 말고 직접 열어봅니다. 이 작은 확인 세트를 모델이나 검색 설정을 바꿀 때마다 반복하면 결과가 나아졌는지 판단하기 쉬워집니다. 모든 문서를 대표하는 품질 점수는 아니지만, 답변이 유창해졌다는 인상만으로 장비와 모델을 바꾸는 것보다는 훨씬 구체적인 기준이 됩니다.
장비는 문서 처리 습관에 맞춰 고릅니다
매일 긴 원문 전체를 읽히는 사람은 입력 처리와 메모리 여유를 함께 봐야 하고, 필요한 문단 몇 개만 찾아 답하는 사람은 검색 정확도와 짧은 응답의 품질이 더 먼저일 수 있습니다. 문서를 보관하는 SSD 공간과 실행 중 필요한 메모리도 같은 항목이 아닙니다. 먼저 대표 자료로 추출과 답변 검증을 끝내고, 그때 사용한 입력 길이를 기준으로 장비 후보를 비교하세요. 보안을 위해 로컬을 선택했다면 모델 서버뿐 아니라 OCR, 임베딩, 검색과 연결된 외부 도구도 로컬인지 따로 확인해야 합니다. 컴퓨터 한 대를 샀다는 사실만으로 처리 경로 전체가 오프라인이 되는 것은 아닙니다.