데이터 검증

데이터 검증이 필요한 이유는 무엇일까요? 간단히 말해, 사용자가 악의적인 데이터를 제출하는 것을 방지하기 위함입니다.

AI 모델은 학습 및 미세 조정을 위해 많은 양의 정제되고 검증된 데이터가 필요합니다. 이 시스템의 철학은 모델이 점점 더 강력해지도록 돕는 검증된 데이터 기여자에게 보상을 제공하는 인센티브 시스템을 구축하는 것입니다. 반면, 악의적인 데이터를 제출하는 사용자에게는 처벌이 가해집니다.

이 목표를 달성하기 위해, 우리의 프레임워크는 탈중앙화 네트워크가 공유된 계산 순서에 동의하는 플랫폼에 적용됩니다. 이 공유된 코드에는 스마트 계약이 사용됩니다. 스마트 계약은 데이터 필드를 포함하고, 새로운 코드 및 이벤트와 메서드 호출을 통해 상호작용합니다. 온체인에서의 계산은 스마트 계약 내에서 수행되는 계산을 의미하며, 일반적으로 계산의 입력과 결과는 블록체인에 저장됩니다. 반면 오프체인은 클라이언트의 로컬 머신에서 계산이 이루어질 수 있으며 반드시 공개될 필요는 없습니다.

전통적인 법률 시스템에서는 계약을 위반할 경우 벌금이나 처벌이 부과될 수 있습니다. 스마트 계약을 통해 벌금을 부과하는 것은 복잡합니다. 사용자가 지불하도록 강제할 수 없기 때문입니다. 대신 블록체인 분야의 많은 솔루션은 사용자가 규칙을 준수할 경우 나중에 회수할 수 있는 '스테이킹' 보증금을 요구합니다. 이러한 시스템과 유사하게, 우리는 새로운 데이터를 제출하기 위한 일부 인센티브 메커니즘을 간소화하기 위해 보증금을 스테이킹하는 방안을 제안합니다.

(1) 인센티브 메커니즘은 거래를 검증하며, 때때로 “스테이킹” 또는 금전적 보증금이 필요합니다.

(2) 데이터 핸들러는 데이터를 블록체인에 저장하고 메타데이터를 기록합니다. 이를 통해 해당 데이터는 스마트 계약에 국한되지 않고 모든 미래의 용도로 접근할 수 있도록 보장됩니다.

(3) 머신러닝 모델은 미리 정의된 학습 알고리즘에 따라 업데이트됩니다. 데이터 추가 외에도, 누구나 모델에 대해 예측을 요청할 수 있으며, 이때 인센티브 메커니즘이 작동하여 사용자에게 보상을 제공할 수 있습니다.

다음은 "비트코인" 주제와 관련된 두 개의 트윗 예시입니다.:

첫 번째 트윗은 영어로 작성되어 있으며, #Bitcoin 해시태그가 포함되어 있어 계산 모델에 대해 간단하게 처리할 수 있습니다.
두 번째 트윗은 "Flatbread"라는 단어를 사용하여 비트코인을 지칭합니다. 이 단어는 영어로는 비트코인과 명시적으로 관련이 없지만, 중국어에서는 비트코인을 잘 알고 있는 용어입니다.

이 경우, 두 개의 트윗 모두 검증 노드를 통해 예측 과정을 통과하게 됩니다. 그런 다음, 두 트윗 모두 BTC로 레이블이 붙고 데이터셋에 추가되어 공유 가능한 업데이트 가능한 모델을 미세 조정하는 데 사용됩니다. 수집되고 검증된 데이터셋이 많을수록 새로운 데이터를 추가하여 모델을 미세 조정함으로써 모델의 성능이 더욱 강화될 것입니다.

스테이킹 기반 자체 평가 메커니즘

부정확한 데이터를 제출하는 것에 대한 벌금이나 처벌을 부과하는 것은 최적의 프레임워크에서 이상적입니다. 데이터 품질을 평가하는 일반적인 방법 중 하나는 피어 검증을 활용하는 것으로, 이는 전통적인 크라우드소싱 모델에서 널리 인식되는 기법입니다. 그러나 제출 후 스마트 계약을 통한 벌금 집행은 특정한 도전 과제를 동반합니다. 따라서 데이터 기여 시점에 보증금 메커니즘을 통합하여 벌금 부과 과정을 간소화합니다.

특별히 배포된 모델인 h는 새로 제출된 데이터를 검증하는 데 중요한 역할을 합니다. 이 모델은 데이터 입력을 정확하게 분류할 수 있는 능력을 보장하기 위해 초기 학습을 거쳐야 한다는 점이 중요합니다. 이 과정은 여러 가지 중요한 단계로 구성됩니다:

