검색 데이터 만들기

2.2 검색 데이터 만들기

세부 학습 목표

• 문서·이미지·음성·영상의 수집을 검색 가능한 표현과 출처로 연결한다.
• 인덱서·기본 제공/사용자 지정 스킬·필드 매핑·인덱스를 구별한다.
• 청킹·임베딩·필드·권한·갱신 상태를 설계하고 최초 불일치 단계를 찾는다.

개요

• 수집: 원문에서 텍스트·표·이미지·음성 정보를 추출.
• 분할: 검색할 의미 단위로 나누고 출처·적용일·권한 보존.
• 색인: 검색 필드와 임베딩을 인덱스에 저장.
• 점검: 문서별 처리 결과와 대표 질문의 검색 결과 대조.

원문이 검색 결과가 되기까지

• 색인(index)은 검색할 필드와 내용을 저장하는 구조입니다.

  인덱서(indexer)는 지원 데이터 원본에서 내용을 읽어 수집 흐름을 실행하는 구성 요소입니다. 스킬셋(skillset)은 OCR·분할·정보 추출·임베딩 같은 보강 작업을 묶습니다. 직접 만든 앱이 추출과 임베딩을 수행한 뒤 문서를 색인에 넣는 방식도 있습니다.

• PDF·이미지·녹음·영상은 형식별 추출이 필요합니다.

  파일 확장자를 바꾸거나 파일 이름을 임베딩하는 것으로 내용 처리가 완성되지는 않습니다. 스캔 문서는 OCR, 녹음은 전사, 영상은 구간과 시각·음성 정보를 검색 가능한 표현으로 연결합니다.

인덱서·스킬셋·인덱스의 역할

• **인덱서(indexer)**는 지원 데이터 원본에서 자료를 읽고 검색 인덱스에 반영하는 흐름입니다. **스킬셋(skillset)**은 그 사이에 적용할 분석·변환 단계의 정의이고, **인덱스(index)**는 검색할 필드와 자료를 담는 구조입니다.

  스캔 설명서를 읽었다면 OCR로 글자를 만들고, 분할·임베딩을 거쳐 검색 필드로 보냅니다. OCR 결과가 존재해도 출력 필드 연결이 틀리면 검색 본문에는 빈 값이 들어갈 수 있습니다.

• 기본 제공 스킬로 충족되지 않는 처리를 외부 코드의 사용자 지정 스킬로 연결할 수 있습니다.

  사용자 지정이라는 이유로 정확한 것은 아닙니다. 같은 문서 ID의 원본→중간 출력→적재 필드를 대조하고 빈 결과·일부 실패를 검사합니다. 자료를 보강하는 단계와 최종 답변을 생성하는 단계도 구별합니다.

청크 크기와 의미 보존

• 청킹(chunking)은 긴 자료를 검색 단위로 나누는 작업입니다.

  지나치게 작게 나누면 조건과 결론이 분리되고, 너무 크게 나누면 무관한 문장이 많이 검색됩니다. “해외 출장에만 적용”이라는 조건이 금액과 다른 청크에 떨어지면 잘못된 규정이 답변의 근거가 될 수 있습니다.

• 문단·제목·표 관계를 기준으로 나누고, 필요에 따라 경계의 문맥을 겹쳐 보존합니다.

  겹침을 늘리면 중복과 색인 비용도 늘어납니다. 청크 길이의 유일한 정답을 외우기보다 대표 질문에서 근거가 함께 검색되는지 평가합니다.

• 메타데이터의 존재만으로 접근 통제가 자동 완성되는 것은 아닙니다.

  앱이 인증된 사용자 정보를 기준으로 올바르게 필터링하도록 구성해야 합니다.

• 인덱스에서는 값의 저장과 검색 기능도 나누어 설정합니다.

  searchable은 전체 텍스트 검색, filterable은 조건에 따른 후보 제한, retrievable은 검색 결과에 값 반환을 허용하는 속성입니다. 예를 들어 본문은 검색·반환 대상으로, 사용자 그룹은 권한 필터 대상으로 구성합니다. 필드 자료형에 따라 사용할 수 있는 속성이 다르므로 스키마와 실제 쿼리를 함께 확인합니다.

