RAG용 문서 클리너

문서 클리너는 검색 증강 생성(RAG)을 위해 PDF를 준비합니다: 텍스트를 추출하고, 모든 페이지에 반복되는 머리글, 바닥글과 페이지 번호를 찾고, 중복 단락에 표시한 뒤, 텍스트가 청크로 나뉘어 임베딩되기 전에 그것들을 제거할 수 있게 합니다. 아래에 PDF를 놓으면 정리는 전적으로 브라우저 안에서 이루어집니다 — 파일은 절대로 기기를 떠나지 않으며 아무것도 업로드되지 않습니다. 가구가 임베딩을 왜 오염시키는지는 RAG 전에 문서 정리하기를 읽고, 구조는 PDF 접근성 검사기로 확인하고, 파일은 먼저 문서 포렌식으로 검사하세요.

마지막 업데이트:

또는 파일을 이 상자 안 어디에나 놓으세요. 파일은 이 기기에서 읽히며 절대 업로드되지 않습니다. 제한: 20 MB.

클리너가 제거하는 것과 그것이 중요한 이유

긴 PDF는 모두 가구를 지니고 있습니다: 보고서 제목이 있는 머리글, 기밀 고지가 있는 바닥글, 모서리에서 올라가는 페이지 번호. 사람 독자에게 그 가구는 방향 감각입니다. 임베딩 모델에게는 모든 페이지에서 온전한 강도로 반복되는 소음입니다. 같은 머리글 줄이 수십 번 청크로 나뉘고, 임베딩되고, 저장되어, 실제 내용을 설명해야 할 벡터를 희석하고, 마치 정보인 것처럼 검색 결과에 나타납니다. 이 클리너는 가구를 단순하고 검사 가능한 규칙을 가진 탐지 문제로 다룹니다: 페이지의 최소 60퍼센트(그리고 최소 두 페이지)에 나타나는 짧은 줄은 제거 후보로 목록에 오르고, 그것을 제거할지는 당신이 결정합니다. 아무것도 조용히 제거되지 않습니다 — 모든 후보는 그 텍스트, 페이지와 횟수와 함께 표시된 뒤에야 당신이 체크하거나 해제합니다.

페이지 번호는 자체 후보를 가집니다. 왜냐하면 그것들은 절대로 글자 그대로 반복되지 않기 때문입니다: 1페이지는 1, 2페이지는 2라고 쓰므로 반복 규칙으로는 절대로 잡을 수 없습니다. 그렇지만 고립된 숫자나 “전체 40페이지 중 7페이지”라는 줄로 끝나는 청크는 임베딩에 아무것도 가르치지 않으며, 그것을 사실로 인용해 돌려주는 모델을 혼란스럽게 할 수 있습니다. 클리너는 흔한 패턴 — 그것이 놓인 페이지와 같은 고립된 숫자와 “N of M” 및 “N / M” 형태 — 에 맞추고 모든 일치를 하나의 후보로 묶습니다. 중복 단락은 세 번째 부류입니다: 반복되는 면책 조항, 중복된 요약, 또는 한 문서에 두 번 나타나는 복사된 섹션. 중복은 절대로 기본으로 체크되지 않습니다. 왜냐하면 반복되는 단락은 때로 의도적이기 때문입니다 — 예를 들어 두 장에 나타나야 하는 경고 — 그래서 클리너는 그것들에 표시하고 결정을 당신에게 맡기며, 제거할 때는 첫 번째 출현을 남깁니다.

추출이 동작하는 방식과 그것이 근사적인 곳

추출은 근사적이며, 이 페이지는 그렇지 않은 척하지 않습니다. 클리너는 PDF 콘텐츠 스트림을 로컬로 디코딩하고, 텍스트 표시 연산을 읽고, 표시된 텍스트의 각 묶음을 한 줄로 취급합니다. 이 모델은 빠르고 일반적인 워드프로세서와 내보내기 도구가 만든 보고서, 매뉴얼과 논문에는 충분하지만, 정직한 한계가 있습니다: 다단 레이아웃은 읽기 순서가 아니라 저장 순서로 나올 수 있고, 합자와 맞춤 글꼴 인코딩은 개별 문자를 깨뜨릴 수 있으며, 스캔된 PDF — 그 페이지가 텍스트가 아니라 사진입니다 — 는 한 줄도 만들지 않습니다. 그런 일이 생기면 도구는 결과를 지어내는 대신 그 사실을 분명히 말합니다: 줄이 0이라는 결과는 그 문서가 어떤 클리너도 도울 수 있기 전에 OCR이 필요하다는 뜻입니다. 이 첫 버전의 가구 탐지는 위치도 고려하지 않습니다: 짧은 줄은 페이지상의 위치가 아니라 몇 페이지에 반복되는지로 판단되므로, 본문 안에서 정말로 반복되는 짧은 제목이 목록에 오를 수 있습니다 — 바로 그래서 모든 후보는 당신이 해제할 수 있는 것입니다.