모델 배포: 데이터의 하위 집합에 대해 사전 훈련된 모델 h를 검증 프로세스에 도입합니다.
보증금 요구: 모든 데이터 제출에 대해 보증금이 요구되며, 이 보증금은 데이터 x와 관련된 레이블 y를 포함합니다. 이는 데이터와 메타데이터가 블록체인에 안전하게 기록되도록 보장하며, 데이터 기여에 대한 책임감과 품질을 촉진하는 환경을 만듭니다.
환불: 시간 t가 경과한 후, 현재 모델 h가 원래 제출된 분류와 여전히 일치하는 경우(즉, h(x) == y), 기여자는 전체 보증금 d를 반환받을 수 있습니다.

– 이제 (x, y)가 “좋은” 데이터라고 가정합니다.

– 보증금의 성공적인 반환은 지갑 주소에 대한 포인트 집계에 기록되어야 합니다.

• 데이터 제출 및 보증금 청구: 이미 환불 단계에서 데이터 검증을 받은 기여자는 모델의 출력이 h(x)와 일치하지 않는 데이터 포인트 (x, y)를 찾아 초기 제출 시 제공된 보증금의 일부를 요청할 수 있습니다.

제출된 샘플 (x, y)가 잘못되었거나 유효하지 않은 경우, 시간 t 이내에 다른 기여자들은 (x, y₀)를 제출해야 하며, 여기서 y₀는 x에 대한 올바르거나 최소한 일반적으로 선호되는 레이블이고 y₀는 y와 다릅니다. 이는 일반적으로 잘못된 편집이 있는 위키피디아 기사가 신속하게 수정되는 방식과 유사합니다.

보증금 청구: 환불 단계에서 이전에 검증된 데이터가 있는 기여자는 모델의 출력이 h(x)와 일치하지 않는 데이터 항목 (x, y)를 식별할 권한을 가지며, 이를 통해 원래 제공한 보증금의 일부에 대한 청구를 시작할 수 있습니다. 이 메커니즘은 시스템 내 데이터 무결성 유지에 대한 인센티브를 제공하기 위해 설계되었습니다. 제출된 데이터셋이 잘못되거나 유효하지 않은 것으로 판단될 경우, 다른 네트워크 참가자들이 (x, y₀)를 제출하여 수정을 제안할 수 있도록 정의된 기간이 할당됩니다. 여기서 y₀는 y와 다른 x에 대한 올바르거나 널리 받아들여지는 레이블을 나타냅니다. 이 절차는 위키피디아와 같은 플랫폼에서 관찰되는 협업 편집 및 수정 동역학을 반영하여 부정확성을 신속하게 수정할 수 있도록 합니다.

환불 대기 시간: 스마트 계약 프레임워크 내에서 t는 기여자가 보증금에 대한 환불 청구를 시작하기 전에 기다려야 하는 기간을 설정하는 중요한 시간 매개변수 역할을 합니다. t는 데이터의 불일치를 발견할 경우, 다른 네트워크 참가자들이 대체 레이블로 수정 제출을 할 수 있는 기회를 제공하기 위해 충분히 길어야 합니다. 예를 들어, t를 최소 일주일로 설정하면 이 과정을 촉진할 수 있습니다. 이러한 지연은 민감도가 낮은 모델에 특히 중요하며, 모델이 새로운 시나리오에 적응하는 데 필요한 다양한 샘플을 충분히 축적할 시간을 제공합니다.

민감도가 높은 모델은 독특한 도전을 제기합니다. 이 모델들은 부정확하게 제출된 데이터에 대해 환불을 조기에 청구할 수 있게 허용하여, 다른 기여자들의 수정 작업이 가능하기 전에 환불이 이루어질 수 있습니다. 이러한 위험을 완화하기 위해, 모델들은 빠른 악의적인 제출을 방지하기 위한 보증금 요구 사항이 상당히 높아져야 합니다. t의 결정을 내리기 전에 철저한 테스트와 신중한 고려가 필요하며, 모델의 민감도와 데이터 정확성 필요성 사이의 균형을 최적화해야 합니다.

다양한 보증금: 보증금 요구 사항의 구현은 시스템 내에서 여러 가지 목표를 수행합니다.:

가치 주입: 보증금은 생태계에 가치를 주입하여 정확한 데이터를 기여하는 참가자에게 보상을 제공합니다. 이를 통해 고품질 정보를 제출하도록 유도합니다.
모델 수정 억제: 보증금은 모델을 과도하게 자주 수정하는 것을 방지하여 시스템의 안정성과 신뢰성을 유지하는 역할을 합니다.
스팸 차단: 여기서 스팸은 부정확하거나 유효하지 않은 데이터 제출로 정의되며, 보증금은 이러한 스팸의 유입을 줄여 전반적인 데이터 무결성을 향상시킵니다.

