스마트 엔터티 해결

스마트 엔터티 해결은(는) 무엇을 하나요?

신뢰할 수 있는 답변을 확립할 수 있는 가장 낮은 수준의 노력으로 정체성을 해결하세요. 기존 식별자, 매핑 또는 확인 증거가 불충분한 경우에만 수준을 높이십시오. 이 스킬은 진정으로 모호한 사람 및 조직 레코드(경쟁 프로필 또는 미디어 후보 포함)에 적용됩니다. 일반적인 이미지 처리 및 결정론적 ID 조인에는 필요하지 않습니다.

핵심 원칙

엔터티 해결을 조회가 아닌 단계별 조사로 취급하세요. 정확한 검색, 슬러그 조회, 인기도, LLM 판단은 모두 유용한 신호이지만, 어느 하나가 다른 신호를 묵묵히 지배해서는 안 됩니다.

세 가지 질문을 분리하세요:

• 범위: 요청된 모든 엔터티를 열거했습니까?
• 정체성: 이 후보가 요청된 사람 또는 조직을 대표합니까?
• 유용성: 이 작업에 가장 적합한 사용 가능한 레코드입니까?

약한 정체성 증거를 가진 고유용성 레코드는 거짓 긍정(위양성) 위험입니다. 정체성은 인기도, 프로필 완성도, 이미지 가용성 및 검색 순위보다 우선합니다.

해결 수준

가장 낮은 충분한 수준을 선택하세요. 더 높은 수준이 필수 전제 조건은 아닙니다.

• 레벨 0 — 직접 식별: 권위 있는 안정적인 ID, 표준 URL 또는 확인된 계정 식별자와 일치시킵니다. 작업이 해결되면 중단합니다.
• 레벨 1 — 결정론적 조정: 명시적 크로스워크, 검토된 별칭, 문서화된 출처별 ID 또는 확인된 정체성 링크를 사용합니다. 매핑을 절대 발명하지 마십시오.
• 레벨 2 — 맥락적 식별: 이벤트, 세션, 시간에 적합한 소속, 개인 프로필, 프로젝트 소유권 또는 독립적으로 확인된 출처 식별자를 사용하여 이름을 확증합니다. 후보 또는 증거가 충돌할 때 수준을 높입니다.
• 레벨 3A — 공식 프로필 검색: 자체 관리 웹사이트 및 소셜 계정, 공식 발표자 페이지, 고용주 디렉토리, 프로젝트 및 저자 프로필을 찾습니다. 다른 신뢰할 수 있는 출처에서 링크된 프로필을 선호합니다.
• 레벨 3B — 독립적 확인: 독립적인 출처 간의 식별자, 별칭, 이벤트, 프로젝트, 소속 및 날짜를 비교합니다. 한 전기의 신디케이트된 복사본은 별도의 확인으로 간주되지 않습니다.
• 레벨 3C — 별칭 및 과거 기록 조정: 예명, 철자 변형, 음역, 과거 고용주, 인수 및 교차 이벤트 출현을 명시적 매핑 또는 독립적 확인을 사용하여 해결합니다. 소속은 시간 범위를 지정하여 유지합니다.
• 레벨 3D — 후보 복구: 별칭 및 맥락화된 이름을 검색하고, 직접 ID, URL 및 슬러그를 탐색하며, 일반 조회가 그럴듯한 레코드를 놓칠 때만 LLM을 사용하여 대상 검색 프로브를 제안합니다. 생성된 후보는 확인된 정체성이 아닙니다.
• 레벨 3E — 고충실도 판정: 정체성 증거, 출처 권위, 과거 일관성, 충돌하는 레코드 및 의미 있는 대안을 비교합니다. LLM은 후보를 요약하거나 재순위화할 수 있지만 출처 기반 식별을 대체할 수는 없습니다.
• 레벨 4 — 민감 또는 미해결: 정체성이 모호하게 남아 있거나, 영구적 병합 또는 게시가 결과를 초래하거나, 개인 정보가 노출되거나, 생체 인식 식별이 필요할 때 명시적 검토가 필요합니다. ambiguous, needs_review 또는 unresolved를 반환합니다.

선호 출처

정체성 및 현재 자기표현을 위해 자체 관리 출처를 우선시합니다:

1. 개인 웹사이트, 블로그 또는 확인된 개인 도메인.
2. X/Twitter 계정.
3. LinkedIn 프로필.
4. GitHub 프로필.
5. Hugging Face 프로필.
6. Google Scholar, Semantic Scholar, ORCID 또는 arXiv 저자 프로필.
7. 개인 YouTube 채널.
8. Substack, Medium 또는 Dev.to 프로필.
9. Bluesky 또는 Mastodon 계정.

