추상 위키백과/업데이트/2022-11-04

추상 위키백과 업데이트

하나의 반지, 아니면 천 개의 꽃?

추상 위키백과 작업 흐름 중 하나는 수백 개의 언어로 위키백과 문서를 만들고 유지 관리하는 데 필요한 자연어 생성 작업에 중점을 둡니다. 다른 작업 흐름과 달리 이 작업은 위키함수의 즉각적인 미래와 출시에 초점을 맞추지 않고 위키함수를 사용할 수 있고 다른 위키미디어 프로젝트, 특히 위키데이터 및 위키백과에 연결되면 필요한 다음 단계를 탐구합니다.

이전 뉴스레터에서 우리는 추상 위키백과의 자연어 생성에 대한 몇 가지 접근 방식과 작업에 대해 이야기했습니다. 마히르 모르셰드는 니나이와 우디론에 대해 이야기했고, 우리는 프로젝트의 개발과 디자인에 큰 영향을 미친 문법적 프레임워크에 대해 이야기했고, 아리엘 구트만과 마리아 키트는 틀 언어 사양(현재 스크리분토 구현과 함께 제공)을 발표했습니다. Diff에 대한 최근 업데이트가 있었습니다.

이 세 가지 솔루션으로 작업이 완료되었습니까? 이제 자연어 생성에 대한 솔루션이 어떻게 생겼는지 알 수 있습니까?

모르겠습니다. 그것은 아마도. 이러한 솔루션은 수십 년간 축적된 경험을 바탕으로 매우 똑똑한 사람들에 의해 개발되었습니다. 이러한 구현이 현재 수행하는 가장 중요한 목표는 존재 증명을 제공하는 것이며 솔루션이 가능하다는 것을 보여줍니다. 그들은 추상 위키백과의 목표가 너무 고상하지 않다는 것을 보여줍니다. 문법적 프레임워크는 추상 위키백과 전체에 대해 그렇게 했습니다. 문법적 프레임워크가 없었다면 추상 위키백과 프로젝트가 존재하지 않았을 것이라고 감히 말할 수 있습니다.

그러나 이러한 솔루션 중 추상 위키백과가 궁극적으로 취할 접근 방식이 있습니까?

모르겠습니다. 한 가지 주요 참신함은 추상 위키백과가 매우 다양한 기술 수준을 가진 많은 기여자에게 확장할 수 있다는 이점이 있다는 것입니다. 일부는 숙련된 프로그래머, 일부는 숙련된 언어학자, 다른 일부는 모국어 수준의 기술을 가져올 수 있습니다. 자원 봉사자 위키미디어인 커뮤니티에 적합한 솔루션은 무엇입니까? 이것은 미리 예측하기가 매우 어렵습니다. 이것이 바로 우리가 아직 특정 솔루션에 전념하기를 원하지 않는 이유입니다.

가능한 솔루션의 캄브리아기 폭발을 보고 싶습니다. 이것이 위키함수가 모든 종류의 기능을 허용하는 이유 중 하나이며 명시적으로 튜링 완전입니다. 그래서 우리는 단일 아키텍처, 단일 솔루션에 성급하게 자신을 가두지 않습니다. 다양한 접근 방식이 시도되고 커뮤니티가 이러한 접근 방식을 기반으로 장점과 단점에 대해 논의하고 활동을 통해 발로 투표하기를 기대합니다.

예, 결국 우리는 단일 솔루션으로 통합해야 합니다. 벵골어의 자연어 생성이 다른 추상적인 내용을 사용하여 하우사어의 자연어 생성과 완전히 다르게 작동한다면 분명히 비극적인 실수가 될 것입니다. 그러나 때로는 특정 언어에 고유한 일부 형태학적 또는 문법적 기능을 개발한 다음 전체 텍스트를 생성하기 위해 전체 아키텍처에 통합해야 할 수도 있습니다. 그 예는 니제르 콩고 언어의 명사 클래스 또는 모음과 자음이 삽입된 아랍어와 히브리어의 형태입니다.

커뮤니티가 솔루션을 선택하고 구현하고 추구하는 데 전적으로 앞장서고 있다고 봅니다. 그러나 저는 커뮤니티의 행동을 통해 대부분 암묵적으로 발생하고 단일 솔루션에 대해 토론하고 투표하는 명시적인 수단에 의해 발생하지 않는다는 것을 알고 있습니다. 저는 우리가 한 가지 방법으로 섣불리 결정하기를 바라지 않고, 오히려 열린 자세를 유지하고 실험과 새로운 아이디어를 초대하기를 바랍니다. 가능한 아이디어의 공간은 매우 방대하고 우리 커뮤니티에 더 잘 맞는 솔루션을 선택하는 이점은 너무 커서 우리가 창의적이라는 것이 합리적입니다.

저는 개발이 네 가지 다른 수준의 진화를 겪을 것으로 기대합니다.

첫 번째 수준: 간단한 조회 테이블로 시작할 수 있습니다. 언어를 기반으로 올바른 언어로 관련 단어나 구를 선택하여 도시에 대한 짧은 설명을 반환하는 함수가 있을 수 있습니다. 위키데이터에는 영어로 “city”라는 짧은 설명이 있는 550개 항목이 있고 “scientific paper”가 있는 항목은 1,700개 이상, 프랑스어로 “article scientifique”라는 짧은 설명이 있는 항목은 400개 이상 있습니다. 이러한 간단한 조회 테이블로도 이미 위키데이터에 있는 수천 개의 항목에 대한 설명을 개선할 수 있습니다.

