애플리케이션 적용 방법 계획

버전 간의 주요 변경사항 중 하나는 Discovery v2 가 프로젝트를 도입하는 것입니다. 프로젝트는 하나 이상의 컬렉션으로 구성되어 있습니다. 프로젝트 사용의 장점은 동시에 여러 콜렉션에 대해 하나의 조회를 실행할 수 있다는 점입니다. 각 컬렉션에는 사용자가 업로드하거나 웹사이트, Microsoft SharePoint, 등과 같은 단일 데이터 소스에서 크롤링한 문서가 포함될 수 있습니다.

프로젝트를 사용하도록 애플리케이션을 조정할 때 고려할 사항은 다음과 같습니다.

• 환경의 개념이 v2에 존재하지 않아도 데이터는 여전히 콜렉션으로 구성됩니다. v2에서 콜렉션은 프로젝트로 그룹화됩니다. 대부분의 경우 단일 v1 콜렉션을 단일 v2 콜렉션으로 마이그레이션하려고 합니다.

  v1 콜렉션에 적용되는 관련성 훈련 정보를 유지하려면 v2 프로젝트의 단일 콜렉션에 콜렉션 문서를 추가하십시오.

• 각 v2 프로젝트에 추가할 콜렉션 수를 결정하십시오. Content Mining 프로젝트를 제외한 모든 프로젝트 유형은 최대 5개의 콜렉션을 포함할 수 있습니다. 데이터에 적합한 프로젝트 유형을 선택하십시오.

  검색 결과를 최적화하기 위해 다른 인리치먼트 및 구성 옵션이 다른 프로젝트 유형에 추가되는 콜렉션에 자동으로 적용됩니다. 자세한 정보는 다음 주제를 참조하십시오.

  • 프로젝트 설명
  • 기본 프로젝트 설정
  • 기본 조회 설정

• Discovery v2 API는 기타 개선사항 중에서 프로젝트 및 콜렉션을 설명하도록 변경되었습니다. 일부 API 호출은 콜렉션 레벨 대신 프로젝트 레벨에서 조치를 지원하도록 변경되었습니다 (예: 조회 제출 및 관련성 훈련 실행). 많은 다른 API 메소드가 변경되었으며 일부는 v2에서 사용할 수 없습니다. v1 및 v2 API 메소드의 자세한 비교는 API 버전 비교 를 참조하십시오.

서비스 계획 선택

Plus, Enterprise및 Premium 관리 플랜 중에서 선택하거나 Discovery Cartridge for IBM Cloud Pak for Data을 구매하여 온프레미스 설치를 선택하십시오. 하나를 선택하기 전에 각 계획 유형의 이점 및 한계를 검토하십시오.

• 플랜에 대한 자세한 정보는 Discovery 가격 플랜 을 참조하십시오.
• 아티팩트 한계에 대한 자세한 정보는 한계 세부사항 을 참조하십시오.

다음 표는 일반적으로 v1 과 v2간에 유사한 관리 배치에 대한 계획 유형을 표시합니다.

사용된 현재 스토리지, 문서 및 콜렉션에 대한 정보를 가져오려면 제품 사용자 인터페이스 헤더에서 환경 세부사항 아이콘을 클릭하십시오.

Lite 또는 Advanced와 같은 v1 플랜에서 v2 플랜으로 인플레이스 업그레이드를 수행할 수 없습니다. 새 v2 플랜을 작성한 후 데이터를 새 서비스 인스턴스로 이동해야 합니다. v1 에서 v2로 데이터를 마이그레이션하는 동안 v1 및 v2 인스턴스가 동시에 배치될 수 있습니다. 이 기간 동안 첫 번째 Plus 플랜 인스턴스에서 사용 가능한 30일무료 평가판을 사용해 보십시오.

업로드된 데이터

API를 사용하여 문서를 Discovery v1에 업로드한 경우 v2 에서 유사한 API를 사용하여 문서를 콜렉션에 업로드할 수 있습니다. 프로젝트 및 콜렉션의 새 배열을 설명하기 위해 프로세스를 자동화하는 데 사용하는 모든 워크플로우를 업데이트해야 합니다.

Discovery v1 에 수집한 원래 문서를 더 이상 사용할 수 없는 경우, 조회 API를 사용하여 Discovery v1에서 문서 텍스트를 추출할 수 있습니다. 그런 다음 Discovery v2의 콜렉션에 텍스트를 추가할 수 있습니다. 자세한 정보는 문서 복구 를 참조하십시오.

크롤링된 데이터

v1의 외부 데이터 소스에서 데이터를 크롤링한 경우에는 v2의 동일한 외부 데이터 소스에서 데이터를 계속 크롤링할 수 있습니다. 동일한 모든 데이터 소스가 지원됩니다.