상호 링크, 일관된 핸들, 공유 도메인, 프로젝트 소유권 및 게시 이력은 정체성을 강화합니다. 일치하는 표시 이름 또는 플랫폼 배지만으로 계정 소유권이 확립되지는 않습니다.

질문이 변경되면 출처 우선순위를 변경하세요:

• 이벤트 참여 및 과거 소속: 주최자 발급 ID, 공식 발표자 페이지 및 일정, 이벤트별 전기, Sessionize 또는 Accelevents 기록 및 동시대 발표 자료는 이후 프로필보다 우선합니다.
• 현재 역할 또는 자기표현: 최근에 유지 관리된 개인 웹사이트, 확인된 소셜 계정 또는 현재 고용주 페이지는 오래된 컨퍼런스 전기보다 우선합니다.
• 표준 프로필 사진: 해당 인물의 확인된 자체 선택 프로필 이미지, 승인된 주최자 헤드샷 또는 안정적인 ID에 연결된 공식 이벤트 초상화를 선호합니다. 공개 URL이 이미지 재배포 또는 훈련 권한을 부여하는 것은 아닙니다.
• 일반 검색: 웹 결과를 사용하여 후보를 검색하거나 사실을 확인합니다. 검색 순위를 증거로 취급하지 마십시오.

추측된 썸네일, 인근 세션 사진, 얼굴 유사성 또는 생체 인식 임베딩을 확인된 정체성 증거로 취급하지 마십시오.

작업 흐름

1. 검색 전에 쿼리를 분류합니다. 단일 엔터티, 엔터티 목록 또는 모호한 그룹/캐스트/멤버/팀/조직 쿼리인지 감지합니다. members, cast, lineup, team, company, subsidiaries 및 leadership과 같은 용어는 일반적으로 확장이 필요함을 의미합니다.

2. 조회 전에 명령형 쿼리를 구문 분석합니다. 사용자는 종종 find the full profiles for..., guess the grouping that includes... 또는 resolve these partial names...와 같은 작업 텍스트에 엔터티 힌트를 포함합니다. 엔터티 힌트 영역을 추출하고, 원래 지침을 컨텍스트로 유지하며, 전체 지침 문자열을 리터럴 데이터베이스 쿼리로 보내지 마십시오.

3. 직접 식별 또는 문서화된 매핑이 불충분한 경우에만 모호한 쿼리를 엔터티 그룹으로 확장합니다. 개인 또는 조직을 열거할 필요가 있을 때 LLM 또는 검색 도구를 사용하십시오. 별칭은 하나의 엔터티 아래에 그룹화합니다.

4. 엔터티 그룹별로 광범위하게 검색합니다. 각 엔터티에 대해 여러 별칭, 정리된 변형, 대상 데이터베이스가 지원하는 경우 정확한 슬러그 또는 직접 ID 후보, <group> <short name>과 같은 맥락화된 짧은 이름 쿼리를 검색합니다. 로컬 엔터티별 쿼리 추적을 사용하십시오. 전역 쿼리 중복 제거는 공통 별칭을 가진 이후 엔터티를 굶주리게 할 수 있습니다.

5. 결정론적 검색이 비어 있거나 약할 때 LLM 검색 계획자를 고려합니다. 계획은 재순위화와 별개입니다. 직접 ID, URL 슬러그, 정확한 이름 프로브, 별칭 및 맥락적 검색을 요청하십시오. 프로브를 제한적이고 정밀하게 유지합니다.

6. 안정적인 레코드 정체성으로 후보를 병합합니다. 프로필 ID, 슬러그, 표준 URL, 데이터베이스 ID 또는 다른 안정적인 키로 중복을 제거합니다. 가장 높은 점수를 받은 경로만 유지하지 말고 후보를 찾은 모든 쿼리와 출처를 보존합니다.

7. 재순위화 전에 후보를 보강합니다. 정체성, 출처, 유용성, 모호성 및 신뢰도에 걸쳐 개념적 증거를 수집합니다. 재순위화 도구가 이름만으로 선택하도록 해서는 안 됩니다.

8. 진정으로 경쟁하는 후보에 대해서만 제한된 LLM 재순위화를 사용합니다. 다른 패스가 범위를 실질적으로 개선하거나 가능한 정체성을 구분할 수 있을 때만 계속합니다.

9. 결정을 변경하거나 수정을 가능하게 할 수 있을 때 의미 있는 대안을 표시합니다. 권위 있는 정확한 ID 일치는 제조된 차점자가 필요하지 않습니다.

10. 미해결 및 불확실을 일급 결과로 취급합니다. needs review, no plausible match 또는 ambiguous를 고유용성 거짓 긍정을 조용히 채우는 것보다 선호합니다.

부분 이름 및 모호한 지침

