추상 위키백과/자연어 생성 시스템 아키텍처 제안

아리엘 구트만의 제안

이 문서는 추상 위키백과에 대한 자연어 생성(NLG) 시스템에 대해 제안된 아키텍처를 설명합니다. NLG 시스템의 아키텍처를 고려할 때 다음 사항을 고려해야 합니다:

1. 모듈화: 시스템은 NLG의 다양한 측면(예: 형태 구문 및 음성 규칙)이 독립적으로 수정될 수 있다는 점에서 모듈식이어야 합니다.
2. 어휘력: 시스템은 어휘 데이터(코드와 별도로)를 가져올 수 있어야 하고 생산적인 언어 규칙에 의존하여 이러한 데이터를 즉석에서 생성할 수 있어야 합니다(예: 영어 복수형에 -s 사용).
3. 재귀: 대부분의 언어의 구성 및 재귀적 특성으로 인해, 효과적인 NLG 시스템이 필요합니다 그 자체로 재귀적이어야 한다.

추상 위키백과의 맥락에서 또 다른 제약 조건이 떠오릅니다:

4. 확장성: 시스템은 언어 전문가와 기술 기여자뿐만 아니라 시스템의 다른 부분에서 작업하는 비기술적 및 비전문가 기여자 모두가 확장할 수 있어야 합니다.

위의 제약 조건에서 단일 위키함수(=WF) 함수는 이러한 모듈식 NLG 시스템의 복잡성을 효과적으로 캡처할 수 없다고 가정하는 것이 합리적으로 보이지만 각각 NLG 파이프라인의 다른 단계를 담당하는 여러 함수가 관련되어야 합니다.

WF의 현재 디자인에서 개별 함수는 다음을 수행할 수 없습니다:

• 다른 WF 함수를 호출합니다.
• 위키데이터와 같은 외부 출처에서 데이터를 가져옵니다.
• 시스템의 일부 전역 상태를 변경합니다.

이러한 제한 사항을 극복하기 위해 이 문서에서는 이러한 제한 사항이 없는 WF 오케스트레이터에서 실행할 NLG 파이프라인을 제안합니다. 또한 비기술적 기여자가 참여할 수 있도록 맞춤형 WF 평가자가 실행할 수 있는 in-house 틀 언어 생성이 제안됩니다.

다른 접근 방식은 단일 WF 함수(다른 WF 함수를 호출함) 내에서 전체 NLG 파이프라인을 캡슐화하기 위해 WF 평가자의 설계 제한을 제거하는 것입니다. 이 접근 방식은 시스템 구현의 일부 측면을 변경하지만(예: 파이프라인 오케스트레이션 자체는 WF 기여자가 편집할 수 있음) 개념적 아키텍처는 여전히 대부분 동일하게 유지됩니다.

문서의 끝에 제안된 다른 접근 방식과의 짧은 비교가 제공됩니다.

아키텍처 개요

위에서 설명한 것처럼 전체 NLG 파이프라인은 단일 위키함수(=WF) 함수 내에서 캡슐화될 수 없으며 WF 오케스트레이터에 의해 실행되어야 합니다. WF(기여자에 의해 정의됨) 및 그렇게 하는 동안 필요한 상태를 유지합니다. 예상되는 아키텍처는 다음 다이어그램에 나와 있습니다. 진한 파란색 형식은 위키함수(사각형) 또는 위키데이터(둥근 사각형)에 기여한 사람이 만든 요소이고 연한 파란색 요소는 WF 오케스트레이터 내에 있는 함수 또는 데이터를 나타냅니다. 따라서 커뮤니티 기여에 직접적으로 적용되지 않습니다.

단계를 자세히 살펴보겠습니다:

1. 생성자 유형이 주어지면 특정 렌더러가 선택됩니다. 주어진 생성자에 포함된 데이터는 함수 인수로 렌더러에 전달됩니다.
2. 렌더러는 기본적으로 틀입니다. 정적 텍스트와 렌더러의 인수, 위키데이터의 어휘 또는 다른 렌더러의 출력으로 채울 수 있는 슬롯의 조합입니다. 틀은 비교적 이해하고 작성하기 쉽기 때문에 렌더러 작성은 비기술적 기여자도 접근할 수 있습니다.
3. 렌더러의 출력은 노드가 변형되지 않은 어휘(정리 정리로 식별됨)이고 일부 형태학적 제약이 추가된 종속성 구문 트리(예를 들어 범용 종속성(UD, Universal Dependencies) 또는 표면 구문 범용 종속성(SUD, Surface-Syntactic Universal Dependencies) 형식을 사용)입니다. 실제로 트리를 완전히 지정할 필요는 없습니다. 특히, 정적 텍스트는 반드시 트리의 일부일 필요는 없습니다.
4. 언어별 문법 사양에 의존하는 구문 트리의 구조와 결합된 형태학적 제약은 위키데이터에 있는 어휘 데이터에 따라 또는 문법 사양의 굴절 테이블을 사용하여 보조 정리의 굴절을 허용합니다. 이 단계의 출력은 품사 정보(즉, 단어가 명사, 동사, 전치사 등을 나타내는지 여부)로 최소한으로 주석이 달린 선형 텍스트 시퀀스입니다.
5. 이 단계에서는 언어별 "산디"(sandhi) 현상을 적용하여 음운 제약이 적용됩니다. 여기에는 문맥적 형태의 선택(예: 영어 "a/an") 또는 인접한 형태의 축약형/격절(예: 프랑스어 "de + le = du")이 포함될 수 있습니다.
6. 최종 정리 단계로 공백, 대문자 및 구두점을 조정하여 위키백과 문서에 저장할 최종 텍스트를 렌더링해야 할 수 있습니다. 이 단계는 이전 단계의 (언어 종속) 주석을 사용하여 언어에 구애받지 않는 방식으로 모델링할 수 있습니다.

위의 아키텍처에는 커뮤니티 구성원이 큐레이팅해야 하는 세 가지 구성 요소가 있습니다:

1. 템플릿 렌더러 - 모든 생성자가 언어당 하나의 템플릿 렌더러를 필요로 하기 때문에 필요한 작업의 대부분을 구성합니다(단, 문장의 일부에 대해 렌더러를 재사용할 수 있음). 여기서 "렌더러"라는 용어는 다국어 위키백과를 위한 아키텍처보다 좁은 의미로 사용됩니다. 후자에서 렌더러라는 용어는 종단 간 데이터-텍스트 함수를 나타내는 반면 여기에서는 렌더러라는 용어를 사용하여 NLG 파이프라인의 특정 구성 요소, 즉 템플릿을 나타냅니다. 위의 아키텍처에서 파이프라인의 다른 부분은 상대적으로 고정되어 있고 커뮤니티 구성원의 지속적인 큐레이션이 필요하지 않기 때문에 이것은 우연이 아닙니다.
2. 문법 사양 - 이들은 각 언어, 계층 구조 및 종속 관계를 통해 이러한 특성이 나타나는 방식에 필요한 관련 형태학적 기능을 지정해야 합니다. 이러한 사양은 위키데이터에 데이터로 저장되거나 위키함수에 함수로 저장될 수 있습니다(미정). 이러한 문법의 생성 및 큐레이션에는 상당한 언어 및 기술 지식이 필요할 수 있지만 (인간) 언어당 한 번 생성되기 때문에 이는 허용되는 것으로 간주됩니다.
3. 위키데이터 어휘소 - 이것들은 오늘날처럼 선별될 것이지만 그들이 사용하는 기능이 각 언어의 문법 사양과 일치하는 것이 중요할 것입니다.

템플릿 구조

커뮤니티 기여자에게 필요한 작업의 대부분은 템플릿 렌더러를 만드는 것이기 때문에 이 작업을 가능한 한 쉽게 만들고 특히 코딩 경험이 필요하지 않도록 하는 것이 중요합니다.

