오래된 답변이 없는 AI 지식 기반: 신선도, 권한 및 출처에 대한 실용 가이드

AI 어시스턴트를 위한 지식 기반은 모든 파일을 하나의 폴더에 업로드하는 것부터 시작하지 않습니다. 그것은 소스 레지스터(source register)로 시작합니다. 즉, 각 소스마다 소유자, 유효 기간, 접근 규칙을 정의하는 것입니다. 검색 시 권한과 업데이트 경로가 함께 작동하여 실제 사용자와 연결됩니다.

목표는 절대 틀리지 않는 모델이 아닙니다. 목표는 감지할 수 있는 오류입니다. 어떤 출처가 반환되었는지, 언제 승인되었는지, 누가 볼 수 있는지, 무엇이 누락되었는지, 그리고 누가 수정하는지를 파악하는 것입니다. 오래된 문서를 폐기하거나 권한 변경을 반영하지 못하는 지식 기반은 모델 자체가 변하지 않았더라도 유창하지만 잘못된 답변을 제공할 것입니다.

1. 인덱싱 전에 소스 레지스터를 구축하세요

폴더별이 아닌, 소스별로 한 행(row)을 만드세요. 각 행은 다음 질문에 답해야 합니다: 이 문서는 무엇이며, 누가 소유하고 있는지, 누구를 위한 것인지, 언제 유효한지, 무엇으로 대체되는지, 그리고 인덱스에서 어떻게 제거되어야 하는지.

가장 최신 파일이 무조건 승리한다고 가정하지 마세요. 업로드 날짜가 콘텐츠 날짜보다 늦을 수 있으며, 폴더 간에 이동된 사본은 오래되었음에도 불구하고 새 것처럼 보일 수 있습니다. 정보 유형별로 우선순위 순서(precedence order)를 정의하세요. 서명된 정책이 교육 자료보다 중요할 수 있고, 번호가 매겨진 수정 공지가 새로운 버전이 출시될 때까지 정책보다 중요할 수 있습니다. 규칙이 없다면 올바한 상태는 conflict입니다. 모델에게 가장 설득력 있게 들리는 문서를 선택하도록 요청하지 마세요.

2. 활성, 기록 보관 및 초안 콘텐츠를 분리하세요

기록 보관된 문서(historical document)는 감사(audit)에 중요할 수 있지만, 활성 문서와 조용히 경쟁해서는 안 됩니다. 접근 제어 뒤의 아카이브에 보관하고, 상태 필드와 만료 날짜를 사용하여 일반 답변 경로에서 제거해야 합니다. 초안은 소유자가 승인할 때까지 활성 저장소 밖에 머물러야 합니다.

3. 권한을 처음부터 끝까지 유지하기

지식 기반에 대한 접근 권한이 그 안에 있는 모든 것을 볼 수 있다는 의미는 아닙니다. 데이터를 가져올 때(ingest), 출처의 대상 독자층(audience)을 저장해야 합니다. 질의 시에는 사용자 신원(identity)별로 결과를 필터링해야 합니다. 답변에서는 사용자가 열지 못할 문서를 절대로 보여주거나, 인용하거나, 링크해서는 안 됩니다. 광범위한 서비스 계정(service account)이 사용자가 보는 범위를 넓혀도 된다는 이유는 될 수 없습니다.

출처의 권한도 확인해야 합니다. 사용자 권한을 존중하는 제품이라 할지라도 과거에 너무 광범위하게 공유된 콘텐츠를 여전히 노출할 수 있습니다. 예를 들어, Microsoft의 문서에서는 SharePoint와 OneDrive 제어가 사용자 권한을 변경하지 않고 검색(discovery)에 영향을 미치며, 라이프사이클 및 공유 정책이 과도한 공유를 줄이는 데 도움이 된다고 설명합니다. 이는 Microsoft 365 Copilot에 대한 진술일 뿐, 모든 RAG 도구에 대한 보장은 아닙니다.