• 테넌트: 이 교재의 앱 예제에서 조직·고객별 데이터 접근 범위를 나누는 단위입니다.

  같은 서비스를 사용해도 고객 A의 자료가 고객 B의 검색 결과에 섞이지 않도록 구분합니다. 사용자 식별과 소속 범위는 앱에서 인증한 정보로 정하고, 사용자가 보낸 테넌트 이름을 그대로 권한으로 인정하지 않습니다.

임베딩과 벡터 필드

• 임베딩(embedding)은 텍스트·이미지 등을 수치 벡터로 표현하는 변환입니다.

  유사한 의미가 가까운 벡터로 표현되도록 학습된 모델을 이용합니다. 검색 질문과 문서를 비교하려면 호환되는 임베딩 모델·차원·전처리를 사용해야 합니다.

• Azure AI Search의 통합 벡터화에서는 수집 시 임베딩 스킬과 질의 시 vectorizer를 구성할 수 있습니다.

  스킬은 색인에 넣을 벡터를 만들고, vectorizer는 검색 질문을 벡터로 바꿉니다. 이름이 비슷해도 실행 단계가 다릅니다. 모델을 바꿨다면 기존 문서 벡터와 질의 벡터의 호환성을 확인하고 필요 시 다시 색인합니다.

장애를 처리 단계로 좁히기

• 신규 매뉴얼이 검색되지 않는다면 생성 모델 설정을 바꾸기 전에 수집 결과부터 봅니다.

  파일을 읽었는지, OCR 결과가 비어 있지 않은지, 청크와 필드 매핑이 맞는지, 색인에서 내용을 직접 찾을 수 있는지 순서대로 확인합니다.

• 전체 문서 수가 0보다 크다는 사실만으로 신규 문서의 처리 성공을 판단할 수 없습니다.

  기존 문서가 남아 있거나 일부 문서만 실패할 수 있습니다. 문서별 오류·마지막 갱신·색인 내용과 대표 질의의 검색 결과를 함께 남깁니다.

클라우드 검색 실습 준비

1. 리소스 준비: Azure AI Search, 원문 저장소, 문서·질의 벡터화에 사용할 임베딩 모델을 준비합니다.
2. 수집 구성: 포털의 데이터 가져오기에서 원본 연결과 텍스트 벡터화를 설정합니다.
3. 색인 확인: 인덱서가 문서를 처리했는지 확인하고 문서 본문·출처·벡터가 실제로 저장됐는지 봅니다.
4. 질의 준비: 질의용 vectorizer와 semantic 설정, 호출 계정의 검색 권한을 확인합니다.
5. 첫 검색: 대표 질문으로 예상 문서가 나오는지 확인한 뒤 2.3의 생성 단계로 연결합니다.

• 처음 리소스부터 구성할 때는 포털 벡터 검색 빠른 시작 을 사용합니다.

  앞의 본문은 인덱스 설계 원리를 설명합니다. 클라우드 인덱스를 자동 생성하지는 않습니다. 빠른 시작에서는 원본 연결·임베딩 배포·수집 실행을 실제로 수행하며 사용한 리소스에 비용이 발생할 수 있습니다.

• 다음 절의 예제와 필드·설정 이름을 맞춥니다.

  포털이 만든 이름은 예제와 다를 수 있습니다. 본문·출처·벡터 필드의 실제 이름을 기록하고, 해당 이름으로 예제의 필드 지정을 바꿉니다. 권한용 문자열 컬렉션과 그 값은 별도로 설계·적재해야 합니다. 필드를 이름만 바꾸거나 벡터 차원만 맞춘 것으로 권한과 검색 품질이 완성되지는 않습니다.

청크와 출처 메타데이터 설계

• 긴 문서를 작은 구간(청크)으로 나누면 검색 가능한 단위가 됩니다.

  하지만 표 머리글과 값, 적용일과 조항이 서로 분리되면 정답 생성에 필요한 문맥이 사라질 수 있습니다.