위키함수의 합성 "언어"와 유사하게 내부 틀 언어를 개발할 수 있습니다. 템플릿 언어는 세 가지 유형의 인수에 대해 언어 트리(UD 주석 포함)를 지정할 수 있어야 합니다:

• 정적 텍스트
• 위키데이터에서 보조정리를 가져오거나 다른 인수(예: 숫자)에서 보조정리를 즉시 생성하는 터미널 함수.
• 기타 렌더러

템플릿 언어에는 WF 조정자가 호출하는 전용 평가자 모듈이 있습니다. 후자는 위에서 설명한 NLG 파이프라인의 다양한 모듈을 통해 출력을 전달하는 역할을 합니다.

예시

사람의 나이를 전달하는 간단한 생성자가 있다고 가정해 보겠습니다.

Age(
  Entity: Malala Yousafzai (Q32732)
  Age_in_years: 24
)

이러한 생성자를 영어로 렌더링하기 위해 다음과 유사한 템플릿 표기법을 사용합니다(Z14/구현 유형):

{
 "type": "implementation",
 "implements": "Age_renderer_en",
 "template": {
   "part": {
     "role": "subject",  # grammatical subject     
     "type": "function call",
     "function": "Resolve_Lexeme",
     "lexeme": {
        "reference": "Entity"
      }
    },
  "part": {
    "role": "root",  # root of the clause     
    "type": "function call",
    "function": "Resolve_Lexeme",
    "lexeme": {
        "value": "be"  # replace with L-id
      }
    },
  "part": {
    "role": "num",  # numerical modifier
    "of": 4,  # Part 4 (“year”)   
    "type": "function call",
    "function": "Cardinal_number",
    "number": {
        "reference": "age_in_years"  
      }
    },
   "part": {
    "role": "npadvmod", 
    "of": 5,  # Part 5 (“old”)
    "type": "function call",
    "function": "Resolve_Lexeme",
    "lexeme": {
        "value": "year"  # replace with L-id
      }
    },
  "part": {
    "role": "acomp",
    "type": "string",
        "value": "old"      
    },
}
}

일부 구문 역할(npadvmod, acomp)은 실제로 합의 효과가 없으므로 생략할 수 있습니다.

문법 구조

문법에는 다음 정보가 포함되어야 합니다:

1. 언어에는 어떤 품사가 있습니다.
2. 각 품사에 적합한 문법적 특징
3. (아마도) 기능의 유형 계층
4. 문법적 관계(즉, 종속 관계)는 문법적 특징 및 품사와 어떻게 상호작용합니까?

첫 번째 요점은 주어진 언어에 사용할 수 있는 위키데이터 어휘에서 유추할 수 있지만 문법 정의의 일부로 명시적으로 만드는 것이 유용합니다. 이는 위키데이터 어휘 정의를 시행/유효화하기도 합니다. 언어별 유효성 검사기를 WF 함수로 작성할 수 있습니다. 그러면 위키데이터 어휘집에서 실행되어 언어 스키마에 따라 주석이 올바르게 추가되었는지 표시합니다.

문법 관계는 위키데이터의 데이터나 WF의 함수로 인코딩할 수 있습니다. 종속 관계는 노드의 문법적 기능을 통합하여 구현할 수 있습니다. 각 관계는 Unify 연산자를 기본 제공 함수로 사용하여 합성 WF 함수로 구현할 수 있습니다. 예를 들어, 영어에 대한 "subj" 관계는 다음과 같이 구현됩니다(속기 표기법 사용).

subj_en(noun, verb): 
    Unify(noun.pos, NOUN);  # Validate types
    Unify(verb.pos, VERB);
    Unify(noun.number, verb.number);
    Unify(noun.person, verb.person);
    Unify(noun.case, NOMINATIVE);