읽기 전용(read-only)으로 시작하세요. 지식 기반 관리자(admin)는 가져오기(import), 비활성화(disable), 재구축을 할 수 있습니다. 일반 사용자는 질문만 할 수 있습니다. 모델은 출처 문서에 대한 쓰기 접근 권한(write access)이 없습니다. 삭제, 대상 독자층 변경 또는 버전 교체는 채팅의 결과가 아니라 기록되는 관리자 작업입니다.

4. 데이터 가져오기를 검증 가능하게 만들기

일반적인 파이프라인은 데이터 가져오기(ingestion), 텍스트 추출, 청킹(chunking), 임베딩(embeddings), 인덱싱 및 검색(retrieval)입니다. Google의 RAG Engine 문서는 유사한 체인을 보여줍니다. 이 문서는 제품을 설명할 뿐, 귀하의 문서가 잘 청크되었는지 또는 출력이 출처에 충실한지 증명하지는 않습니다.

모든 실행(run)을 기록하세요: 실행 ID, 출처 목록, 버전, 성공 및 실패 여부. 파일이 API로 전송되었다고 해서 검색 가능한 것은 아닙니다. 예를 들어, OpenAI의 File Search 문서는 파일이 completed 상태에 도달했는지 확인하고, 파일 인용(citation) 및 메타데이터 필터링을 설명합니다. 데이터 가져오기가 부분적이라면 이전 버전을 활성 상태로 유지하거나 해당 주제를 차단하세요. 마커 없이 절반만 업데이트하는 것은 하지 마십시오.

도구 구성은 간단할 수 있습니다. 등록을 위한 시트나 데이터베이스, 내보내기 도구나 크롤러, 파서(parser), 검색 엔진 또는 벡터 스토어(vector store), 링크 확인기, 참고 질문 세트, 그리고 각 질문을 검색된 결과 및 답변에 연결하는 로그가 필요합니다.

5. 열람 가능하고 버전 관리되는 인용 출처 요구

답변에는 사용자의 권한으로 열리는 명확한 출처 이름과 링크를 보여줘야 합니다. 테스트를 위해 source_id, 버전, 청크 ID도 유지해야 합니다. 파일 이름만으로는 폴더를 넘나들며 변경되거나 반복될 수 있습니다. 만약 출처를 열 수 없다면, 인용 출처가 사용자가 주장을 확인할 수 있도록 해주지 못합니다.

인용 출처는 시스템이 어떤 주장(claim)을 특정 파일에 연결했음을 보여줍니다. 하지만 그 주장이 실제로 그 파일에서 도출되었음을 증명하지는 않습니다. 테스트할 때는 각 자료의 주장을 출처 문장과 비교하고, 컨텍스트가 잘려나가지 않았는지 확인하며, 답변 시점에 출처가 유효했는지 확인해야 합니다. 또한 유사한 단락이 발견되었지만 다른 대상 고객, 제품 또는 기간에 속하는 샘플 답변도 준비해 보세요.

6. 검색을 위한 인수 테스트 구축

단지 문구가 자연스러운지 여부만 확인해서는 안 됩니다. 각 질문에 대해 세 가지 수준에서 예상 결과를 저장해야 합니다. 어떤 출처가 검색되어야 하는지, 그 출처들로부터 무엇을 결론지을 수 있는지, 그리고 올바른 결정 상태(decision state)가 무엇인지를 말입니다. 이렇게 해야 검색 실패와 문구 실패를 구분할 수 있습니다. 만약 올바른 문서가 컨텍스트에 도달하지 못했다면, 더 나은 프롬프트(prompt)가 해결책이 아닙니다.

다음 항목들을 포함하세요:

• 일반적인 질문과 재구성된 질문
• 다른 언어의 기술 용어
• 폐기된 문서
• 상충하는 두 가지 버전
• 권한이 없는 사용자
• 수집(ingestion)에 실패한 파일
• 답변이 없는 질문
• 삭제된 링크