이러한 목표를 실현하기 위해, 기여자가 짧은 시간 내에 많은 업데이트를 제출하는 것이 엄청난 비용이 들도록 하는 특정 방정식이 사용됩니다. 이 접근법은 모델의 예측 기능 사용자에게 보다 일관되고 신뢰할 수 있는 경험을 제공하는 것을 목표로 합니다. 이 원칙의 한 가지 설명적인 예시는 개인 비서 장치가 하루에 여러 번 동일한 음성 명령에 대해 일관된 응답을 제공해야 한다는 기대입니다. 예를 들어, 뉴스 재생 요청과 같은 경우입니다.

다른 기여자의 보증금 차감: “부정확한” 데이터를 보고하는 기여자가 원래 기여자 c의 보증금에서 일부를 차감할 수 있도록 가이드라인을 도입합니다. 기여된 데이터와 그에 대한 메타데이터는 데이터 핸들러나 발생된 이벤트에서 확인할 수 있다는 점에 유의해야 합니다.

먼저, 몇 가지 정의를 제시합니다.:

• r(Cr, d): 기여 보고자 Cr이 보증금 d와 함께 데이터 **(x, y)**를 보고함으로써 받는 보상입니다.

• n(c): 기여자 c가 환불받은 데이터 샘플의 수(좋은 데이터로 가정)입니다.

가이드라인:

• h(x) != y: 현재 모델이 레이블에 대해 일치하지 않습니다. 따라서 해당 데이터는 “부정확한” 것으로 가정합니다.

• n(cr) > 0: 보고자는 이미 환불된 데이터가 있어야 합니다. 이는 그들이 시스템에서 이익을 얻기 전에 “좋은” 데이터를 제출했을 가능성이 높음을 보장합니다.

• cr != c: 보고자는 원래 기여자가 될 수 없습니다. 그렇지 않으면 기여자들이 “부정확한” 데이터에 대해 쉽게 보증금을 청구하려고 시도할 수 있습니다.

• 보상은 “좋은” 기여자들 사이에서 공유되어야 합니다.

– 이는 기여자가 두 번째 계정을 사용하여 전체 보증금을 되찾는 시빌 공격(Sybil Attack)을 방지합니다. 기여자는 여전히 다른 계정에서 일부 보상을 청구할 수 있지만, 그 다른 계정을 사용하여 “좋은” 데이터에 대한 환불을 기다려야 합니다.

r(cr, d) > ε > 0: 보상은 잠재적인 거래 비용을 충당할 수 있는 최소한의 가치를 가져야 합니다.
데이터 핸들러는 청구 가능한 남은 보증금 dr ≤ d를 추적해야 합니다.

n(c)가 시간이 지남에 따라 변하기 때문에, 보고자들이 보증금 d의 몫을 청구하는 동안 (3)에서의 비율도 변화합니다. 따라서 일부 보고자는 d의 더 작은 비율을 받을 수 있습니다. 이러한 문제에 대한 몇 가지 가능한 해결책은 III-C5에서 논의합니다.

모델 편향: 제안된 시스템 하에서는 기여자들이 제출 시점에서 현재 모델의 예측과 일치하는 데이터를 주로 제출할 가능성이 있습니다. 이는 환불 기간 동안 모델이 이전의 동의 상태를 유지할 것이라는 기대에서 비롯됩니다. 이러한 전략은 모델 내에서 확인 편향을 초래하여, 이전에 접한 데이터를 재확인하는 방향으로 편향될 수 있습니다. 기여자가 거래 수수료를 부담해야 하므로 보증금을 예치하고 환불을 받는 데 최소한의 비용이 발생하지만, 이는 편향된 데이터 제출의 위험을 완전히 완화하지는 못합니다.

따라서 모델 선택 및 학습 방법론은 매우 중요해지며, 데이터 제출의 수용 및 처리에 대한 전략적 접근이 필요합니다. 시스템 설계자는 데이터셋의 다양성과 대표성을 저해할 수 있는 중복되거나 지나치게 유사한 데이터 항목의 영향을 식별하고 완화할 수 있는 메커니즘을 구현해야 합니다. 이를 위해 정보 관리자(Information Manager, IM)는 이전에 제출된 데이터를 과도하게 반복하는 제출을 거부할 수 있는 권한을 가지고 있어야 하며, 이는 모델이 다양한 정보에 지속적으로 노출되도록 보장합니다.