쿼리에 대부분 이름, 짧은 별칭, 이니셜 또는 부분 조직 이름이 포함된 경우 원시 데이터베이스 히트를 충분한 것으로 취급하지 마십시오. 그룹화 용어, 전체 프로필 의도 또는 대부분 하나의 토큰 이름으로 직접 결과를 신뢰할 수 없을 때 확장하거나 분류하십시오.

쿼리의 두 가지 표현을 유지하십시오:

• originalQuery: 전체 사용자 지침 및 컨텍스트.
• entityHints: 해결할 후보 이름 또는 별칭의 추출된 목록.

확장 모델은 둘 다 볼 수 있어야 합니다. 가능한 공유 컨텍스트를 추론하고 그룹화된 별칭과 함께 구체적인 엔터티를 반환하도록 요청하십시오. 각 확장된 엔터티에 대해 레이블과 별칭을 보존한 다음 해당 엔터티 분기 내에서 해당 별칭을 검색하십시오. 직접 검색 경로는 간단한 정확한 이름에 대해 여전히 실행될 수 있지만, 부분 힌트에서 전체 정체성을 추론하는 데 범위가 의존할 때 확장을 억제해서는 안 됩니다.

범위는 결과 볼륨과 별개입니다. 많은 원시 후보를 생성하는 다섯 개의 요청된 힌트는 각 힌트가 선택된 엔터티 또는 명시적 미해결/모호함 결과에 매핑될 때까지 해결되지 않습니다. expectedCount, resolvedCount, ambiguousCount 및 unresolvedHints 또는 동등한 필드를 추적하십시오.

검색 계획 및 격차 복구

검색이 반환하지 않은 레코드를 재순위화 도구가 구출하는 데 의존하지 마십시오. LLM 참여를 별도의 역할로 분할하십시오:

• 확장 모델: "대상 엔터티는 누구 또는 무엇입니까?"
• 검색 계획자 또는 복구 모델: "검색기가 이 대상에 대해 시도해야 할 정확한 ID, 슬러그, 직접 URL, 별칭 및 검색 프로브는 무엇입니까?"
• 재순위화 모델: "이러한 보강된 후보가 주어졌을 때 올바른 레코드는 어느 것입니까?"

직접 슬러그 또는 ID가 누락된 레코드를 복구할 수 있거나, 엔터티에 후보, 사용 가능한 데이터가 없거나 약한/일반 이름 일치만 있는 경우에만 검색 계획을 사용하십시오. 계획자에게 원래 쿼리, 그룹화된 별칭, 시도된 프로브, 출처 실패 및 관련 출처 제약 조건을 제공하십시오. 정체성 결정이 아닌 프로브를 반환해야 합니다.

복구를 제한적이고 비례적으로 유지합니다. 유용한 프로브에 대해 결정론적 검색을 실행하고, 복구된 후보를 병합하며, 추가 검색이 답을 변경할 가능성이 낮을 때 엔터티를 미해결로 표시합니다.

로깅 및 팬아웃

작업에 비례하여 출처 출처, 선택된 ID, 모호성 및 범위를 기록합니다. 원시 개인 페이로드는 피합니다. 독립적인 엔터티 그룹이 이미 동시에 처리되고 있는 경우 분기 상태를 격리하고 결정론적으로 병합합니다. 이 스킬을 충족시키기 위해서만 팬아웃, 원격 측정 인프라 또는 재시도를 도입하지 마십시오.

증거 모델

증거를 개념적이고 이식 가능하게 유지합니다. 한 사이트의 필드에 과적합하지 마십시오.

• 정체성 증거: 정확한 이름 또는 ID 일치, 별칭, 예명, 법적 이름, 로마자 변형, 공유 토큰, 누락된 기본 토큰, 컨텍스트 일치, 알려진 조직/그룹 관계 및 충돌하는 이름.
• 출처 증거: 어떤 쿼리가 후보를 찾았는지, 검색, 정확한 슬러그, 직접 URL, 데이터베이스 ID, API 조회, 웹 결과, 사용자 제공 출처, 검색 계획자 프로브 또는 복구 패스에서 왔는지.
• 유용성 증거: 이미지 수, 프로필 완성도, 활동성, 인기도, 조회수, 투표수, 목록 수, 직원 수, 관계 수, 확인 상태, 최신성 및 레코드에 작업에 사용 가능한 미디어 또는 메타데이터가 있는지.
• 모호성 증거: 짧은/일반 이름, 성만 일치, 이니셜, 중복 레코드, 그룹/프로젝트 페이지, "and the" 페이지, 희소 레코드, 충돌하는 별칭, 이전 이름, 병합된 조직, 자회사 또는 유사한 이름의 공인.
• 신뢰도 증거: 선택된 후보, 차점 후보, 재순위화 이유, 미해결 상태, 인간 검토 필요 플래그 및 원래 쿼리의 범위 상태.