외부 데이터 소스의 데이터를 사용하려면 v2 프로젝트 내에서 콜렉션을 다시 작성하고 데이터 소스를 크롤링하는 방법을 구성해야 합니다. 자세한 정보는 데이터 소스 개요 를 참조하십시오.

서비스에는 외부 데이터 소스에서 문서를 크롤링하고 수집하는 데 필요한 시간 및 자원이 필요합니다. 한 번에 하나씩 커넥터를 다시 작성하십시오. 마이그레이션 계획 스케줄에 데이터를 다시 크롤링하는 데 걸리는 시간을 고려하십시오.

사전 빌드된 데이터 콜렉션

다음 내장 데이터 소스 콜렉션은 v2:

Watson Discovery 뉴스

이 사전 강화된 데이터 소스는 v2에서 제공되지 않습니다. 뉴스 데이터를 가져오는 대체 방법에 대한 자세한 정보는 v2에서 뉴스 서비스 사용 을 참조하십시오.

COVID-19 킷

이 사전 빌드된 콜렉션은 IBM® watsonx™ Assistant 및 Discovery 를 사용하여 빌드된 동적 챗봇이 COVID-19에 대한 고객의 질문에 응답하도록 지원하기 위해 설계되었습니다. v2에서 유사한 솔루션을 빌드할 수 있습니다. COVID-19 질문에 대한 답변을 위해 신뢰할 수 있는 웹 사이트를 크롤링하는 콜렉션을 사용하여 대화식 검색 프로젝트 유형을 작성하십시오.

문서 ID 보유

문서 ID는 제품 사용자 인터페이스에서 업로드하거나 문서 추가 API 메소드를 사용하여 추가할 때 v2 콜렉션에 추가하는 문서에 지정됩니다.

이러한 고유 ID에 의존하는 프로세스를 사용하는 경우 v1 문서의 ID를 v2 에 보유할 수 있습니다. 예를 들어, 애플리케이션에 대한 회귀 테스트는 문서 ID를 검사하여 특정 문서가 리턴되는지 확인할 수 있습니다. 관련성 훈련은 문서 ID를 사용하여 훈련 실행 사이의 문서를 추적합니다. 이러한 프로세스는 문서 ID가 v1 및 v2 인스턴스 간에 동일한 경우 적용하기가 더 쉽습니다. 그렇지 않으면 Discovery v1 인스턴스와 함께 사용되는 프로세스가 Discovery v2 인스턴스에 추가된 후 문서에 지정된 ID에 다시 맵핑되어야 합니다.

v1 서비스 인스턴스에 문서를 추가할 때 사용자 고유의 문서 ID를 지정한 경우, 문서 추가 메소드 대신 문서 업데이트 메소드를 사용하여 ID를 보유할 수 있습니다. 갱신 메소드를 사용하여 v2 콜렉션에 추가할 때 문서에 문서 ID를 지정할 수 있습니다. 자세한 정보는 문서 업데이트를 참조하십시오.

데이터가 JSON 파일에 저장된 경우 원래 문서의 배열은 번호가 추가된 문서 ID를 생성합니다. 예를 들어, original_id_n입니다. 숫자 접미부 없이 원래 문서 ID를 유지하려면 JSON 파일에서 배열을 제거하십시오. 예를 들어, [ {"name": "value"} ] 를 {"name": "value"} 로 변경하십시오.

v1 문서에 시스템 생성 ID가 있는 경우 비어 있는 검색 조회 를 제출하여 문서 및 해당 ID의 목록을 검색할 수 있습니다. 그런 다음 v2의 새 콜렉션에 추가할 때 각 문서에 동일한 ID를 지정할 수 있습니다.

문서 복구

일부 경우에는 Discovery V1 에 수집된 원래 문서를 더 이상 사용할 수 없습니다. Discovery v1 인스턴스를 사용하여 문서에서 정보를 검색할 수 있습니다. Discovery 는 수집하는 각 문서의 텍스트 사본을 작성합니다. 사본은 텍스트 전용이므로 HTML, PDF 또는 기타 비텍스트 형식의 문서는 텍스트 전용 버전으로 변환됩니다.

이 방법을 사용하여 콜렉션에서 처음 10 ,000개의 문서만 복구할 수 있습니다. 10 ,000개 이상의 문서를 복구하는 방법에 대한 자세한 정보는 콜렉션에서 10 ,000개 이상의 문서 복구 를 참조하십시오.

v1 에서 v2로 문서 정보를 전송하려면 다음 단계를 완료하십시오.