질문의 양만으로는 품질을 보장할 수 있는 만능의 숫자는 없습니다. 콘텐츠 다양성으로 커버리지를 확보하고 잘못된 답변이 초래할 수 있는 피해를 고려해야 합니다. 유용한 지표로는 올바른 출처 검색률(right-source retrieval rate), 유효한 출처가 포함된 답변 비율, 감지된 충돌 건수, 권한 누출(permission leaks) 건수, 적절하게 중단된 미답변 질문 수, 그리고 승인부터 활성화까지 걸린 시간 등이 있습니다. 평균적인 지표는 권한 누출이나 폐기된 문서 사용을 대체할 수 없습니다.

7. 회색지대 없이 업데이트하고 제거하기

변경 경로를 정의해야 합니다. 즉, 소유자가 특정 버전을 승인하면 관리자(admin)가 이를 수집(ingest)하고, 회귀 테스트(regression tests)가 실행된 후에야만 별칭(alias)이 새로운 활성 인덱스로 전환되어야 합니다. 이전 인덱스로 돌아갈 방법은 유지하되, 안전이나 개인 정보 보호를 이유로 폐기된 문서는 절대 복원해서는 안 됩니다. 기술적 롤백은 출처의 비즈니스 상태에 따라 달라집니다.

권한이 제거되거나 문서가 폐기될 때는 대응 시간을 설정하고 모든 사본(source, cache, index, saved results, 테스트 환경)을 확인해야 합니다. 제품 설명에 다른 보존 기간이 명시되어 있다면 즉각적인 삭제를 약속해서는 안 됩니다. 무엇이 삭제되었는지, 어떤 것이 정책에 따라 남아 있는지, 그리고 언제 확인했는지를 기록으로 남겨야 합니다.

예시 (가상): 경비 정책

이는 프로덕션 환경에서 테스트되지 않은 제안된 설계입니다. 운영팀(ops team)은 어시스턴트가 출장 경비 관련 질문에 답변하기를 원합니다. 현재 활성화된 정책, 오래된 교육 자료(training deck), 그리고 내년도 초안이 존재합니다.

• 입력 (Input): 활성 정책과 승인된 정정 공지(approved correction notice). 해당 자료는 superseded로 표시되어 있습니다. 초안은 활성 저장소에 포함되지 않습니다.
• 출력 (Output): 짧은 답변, 유효한 출처에서만 발견되는 금액 또는 규칙, 섹션 링크, 버전 정보, 그리고 answered 또는 needs-clarification 상태를 제공합니다.
• 권한 (Permissions): 모든 직원은 정책을 읽을 수 있습니다. Ops만이 버전을 관리할 수 있습니다. 모델은 비용(expenses)을 작성하거나 승인할 수 없습니다.
• 테스트 케이스 (Tests): 일반 직원, 예외가 있는 단위, 히브리어 및 영어 표현, 내년에 관한 질문, 깨진 링크, 그리고 공지사항과 정책 간의 충돌에 대한 테스트를 포함합니다.
• 중단 조건 (Stop conditions): 활성 출처를 찾을 수 없음, 동등한 순위의 두 출처가 충돌함, 사용자가 권한이 없음, 파일 색인화(ingestion)가 완료되지 않음, 또는 답변이 출처에 포함되지 않은 조건을 추가할 때.

유효한 출처가 없을 때는 'Contact ops'라는 결과가 허용됩니다. 이는 모델이 정책을 임의로 지어내는 것을 방지하는 예상된 동작입니다.

실패 사례 (Failure cases)

• 활성 버전 두 개: conflict로 중단하고, 소유자에게 두 출처를 모두 보여주며, 자동으로 선택하지 않습니다.

• 부분 색인화: 새 인덱스를 활성화하지 않습니다. 파일을 기록(log)하고 오류를 남기며, 임계값(threshold)을 낮추지 않고 재시도합니다.