출력은 RAG 파이프라인의 다음 단계를 위해 만들어졌습니다. 정리된 텍스트 다운로드는 살아남은 줄을 페이지별로, 페이지 사이에는 빈 줄을 넣어 결합하므로, 읽거나, 비교하거나, 자신의 스플리터에 건넬 수 있습니다. JSONL 다운로드는 한 걸음 더 나아갑니다: 정리된 텍스트를 약 800자의 청크로 묶고, 가능한 한 문장 중간이 아니라 단락 경계에서 나누며, {"text": "..."} 형태로 한 줄에 하나의 JSON 객체를 씁니다 — 대부분의 임베딩 스크립트와 벡터 스토어 로더가 직접 받아들이는 형태입니다. 청크 크기는 법이 아니라 타협입니다: 800자는 청크가 보통 하나의 생각을 담기에 충분히 작고, 그 생각이 맥락을 유지하기에 충분히 큽니다. 동반 기사는 크기, 겹침과 경계를 더 깊이 설명합니다.

개인정보와 범위는 의도적으로 좁게 유지됩니다. 파일은 이 페이지에서, 당신의 기기에서 구문 분석됩니다; 그것을 분석해도 네트워크 요청이 일어나지 않으므로 내부 보고서, 계약서 초안과 개인 문서는 있어야 할 자리에 머뭅니다. 첫 버전은 PDF만 받아들입니다. 왜냐하면 가구 문제가 가장 심한 곳이 PDF이고, 브라우저 로컬 구문 분석기가 여전히 확실하게 텍스트를 복원할 수 있는 곳도 PDF이기 때문입니다; 워드프로세서와 HTML 출처는 그것들을 만든 도구 안에서 정리하거나, 먼저 PDF로 변환하는 편이 낫습니다. 클리너는 품질도 판단하지 않습니다: 남기는 텍스트를 요약하거나, 다시 쓰거나, 교정하지 않으며, 문서가 임베딩할 가치가 있는지 결정하지도 않습니다. 그것은 하나의 기계적인 일을 합니다 — 반복되는 것을 벗겨내고, 유일한 것을 남기고, 청크를 당신에게 건네는 일 — 그리고 모든 단계에서 그 작업을 보여주므로, 판단은 문서를 아는 사람의 손에 남습니다.

세 종류의 후보를 한눈에

반복되는 가구최소 60%의 페이지와 최소 두 페이지에 반복되는 짧은 줄(최대 120자): 머리글, 바닥글, 면책 조항과 워터마크. 기본으로 제거에 체크됩니다.
페이지 번호“전체 M페이지 중 N페이지”, “N / M”, 또는 그것이 놓인 페이지와 같은 고립된 숫자에 일치하는 줄을 하나의 후보로 묶은 것. 기본으로 제거에 체크됩니다.
중복 단락문서 어딘가에 최소 두 번 나타나는 최소 40자의 블록. 기본으로 체크되는 일은 절대로 없습니다; 제거하면 첫 번째 출현이 남습니다.
출력페이지 사이를 빈 줄로 구분한 정리된 일반 텍스트와, 단락 경계에서 나뉜 약 800자 JSONL 청크(한 줄에 {"text": "..."} 객체 하나).

자주 묻는 질문

제 PDF가 어딘가에 업로드되나요?

아니요. 파일은 이 페이지에서, 당신의 기기에서 열리고, 디코딩되고, 정리되며, 아무것도 업로드, 전송 또는 저장되지 않습니다. 페이지가 로드되면 오프라인으로 동작하는데, 이는 내부 보고서와 개인 문서에 맞는 형태입니다.

도구가 제 PDF에서 텍스트를 찾지 못한 이유는 무엇인가요?

거의 확실히 그 PDF가 텍스트가 아니라 스캔 이미지이기 때문입니다: 각 페이지는 사진이며 추출할 텍스트 연산이 없습니다. 도구는 추측하는 대신 줄 0을 보고합니다. 먼저 문서에 OCR을 실행해 페이지에 실제 텍스트 레이어를 갖게 한 뒤, 결과를 정리하세요.

정리가 실제 제목을 실수로 제거할 수 있나요?

탐지가 위치가 아니라 반복에 기반하므로, 반복되는 섹션 제목을 포함해 자주 반복되는 짧은 줄을 목록에 올릴 수 있습니다. 그래서 당신이 확인할 때까지 아무것도 제거되지 않습니다: 모든 후보는 그 텍스트, 페이지와 횟수를 표시하고, 체크를 해제하면 모든 출현이 남습니다.

중복 단락은 왜 기본으로 제거되지 않나요?

반복이 때로는 목적 자체이기 때문입니다: 안전 경고, 법적 고지나 요약은 의도적으로 반복될 수 있습니다. 중복은 그 위치와 함께 표시되어 당신이 판단할 수 있습니다; 하나를 체크하면 클리너는 첫 번째 출현을 남기고 뒤의 복사본을 제거합니다.

JSONL 내보내기는 어떤 청크 크기를 사용하나요?

청크당 약 800자로, 단락 경계로 묶이므로 청크가 문장 중간에 끝나는 일은 드뭅니다. 이는 임베딩을 위한 합리적인 기본값이며 보편적인 최적값은 아닙니다 — 동반 기사는 자신의 코퍼스와 리트리버에 맞는 크기와 겹침을 선택하는 방법을 다룹니다.