1. 비어 있는 조회를 제출 하기 위해 API를 사용하여 v1 에서 문서를 추출하십시오.

   예를 들어, GET {url}/v1/environments/{environment_id}/collections/{collection_id}/query?q=입니다.

   API가 결과를 리턴합니다. matching_results 필드는 총 결과 수를 지정합니다. 결과 오브젝트는 일치하는 문서를 리턴합니다. 각 문서는 별도의 JSON 오브젝트로 리턴됩니다. 기본적으로 최대 10개의 문서를 리턴합니다.

   {
     "matching_results": 34,
     "session_token": "nnn",
     "results": [
       {"{result objects}":"{maximum of 10 by default}"}
     ]
   }
   

2. count 및 offset 매개변수를 사용하여 조회 결과를 페이지 이동하고 모든 문서를 저장할 수 있습니다.

   예를 들어, 한 번에 100개의 문서를 가져오려면 count 를 100 로 설정하고 offset 를 0 로 설정하고 조회를 제출할 수 있습니다.

   GET {url}/v1/environments/{environment_id}/collections/{collection_id}/query?q=&count=100&offset=0
   

   그런 다음 다시 계수를 100으로 설정할 수 있지만 이번에는 오프셋을 100으로 설정하여 다음 100개의 문서를 가져옵니다.

   GET {url}/v1/environments/{environment_id}/collections/{collection_id}/query?q=&count=100&offset=100`
   

   이 프로세스를 반복하여 모든 문서를 검색할 때까지 오프셋을 100씩 증가시키십시오.

3. 익스포트된 문서를 v2로 수집하도록 준비하십시오.

   Discovery v1 에서 가져온 각 결과 JSON 파일에는 텍스트, html및 기타 필드와 같은 원래 문서에서 추출된 데이터가 포함되어 있습니다. 사용자 정의 메타데이터가 v1에 업로드될 때 문서와 연관된 경우 JSON 파일에도 존재합니다. 또한 파일에는 v1 분석으로 생성된 여러 필드가 포함되어 있습니다. Discovery v2에 추가하는 문서의 일부로 이 데이터의 서브세트만 보유하십시오.

   다음 팁은 유지할 필드를 결정하는 데 도움이 될 수 있습니다.

   • Discovery v2에서 강화하거나 검색할 수 있도록 하려는 텍스트 컨텐츠가 있는 text 필드 또는 기타 필드를 포함하십시오.
   • 문서에 저장된 사용자 정의 메타데이터를 포함하십시오. 이 메타데이터는 일반적으로 Discovery 를 사용하는 애플리케이션에 특정하며 검색에서 문서를 필터링하는 데 사용됩니다. 예를 들어, metadata.customer_id입니다.
   • Discovery v1의 인리치먼트를 포함하지 마십시오. 예를 들어, enriched_text.entities. Discovery v2 는 자체 인리치먼트를 생성합니다.
   • 애플리케이션에서 사용되고 문서의 v1 버전에 고유한 정보를 포함하지 않는 한, Discovery 에 의해 생성되는 필드를 제외하십시오. 이 경우 문서가 Discovery v2에 수집될 때 바뀌지 않도록 필드의 이름을 바꾸십시오. 예를 들어, extracted_metadata.publicationdate 는 문서가 수집될 때 Discovery 에 의해 생성되는 필드입니다. 하위 문서가 원래 단일 소스 문서에서 생성된 방법을 이해하기 위해 v1 의 metadata.parent_document_id 정보를 보유하려고 할 수 있습니다.
   • 예약된 필드 이름이 있는 필드는 사용하지 마십시오. 자세한 정보는 필드 처리 방법 을 참조하십시오.

4. 편집된 각 v1 JSON 문서를 Discovery v2 인스턴스에 수집하십시오. Discovery v1 문서 ID는 Discovery v2에서 유지보수할 수 있습니다. 문서 ID를 보유하는 방법에 대한 자세한 정보는 문서 ID 보유 를 참조하십시오.

콜렉션에서 10 ,000개 이상의 문서 복구

조회는 최대 10 ,000개의 문서만 리턴할 수 있습니다. 그러나 콜렉션에서 10 ,000개 이상의 문서를 복구하려면 문서를 겹치지 않는 하위 그룹으로 분리하는 방법이 필요합니다. 각 하위 그룹에는 조회에서 리턴할 수 있는 10 ,000개 미만의 문서가 포함되어야 합니다. 그런 다음 결과를 통해 페이지 번호를 지정하여 문서를 검색할 수 있습니다.

결과에 대한 페이지 매김은 조회에서 리턴되는 최대 10 ,000개의 문서로 제한됩니다. 특히 count 및 offset 페이지 매김 매개변수의 결합된 사용은 10 ,000개의 문서를 초과할 수 없습니다.

문서를 겹치지 않는 하위 그룹으로 분리하는 한 가지 방법은 모든 문서에 존재하고 고유한 값을 포함하는 필드를 활용하는 것입니다. 예를 들어, SHA-1 필드는 원래 소스 파일의 해시를 포함하며 16진문자열 값으로 형식화됩니다. 콜렉션을 하위 그룹으로 나누는 방법으로 필드의 첫 번째 문자를 사용할 수 있습니다. SHA-1 이 16진값을 포함하므로 첫 번째 문자는 최대 16개의 가능한 값 (0-9또는 a-f) 을 가질 수 있습니다. first_char_of (SHA-1) == 0 로 필터링하는 경우 전체 콜렉션의 약 1/16을 리턴할 수 있습니다. 그런 다음 가능한 16개의 각 값을 반복하여 나머지 문서를 가져올 수 있습니다. 하위 그룹 중 하나에서 최적의 문서 수가 리턴되지 않으면 SHA-1 필드의 처음 두 문자를 사용하여 콜렉션을 대신 256개의 하위 그룹으로 나눌 수 있습니다.

애플리케이션이 조회 결과를 처리하는 방법 업데이트

애플리케이션이 조회 결과를 표시하는 방법은 v1 및 v2 조회 사이의 조회 결과 문서 구문 간 다음 차이로 인해 업데이트해야 할 수 있습니다.

• 엔티티 인리치먼트 레벨에서는 다음 정보가 v2: 에서 지원되지 않습니다.

  • 명확화
  • 감정
  • 감성

  Part of Speech 인리치먼트는 v2의 대부분의 프로젝트 유형에 있는 문서에 자동으로 적용되지만 인리치먼트에 의해 생성되는 색인 필드는 문서의 JSON 표시에 표시되지 않습니다.

  

• v1의 count 및 relevance 대신, v2 는 멘션을 포함합니다.

  멘션의 각 항목은 문서 텍스트에서 엔티티의 발생에 해당합니다. 다음 예제에서는 일곱 개의 발생이 발견되었습니다. 각 발생에 대해 멘션 텍스트의 오프셋 및 신뢰도 점수가 표시됩니다. 오프셋을 사용하여 결과가 사용자 인터페이스에 표시될 때 문서 텍스트에서 멘션을 강조표시할 수 있습니다.

  

• 조회 응답의 JSON 구조는 v2에서 약간 재배열됩니다.

• 데이터 중복 제거 정보는 v2 조회 응답에 포함되지 않습니다.

• v2에서 enriched_text 는 오브젝트 대신 배열입니다.

• Discovery v2에서는 엔티티 v2 인리치먼트가 사용됩니다. v2 의 엔티티 유형 이름은 모두 대문자가 아닌 헤드라인 문자로 지정됩니다. 엔티티 이름을 지정하는 조회 또는 집계를 사용하는 경우 대소문자를 변경해야 합니다. 예를 들어, PERSON 를 Person 로 변경하십시오.

• 콜렉션에 추가되는 JSON 파일의 필드는 v1 과 v2사이의 수집 중에 다르게 변환됩니다. 애플리케이션이 이러한 결과를 조작하는 경우 조정해야 할 수 있습니다.

  API의 콜렉션 업데이트 메소드에서 normalizations 및 conversions 오브젝트를 지정하여 JSON 필드를 이동하거나 병합할 수 있습니다.

  JSON 소스 필드를 처리하는 방법

  원래 JSON 필드 컨텐츠	v1 표시	v2 표시	참고
  "field": null	"field": null	해당사항 없음	v1 은 널값을 유지합니다. v2 는 널 필드를 모두 건너뜁니다.
  "field": ""	"field": ""	해당사항 없음	v1 은 빈 텍스트 값을 유지합니다. v2 는 비어 있는 텍스트 필드를 모두 건너뜁니다.
  "field": "value2"	"field": "value2"	"field": "value2"	차이가 없습니다.
  "field": []	"field": []	해당사항 없음	v1 은 빈 배열을 유지합니다. v2 는 비어 있는 배열이 있는 필드를 모두 건너뜁니다.
  "field": [ "value4" ]	"field": [ "value4" ]	"field": "value4"	v1 은 싱글톤 배열을 유지합니다. v2 는 싱글톤 배열을 값으로만 변환합니다. 배열의 일부로 저장되지 않습니다.
  "field": [ 1, 2, 3 ]	"field": [ 1, 2, 3 ]	"field": [ 1, 2, 3 ]	차이가 없습니다.
  "field": [ "v6", "v7", "v8" ]	"field": [ "v6", "v7", "v8"]	"field": [ "v6", "v7", "v8"]	차이가 없습니다.