• 출처가 너무 광범위하게 공유됨: 공유 설정을 수정하거나 결정이 내려질 때까지 출처를 제거합니다. 앱 레벨 필터는 출처 접근 제어를 대체할 수 없습니다.

• 유효한 문서 검색 실패: 검색 실패로 표시합니다. 답변을 다시 작성하기 전에 추출(extraction), 청킹(chunking), 메타데이터, 그리고 쿼리를 확인해야 합니다.

• 인용이 주장을 뒷받침하지 않음: 해당 주장을 차단하고, 컨텍스트 검사(context check)를 수정하며, 이 사례를 회귀 테스트(regression)에 추가합니다.

• 기본 데이터베이스에 답변 없음: 에스컬레이션 경로와 함께 no-valid-source를 반환합니다. 회사 정책인 것처럼 일반 지식을 채우지 않습니다.

• 깨진 링크: 출처가 검증될 수 없음을 보여주고, 소유자에게 전달(route)합니다.

• 색인화 후 권한 변경(Permission changed after indexing): 삭제를 실행하거나 재구축하고, 캐시를 무효화하며, 접근이 사라졌는지 사용자의 신원을 통해 테스트해야 합니다.

한계점 (Limits)

RAG 또는 파일 검색 기능 자체가 출처가 정확하거나, 최신이거나, 허용된다는 것을 의미하지 않습니다. 청킹(Chunking)은 규칙과 예외를 분리할 수 있고, 메타데이터(metadata)가 잘못될 수 있으며, 검색 과정에서 특정 용어를 놓칠 수 있고, 심지어 올바른 컨텍스트(context)가 주어졌더라도 모델이 출처가 뒷받침하지 않는 결론을 내릴 수 있습니다. 한 제품에서의 권한이 다른 제품에서도 권한을 증명하지는 않습니다.

본 가이드는 데이터 분류, 개인 정보 보호 평가(privacy assessment), 법률 자문, 기록 관리 또는 공급업체 계약 검토를 대체하지 않습니다. 보존(Retention), 삭제, 처리 지역 및 하위 프로세서(sub-processors)는 제품, 플랜 및 실제 설정에 따라 달라집니다. 개인적, 기밀 또는 규제 대상 자료를 사용하기 전에 조직 내 책임자로부터 승인을 받으십시오.

출처 (Sources)

• NIST AI 600-1, Generative AI Profile (2024년 7월 26일 발행). AI 위험 관리를 위한 자발적인 교차 영역 프레임워크입니다. 여기의 출처 등록부 및 워크시트는 NIST 요구 사항이 아닌 제안된 구현체입니다.
• OpenAI API, 파일 검색 문서(File Search documentation). 해당 제품에 대한 데이터 수집 상태(ingestion status), 파일 인용(file citations), 검색 결과 포함 및 메타데이터 필터링을 설명합니다.
• Microsoft Learn, Microsoft 365 Copilot 데이터 보호 아키텍처. 권한, 민감도 레이블(sensitivity labels), 공유 및 라이프사이클 정책이 Copilot에 어떻게 영향을 미치는지 설명합니다. 모든 RAG 시스템을 위한 배포 가이드가 아닙니다.
• Google Cloud, Vertex AI RAG 엔진 개요(overview). 데이터 수집, 변환, 임베딩, 인덱싱, 검색 및 생성 체인(chain)을 나열합니다.

원래는 AI NEWS IL (ainewsil.co.il)에 히브리어로 게시되었으며, 인쇄 가능한 워크시트가 제공되었습니다. 본 내용은 영어 각색본입니다.

전체 히브리어 가이드와 인쇄 가능한 워크시트는 AI NEWS IL에서 확인할 수 있습니다: 원문 기사 읽기. 이스라엘 AI 연구소(Israeli Institute for AI)는 전 세계 조직을 대상으로 AI 교육 및 구현 프로그램을 운영하고 있습니다.