두 번째 수준: 예를 들어 "아제르바이잔의 도시" 또는 "이스라엘의 도시"(각 50회 발생) 또는 "프랑스 작가"와 같은 짧은 설명을 만들기 위해 틀 구조의 인수를 허용하여 가능성을 광범위하게 확장할 수 있습니다. 또는 "아르헨티나 화학자". 이러한 단순한 패턴은 많은 수의 항목에 유용할 뿐만 아니라 이미 놀라운 수의 극단적인 경우를 발견하는 데에도 유용합니다. 이것은 위키데이터 설명에 유용할 뿐만 아니라 위키백과 문서에도 이미 유용할 수 있습니다. 영어 위키백과의 Rambot 또는 스웨덴어의 LSJbot과 같은 많은 봇이 정확히 이와 같이 작동했습니다.

세 번째 수준: 틀에 생성자를 추가합니다. 생성자를 사용하면 개별 문장에서 전체 문서를 작성할 수 있습니다. 전체 분류에 대한 모델 문서를 사용하는 대신 이제 수동으로 작성된 문서를 허용합니다. 이것은 동시에 작업을 더 쉽고 더 어렵게 만듭니다. 생성자는 이제 재사용할 수 있어야 하기 때문에 전체 문서보다 모듈식 문장과 비슷해야 합니다.

네 번째 수준: 세 번째 수준에서 생성자의 수가 증가할 것이므로 더 작은 언어 커뮤니티에서 수행해야 하는 작업의 양을 억제하는 것을 목표로 해야 합니다. 이것은 생성자를 위한 추상 렌더러를 사용하여 달성할 수 있습니다. 다음과 같이 영어로 직접 틀을 사용하는 대신 상을 받을 수 있습니다(예제는 단순화됨)

“{person} received the {award} on {date}”

(다시 단순화 됨)과 같은 추상 (즉, 언어 독립적) 렌더러가 있습니다.

“Clause(subject=person, predicate=Q76664785, object=award, time=date)”

차례로 언어 종속 렌더러가 있지만 그 수가 적습니다. 이것은 종종 덜 관용적인 결과로 이어집니다.

지금까지의 솔루션 중 일부는 두 번째 또는 세 번째 수준에서 잘 작동하고 다른 솔루션도 네 번째 수준을 처리할 수 있는 것 같습니다. 세 번째 수준은 네 번째 수준이 아닌 특정 종류의 사용자 경험에 적합합니다. 균형을 맞추는 데에는 장점과 단점이 있습니다.

이 뉴스레터의 목표는 그러한 발전을 처방하는 것이 아닙니다. 개발 계획과 달리 우리는 이러한 수준을 실현하기 위해 적극적으로 노력하지 않을 것입니다. 우리는 이러한 특정 수준을 거칠 필요가 없으며 다른 영역의 수준에 대해 균일할 필요도 없습니다. 어떤 영역에서는 첫 번째 수준이 완전히 충분할 수 있고, 다른 영역에서는 네 번째 수준에 대해 설명된 아이디어를 사용하여 번창할 수 있으며, 다른 영역에서는 설명된 수준에 전혀 맞지 않을 수도 있습니다. 괜찮습니다.

이 뉴스레터의 목표는 내 생각과 결정을 설명하고, 이전에 언급한 다양한 시스템과 접근 방식이 어떻게 조화를 이루는지 보여주고, 우리가 어디로 가고 있고 어떤 기여를 원하는지 합리적으로 예측할 수 있도록 하는 것입니다. 이것은 또한 여러분 모두를 위한 초대입니다. NLG 시스템은 우리 모두가 함께 개발할 것입니다.

"(이 에세이에 대해 활발한 토론을 해준 자원봉사자와 팀, 특히 아리엘 구트만, 마리아 키트, 데이비드 마틴, 마히르 모르셰드, 안 란타에게 감사드립니다. 여기에 반영된 의견은 특히 데니의 의견입니다.)"

자원봉사 코너

다음 주, 11월 7일 월요일, 18:30 UTC에 다음 자원 봉사 코너를 개최할 예정입니다. 여기에서 가입할 수 있습니다: https://meet.google.com/evj-ktbq-hbn

직원 편집 토론이 종료됩니다

기부 활동이 진정되었고, 곧 직원 편집 토론을 종료할 계획입니다.

새로운 개발자 채널

IRC의 #wikipedia-abstract-tech^접속 채널(텔레그램에도 연결됨)을 위키함수 및 추상 위키백과 주변의 개발자 및 기술에 보다 중점을 둔 공간으로 사용할 것입니다. 우리 채널은 여기에 문서화되어 있습니다: 추상 위키백과#참야

2022년 10월 28일 주간 개발 업데이트

경험 및 성능:

오케스트레이터에서 유형 확장 방지 (T297742)
작업 요약 구성 요소를 제거했습니다.
ZFunction 및 ZObject 생성 중 필수 필드와 선택 필드에 따라 정렬
게시 구성 요소에 대한 최종 디자인
더 많은 FE 버그 수정
또 다른 테스트를 완료했습니다

메타 데이터:

모든 오류 유형의 읽을 수 있는 요약의 초기 구현 (T312611)

자연어 생성:

UI 및 문법 판단에 대한 문서 공유
틀 언어에 대한 진전
틀 생성 GUI 데모 제작 (github)