먼저 읽기
최종 업데이트
PDF 요약용 로컬 AI, 메모리를 사기 전에 문서부터 확인하세요
메모리를 늘리기 전에 PDF에서 읽힌 내용을 확인해요
PDF용 로컬 AI는 문서에서 글을 추출하거나 검색해 답을 만들어요. 요약이 틀리면 먼저 추출된 한 페이지에서 제목·문장 순서·표의 숫자가 원문과 맞는지 확인해요. 입력이 깨졌다면 더 큰 모델이나 메모리로 바로잡을 수 없고, 문서가 제대로 읽힌 뒤에야 검색 방식과 장비를 비교할 수 있어요.
80쪽짜리 서비스 계약서를 검토한다고 생각해 봐요. 본문과 표가 함께 있는 페이지 하나를 복사해 제목, 문장 순서, 금액이 원래 항목과 나란히 남았는지 살펴요. 숫자만 훑지 말고 ‘연간 이용료’에 붙은 값이 실제로 그 항목의 값인지 확인해야 해요. 읽는 순서나 표 구조가 이미 흐트러졌다면 모델도 잘못 배열된 내용을 바탕으로 답하게 돼요.
복사 결과가 비어 있거나 페이지 그림만 나온다면 먼저 OCR1이나 시각 입력 처리를 살펴봐요. 예를 들어 스캔 페이지의 숫자 8을 3으로 읽었는지 원본과 대조해요. 민감한 계약서 대신 구조가 비슷한 공개 자료로 이 단계를 시험할 수도 있어요. 한 페이지의 제목·문장·표가 제대로 복사되는 것을 통과 기준으로 삼으면, 뒤 단계에서 생긴 문제와 문서 추출 문제를 구분하기 쉬워요.
문서 전체 요약과 질문 하나를 구분해요
‘계약의 모든 의무를 요약해 줘’는 문서 전체의 흐름과 장 사이의 관계를 묻는 요청이에요. ‘자동 갱신을 취소하려면 언제 통지해야 해?’는 해당 조항과 조건을 바꾸는 예외를 찾아 근거를 확인하는 요청이에요. 매번 모든 페이지를 입력하지 않고 관련 구절을 찾아 답에 넣는 구성이 RAG2예요. 검색 결과에서 해지 조항만 나오고 다른 장에 있는 예외가 빠지면, 답변이 유창해도 결론은 틀릴 수 있어요.
검색된 조항이 질문에 직접 답하는지뿐 아니라 다른 절의 예외와 연결 조건도 포함하는지 확인해요. 예를 들어 통지 기한과 통지 방법이 서로 다른 장에 있으면 한 조각만으로는 답이 완성되지 않을 수 있어요. 반대로 전체 문서를 한꺼번에 넣더라도 장별 요약을 합치는 과정에서 정의와 예외가 분리될 수 있어요. 원하는 결과가 전체 개요인지 근거가 붙은 특정 답인지 먼저 정하면 입력 범위와 검색 방식을 고르기 쉬워요.
기다린 구간을 나눠 원인을 찾아요
PDF를 넣은 뒤 첫 글자가 나오기까지의 시간에는 파일 읽기, 텍스트 추출, 모델의 입력 처리인 프리필3이 섞일 수 있어요. 답을 생성하는 시간은 그 다음 디코드4 구간이에요. 이미 추출해 둔 텍스트를 붙여 넣으면 빠른데 PDF 업로드만 느리다면 파일 처리나 추출 경로를 먼저 봐요. 텍스트가 준비돼도 입력이 길수록 첫 답이 늦어진다면 프리필 영향을 살펴요.
사이트의 프리필 비교 도구는 모델 입력 처리의 예상 체감을 비교하며 PDF 읽기나 OCR을 재현하지 않아요. 실제 앱에서는 PDF 선택부터 답변 완료까지의 시간과 추출 텍스트를 바로 입력한 시간을 따로 기록해요. 첫 글자까지 기다린 시간과 답을 끝까지 받는 시간도 구분하면 파일 처리, 입력 처리, 생성 중 어디에 손볼 여지가 있는지 알 수 있어요.
정답을 아는 질문과 원문 근거를 함께 기록해요
계약서에서 반복해 쓸 질문 세 개를 골라요. 첫째는 갱신 통지 날짜, 둘째는 요금표의 특정 숫자와 단위, 셋째는 계약에 적히지 않은 지원 시간이에요. 각 정답은 원문에서 미리 찾아 두고, 마지막 질문에는 모델이 근거 없이 시간을 만들어 내지 않고 문서에 없다고 설명하는지도 확인해요. 모델이나 검색 범위를 바꾼 뒤에도 같은 질문과 정답을 쓰면 결과를 나란히 비교할 수 있어요.
답변에 페이지나 조항 번호가 있어도 그 위치를 직접 열어 확인해요. 검색형 구성에서는 해당 조항이 실제로 모델 입력에 도착했는지도 살펴요. 날짜 질문은 맞고 요금 숫자가 틀리면 표 추출과 숫자-항목 연결부터 점검해요. 문서에 없는 질문에 답을 지어냈다면 모델 크기만 바꾸기 전에 지시문, 검색 누락, 근거 전달을 확인해요. 질문마다 원문과 일치하는지, 근거가 입력에 포함됐는지, 모르는 내용을 인정했는지 기록하면 다음에 바꿀 설정이 분명해져요.
문서 작업의 반복 병목이 확인된 뒤 장비를 골라요
먼저 현재 구성으로 문서 한 건을 추출하고, 필요한 질문을 처리하고, 답의 근거를 확인하는 데 걸리는 시간을 적어요. 문서 전체를 매번 입력해야 한다면 입력 처리와 실행 중 메모리 여유가 중요할 수 있어요. 일부 조항만 찾는 작업이라면 예외까지 검색했는지와 문서에 없는 질문을 적절히 다루는지가 우선이에요. 파일을 보관할 SSD5 공간과 모델이 실행 중 쓰는 메모리는 다른 요구예요.
같은 추출 텍스트와 질문을 유지한 채 설정 하나만 바꿔요. 문맥 길이나 검색 범위 가운데 하나를 조정하고 답과 대기 단계를 비교해요. 짧은 요청에서 정상 작동을 확인한 다음 대표 페이지, 관련 조항, 전체 계약서 순으로 입력 범위를 늘리면 어느 지점에서 메모리나 시간이 부담이 되는지 찾기 쉬워요. 스캔 숫자가 이미 잘못 추출됐다면 모델 크기를 키워도 원인은 남아요. 반대로 원문과 검색 근거가 정확한데 전체 입력이나 메모리에서 반복해 막힐 때 장비 증설을 비교할 이유가 생겨요.
개인정보 보호를 위해 로컬 실행을 택했다면 OCR·임베딩·검색·파일 업로드도 어느 환경에서 처리되는지 확인해요. 한 문서를 처음부터 끝까지 돌리면서 앱 준비, PDF 입력, 후속 질문 때의 메모리와 오류를 기록해요. 전체 계약서를 매일 다뤄 입력 처리나 메모리가 계속 병목이라면 증설을 검토할 수 있어요. 반대로 문서를 가끔 열어 필요한 조항만 확인한다면 현재 구성의 검색 흐름으로 충분할 수 있어요. 기준은 최대 문맥 길이가 아니라 반복하는 문서 작업이에요.
용어 각주
OCR — 이미지나 스캔 문서에서 글자를 인식해 텍스트로 바꾸는 처리입니다. 표 배치나 읽기 순서는 원본 이미지를 함께 봐야 판단할 수 있습니다.
본문으로 돌아가기검색 증강 생성 — 질문과 관련된 자료를 검색해 모델 입력에 추가한 뒤, 그 문맥을 바탕으로 답변을 생성하는 방식입니다.
본문으로 돌아가기프리필 — LLM이 입력 프롬프트를 읽고 각 토큰의 내부 표현을 계산하는 단계입니다. 입력이 길수록 처리할 토큰이 많아집니다.
본문으로 돌아가기토큰 디코드 — 입력과 앞서 만든 답변을 바탕으로 다음 출력 토큰을 차례로 생성하는 단계입니다.
본문으로 돌아가기SSD — 플래시 메모리를 사용하는 데이터 저장 장치입니다. 전원이 꺼져도 데이터가 보존됩니다.
본문으로 돌아가기
자주 묻는 질문
- 이 글에서 가장 먼저 확인할 것은 무엇인가요?
- PDF용 로컬 AI는 문서에서 글을 추출하거나 검색해 답을 만들어요. 요약이 틀리면 먼저 추출된 한 페이지에서 제목·문장 순서·표의 숫자가 원문과 맞는지 확인해요. 입력이 깨졌다면 더 큰 모델이나 메모리로 바로잡을 수 없고, 문서가 제대로 읽힌 뒤에야 검색 방식과 장비를 비교할 수 있어요.
- 필요한 메모리는 어느 정도인가요?
- 먼저 현재 구성으로 문서 한 건을 추출하고, 필요한 질문을 처리하고, 답의 근거를 확인하는 데 걸리는 시간을 적어요. 문서 전체를 매번 입력해야 한다면 입력 처리와 실행 중 메모리 여유가 중요할 수 있어요. 일부 조항만 찾는 작업이라면 예외까지 검색했는지와 문서에 없는 질문을 적절히 다루는지가 우선이에요. 파일을 보관할 SSD 공간과 모델이 실행 중 쓰는 메모리는 다른 요구예요.