잠금 방지: 이 섹션에서는 자금이 스마트 계약 내에 “잠겨” 있거나 “갇히는” 것을 방지하는 방법에 대해 논의합니다. 기여자가 환불을 받는 것을 잊거나 기여자가 보증금의 일부를 차지하지 않을 경우, 가치가 계약 내에 “갇히게” 될 수 있습니다. 이를 피하기 위해 두 가지 새로운 매개변수를 도입합니다:

• tc: 특정 기여에 대한 남은 환불 (dr)을 받기 위해 창작자가 기다려야 하는 시간입니다. 여기서 tc > t입니다. 이 매개변수는 창작자가 모델을 배포할 때, 보증금 d의 상당 부분을 청구할 기회를 제공하므로 창작자를 유도합니다. 계약에서는 이것이 환불을 시도하기 위해 기다려야 하는 시간보다 훨씬 더 길어야 한다고 강제할 수 있으며, 이는 기여자가 보증금을 회수할 더 많은 시간을 제공하고 창작자가 너무 많은 것을 차지하지 못하도록 합니다. (tc ≥ t).

• ta: 모든 사람이 남은 환불 (dr)을 받기 위해 기다려야 하는 시간입니다. 여기서 ta ≥ tc > t입니다. 이는 창작자가 계약에서 "잠긴" 가치를 가져가는 것을 누락할 경우 사용됩니다.

실제로, 환불된 제출물 (n(c) > 0)을 가진 데이터 기여자를 위한 값 td와 같은 다양한 변형이 있을 수 있으며, 여기서 ta ≥ td ≥ tc입니다.

이 섹션에서는 자금이 스마트 계약 프레임워크 내에서 접근할 수 없거나 "잠겨" 버리는 것을 방지하기 위한 전략을 설명합니다. 기여자가 환불을 받는 것을 잊거나, 지정된 보증금의 일부를 청구하지 않아 계약 내에서 자금이 미청구 상태로 남아 있는 경우가 발생할 수 있습니다. 이러한 상황을 완화하기 위해 두 가지 새로운 매개변수가 도입됩니다.:

tc: 이 매개변수는 창작자가 특정 기여에 할당된 남은 환불 (dr)을 청구할 수 있는 자격이 생기기까지 기다려야 하는 기간을 지정합니다. 조건 tc > t는 창작자들이 모델을 배포하도록 유도하는 역할을 하며, 기여자들이 청구하지 않을 경우 상당한 부분 d를 차지할 수 있는 기회를 제공합니다. 계약에서는 tc가 환불 시도에 대한 최소 대기 기간을 상당히 초과하도록 명시하는 것이 권장되며, 이는 기여자들에게 보증금을 회수할 충분한 기회를 제공하고 창작자가 인출할 수 있는 금액을 제한합니다 (tc ≥ t).
ta: 이 매개변수는 어떤 당사자가 남은 환불 (dr)을 청구하기 위해 기다려야 하는 기간을 정의합니다. ta ≥ tc > t라는 조건은 창작자가 계약에서 "잠긴" 자금을 회수하는 것을 잊는 상황에서 특히 중요합니다.

추가적으로, 성공적으로 제출물에 대한 환불을 받은 기여자를 위해 td와 같은 매개변수의 추가 조정이 고려될 수 있습니다 (n(c) > 0). 이때 ta ≥ td ≥ tc라는 조건이 성립합니다. 이러한 조치는 시스템 내에서 자금의 원활한 순환을 보장하고 스마트 계약 내에서 미청구 자산의 축적을 방지하며, 모델의 배포 및 개선 과정을 동적이고 반응적으로 촉진하기 위해 설계되었습니다.

현대 디지털 생태계에서 스마트폰, 태블릿, 노트북 등 최종 사용자 장치의 컴퓨팅 능력은 주로 충분히 활용되지 않고 있으며, 완전히 활용되지 않은 처리 능력이 잉여로 나타나고 있습니다. 이러한 환경에서 사용자는 주변 장치에서 특정 알고리즘을 포함하는 dApp을 실행하며 네트워크와 상호작용합니다. 이 참여는 네트워크 전반에 걸쳐 데이터 검증을 촉진하는 동시에 기초 모델의 반복적인 개선에도 기여합니다. 또한, 각 검증 노드는 과거의 컴퓨팅 자원 기여도와 네트워크 참여 기간에 따라 명성 점수를 부여받습니다. 높은 명성을 가진 노드는 더 많은 작업을 맡게 되며, 그에 따라 더 큰 보상을 받습니다. 이러한 메커니즘은 작업과 보상을 공정하게 분배하여 네트워크의 무결성과 효율성을 강화합니다.

最后更新于1个月前