• 상황: 제5조와 적용일이 페이지 경계에서 분리되어 오래된 규정만 검색됩니다.

• 적용: 문서 ID·판본·제목·페이지·조항·적용일 및 접근 범위를 저장하고, 분할 뒤 핵심 의미가 보존됐는지 질문으로 검증합니다.

인덱싱 전에 추출 품질 확인

• 문서 수집 후 OCR/레이아웃 추출, 정제, 필드 매핑, 색인 생성으로 이어집니다.

  결과가 검색되지 않을 때 색인 쿼리만 고치면 앞 단계 누락을 해결할 수 없습니다.

• 상황: 원본 PDF 100개 중 검색 결과에는 80개 문서만 나타납니다.

• 적용: 수집 성공 건수→추출 성공→필드 매핑→색인 성공→검색 필터 순으로 단계별 건수를 대조합니다.

검색 누락의 원인 격리

• 검색 실패는 검색 엔진 이전 데이터 파이프라인에서 시작될 수 있습니다.

  문서별 추적 ID와 실패 상태를 보존하면 원인을 빠르게 찾습니다.

• 상황: 특정 계약서는 색인에는 존재하지만 특정 사용자에게만 검색되지 않습니다.

• 적용: 우선 해당 사용자의 접근 필터·테넌트·인덱스 필드와 쿼리 조건을 확인합니다.

  색인 자체 누락이 아니면 OCR 재실행은 원인과 맞지 않습니다.

Azure 검색 인덱스 필드 설계

• Azure AI Search 인덱스에서 searchable·filterable·retrievable 등의 필드 속성은 역할이 다릅니다.

  전체 텍스트 검색 대상과 테넌트별 필터 필드를 구분하고, 문서 ACL 또는 서버 측 보안 필터를 통해 사용자 권한에 맞는 문서만 검색 후보로 제공합니다. 프롬프트만으로 문서 접근을 제한해서는 안 됩니다.

• 상황: 고객별 정책 문서를 하나의 인덱스에 보관합니다.

• 적용: 테넌트 ID는 접근 범위 필터의 핵심이고 문서 ID·버전·조항은 출처 검증에 필요합니다.

  필드별 실제 인덱스 기능 지원도 확인해야 합니다.

• 검색 인덱스 필드 설정 

• 검색 권한별 결과 제한 

확인 문제

source D12: text="부품 Z17 교체 주기 6개월"
extract D12: content="부품 Z17 교체 주기 6개월"
mapping: index.body ← source.description
source.description: null
indexed D12: body=null / title="정비 문서"
query="Z17 교체" → hits=[]

수집기 경로:
  text/* → 텍스트 추출 → 청크 → 색인
  application/pdf → 문서 분석 → 청크 → 색인
  audio/wav → 파일명 청크 → 색인
sample audio: "Z17 납기는 금요일" / indexed="meeting.wav"
출처·접근 권한 필드: 보존됨

원문 표 p4:
부품 | 온도 상한
A17  | 80도
B20  | 120도
현재 청크: "A17 B20 80도 120도"
검색 답변: A17은 120도까지 가능

query="스캔 매뉴얼의 교체 주기" / hits=[]
원문 파일: 제공되지 않음
추출 로그: 제공되지 않음
색인 문서·필드: 제공되지 않음
질의 필터: 제공되지 않음

참고 자료

• Chunk large documents for RAG and vector search in Azure AI Search 
• Integrated vector embedding in Azure AI Search 
• Vector search in Azure AI Search 
• AI enrichment in Azure AI Search 
• 포털에서 벡터 검색 준비하기 

자료 확인: 2026-10-25 · 적용 사례 교정: 2026-10-23. 사례는 교육용이며 Azure API 호출·요금은 실행 검증하지 않았습니다.

원본 D12와 OCR 결과에는 “제품 B, 수령 후 14일”이 있습니다. 인덱서의 필드 매핑은 비어 있는 description을 본문으로 적재했습니다. 새 자료는 검색되지 않습니다.