재순위화 규칙

진정한 모호성이 이를 보장할 때, 출처 증거와 작업에 적합한 예산에 따라 제한된 LLM 재순위화를 사용하십시오.

• 재순위화 도구에 원래 쿼리, 해결된 엔터티 레이블, 별칭, 후보 이름/ID/URL, 출처, 정체성 증거, 유용성 증거 및 모호성 경고를 제공합니다.
• 정체성을 유용성보다 먼저 선택하도록 지시합니다. 정체성 증거가 약하면 이미지가 풍부하거나 인기 있는 후보를 선택해서는 안 됩니다.
• 그럴듯하게 동일한 정체성의 후보에 대해서는 유용성이 결정하도록 합니다. 공개 예명 또는 브랜드 이름 레코드는 작업 관련 증거가 더 강력한 경우 법적 이름 레코드보다 더 나을 수 있습니다.
• 하나의 토큰 별칭을 컨텍스트, 정확한 ID/슬러그, 더 풍부한 별칭 중복 또는 강력한 외부 증거에 의해 지원되지 않는 한 모호한 것으로 취급합니다.
• 하드 수용 규칙을 피합니다. 직접 별칭 히트는 신호이지 증거가 아닙니다.
• 하드 거부 규칙을 피합니다. 로마자 표기, 리브랜딩, 희소 또는 예명 레코드는 불완전해 보일 수 있지만 여전히 정확할 수 있습니다.
• 동등하게 잘 지원되는 후보가 실질적으로 더 나은 작업 유용성을 가지고 있는 경우, 정체성 증거를 조용히 재정의하기보다는 후보를 노출하거나 하나의 정당화된 추가 비교를 수행합니다.
• 선택된 후보에 대한 이유를 기록하거나 표시하고 대안을 계속 표시합니다.

실패 모드

해결사가 "대부분 작동"하지만 이상하게 느껴질 때 검토 확인 사항으로 사용하십시오.

• 정확한 데이터베이스 검색은 실제 레코드를 놓칠 수 있습니다. 가능할 때 정확한 슬러그, 직접 URL, ID 또는 대체 엔드포인트를 탐색하십시오.
• 짧은 이름은 거짓 긍정을 생성합니다. Lisa, Rose, Sunny, Tiffany, Yuri 및 유사한 단일 토큰 이름에는 컨텍스트 검색 및 모호성 경고가 필요합니다.
• 법적 이름은 유용성 레코드가 더 나쁠 수 있습니다. 공개/예명 또는 브랜드 이름이 더 완전한 프로필, 더 많은 이미지 또는 더 최신 메타데이터를 가질 수 있습니다.
• 유용성 신호는 강력하지만 단독으로는 안전하지 않습니다. 개수, 투표, 조회수 및 인기도는 정체성 타당성 이후에만 동점을 깨야 합니다.
• 복합 별칭은 유용한 컨텍스트이지만 종종 검색 문자열로서는 좋지 않습니다. 그룹 정체성을 유지하면서 별칭으로 분할하십시오.
• 하드 직접 수락 로직은 취약합니다. 하나의 별칭이 일치했다는 이유만으로 일반 중복을 잡을 수 있습니다.
• 하드 정체성 게이트는 취약합니다. 이름이 희소하거나, 번역되거나, 로마자 표기되거나, 리브랜딩되거나, 예명만 있는 경우 올바른 레코드를 숨길 수 있습니다.
• 범위 개수는 정확성이 아닙니다. 6개 중 6개의 엔터티를 찾는 것이 성공은 아닙니다. 선택된 레코드 중 하나가 잘못된 사람이나 조직인 경우 실패입니다.
• 전역 쿼리 중복 제거는 이후 엔터티를 굶주리게 할 수 있습니다. 공통 별칭은 엔터티 그룹별로 추적해야 합니다.
• 출처 불안정성은 결과의 일부입니다. 시간 초과, 403, 404, 재시도 및 부분 데이터는 출처 또는 디버그 로그에 표시되어야 합니다.
• 재순위화 도구는 누락된 후보를 수정할 수 없습니다. 대상 브랜치에 후보가 0명이면 재순위화 전에 검색 계획 또는 복구를 삽입하십시오. 재순위화 도구가 숨겨진 레코드를 추론할 것으로 기대하지 마십시오.
• 지침 텍스트는 리터럴 검색을 오염시킬 수 있습니다. 작업 구문을 컨텍스트로 유지하면서 조회 쿼리에서 제거하십시오.
• 빠른 직접 결과는 확장을 억제할 수 있습니다. 정확한 ID는 즉시 중단할 만한 충분한 이유가 아닙니다. 특정 시나리오에 대해 평가합니다.