이렇게 구현된 subj 함수는 입력 인수에 영향을 미치기 때문에 순수 함수가 아닙니다(사실 통합 오류가 발생하지 않는 한 반환 값은 사용되지 않음). 일을 단순하게 유지하려면 이 특별한 동작을 함수 평가자가 지원해야 합니다.

하나로 통합되는 기능을 함께 묶고 싶을 수도 있습니다. 예를 들어, 숫자와 사람이 종종 함께 통합되는 것을 관찰하면 다음과 같은 하위 함수를 정의할 수 있습니다:

agr(left, right):
    Unify(left.number, right.number);
    Unify(left.person, right.person);

그런 다음 위의 subj 관계를 다음과 같이 재정의할 수 있습니다:

subj_en(noun, verb): 
    Unify(noun.pos, NOUN);  # Validate types
    Unify(verb.pos, VERB);
    agr(noun, verb);
    Unify(noun.case, NOMINATIVE);

문법 및 렌더링의 모듈식 설계

같은 어족의 언어들이 문법적, 구조적 유사성을 보이는 경우가 종종 있습니다. 언어 및 언어군 계층을 정의하여 이 현상을 이용할 수 있으며 NLG 시스템이 (하위) 렌더러 또는 (하위) 관계의 가장 구체적인 구현에 대한 동적 디스패치를 사용할 수 있습니다.

다른 접근 방식

지금까지 추상 위키백과의 NLG를 처리하기 위해 제안된 두 가지 다른 시스템을 알고 있습니다.

1. 문법 프레임워크(GF, Grammatical framework)는 다국어 자연어 생성 및 이해를 지원하기 위해 확립된 기능적 프로그래밍 언어입니다(뉴스레터 설명 참조). 컴퓨터 과학자, 언어학자 및 이에 기여하는 기타 애호가로 구성된 번성하는 커뮤니티가 있습니다.
2. Ninai/Udiron은 커뮤니티 회원 마히르 모르셰드가 구축한 파이썬 기반 NLG 시스템으로 위키데이터의 어휘 데이터를 사용하고 UD 트리를 사용하여 결합합니다. 이 시스템은 추상위키백과 프로젝트를 염두에 두고 구축되었습니다. 생성자의 몇 가지 흥미로운 예와 생성 방법은 Ninai 데모에서 찾을 수 있습니다.

두 시스템은 다르지만 유사한 축을 따라 이 문서에 요약된 제안과 대조될 수 있습니다:

• 두 시스템 모두 상대적으로 추상적이고 구성적인 의미 표현을 문법 구조로 변환한 다음 텍스트로 변환하는 데 적합합니다.
• 그들은 도메인 특정 언어(GF) 또는 일반 프로그래밍 언어(파이썬)와 같은 일부 프로그래밍 기술을 마스터해야 합니다.
• 출력 텍스트의 단어 순서는 전체 NLG 파이프라인에 의해 결정됩니다(예: 질문 연산자를 추가하면 영어의 단어 순서가 변경될 수 있음).
• 문법 정의가 올바른 한, 출력은 문법적으로 보장됩니다.

반면에 이 문서에 요약된 제안은 사전 기술 지식이 없는 사람들도 가능한 한 쉽게 기여할 수 있도록 하기 위한 것입니다. 이것은 다음을 의미합니다:

• 구체적이고 비구성적이며 의미론적 표현으로 작동할 수 있습니다(위의 Age 예제와 같이). 그러나 이것은 더 추상적인 표현을 처리하는 것을 배제하지 않습니다.
• 엔트리 레벨에서는 템플릿 렌더러를 작성하는 데 프로그래밍 기술이 거의 필요하지 않습니다. 언어학에 대한 지식(특히 종속성 주석)은 문법적 출력을 달성하는 데 유용할 수 있으며 문법 사양 자체를 작성하는 데 필요합니다.
• 단어의 순서는 템플릿 자체에 의해 결정되며 나중에 파이프라인에서 변경되지 않습니다.
• 템플릿이 올바르게 설계되지 않은 경우 출력이 비문법적일 수 있습니다.