shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
블랙보드와 유사한 시스템은 현대 베이즈 기계 학습 설정 내에서 구축되었으며, 에이전트를 사용하여 베이즈 네트워크 노드를 추가하고 제거한다. 이러한 '베이즈 블랙보드' 시스템에서 발견법은 가능한 구조 공간을 통한 메트로폴리스 헤이스팅스 샘플링에서 제안 및 수락으로서 더 엄격한 확률적 의미를 얻을 수 있다. 반대로, 이러한 매핑을 사용하면 구조 공간에 대한 기존 메트로폴리스-헤이스팅스 샘플러는 저자에 의해 그렇게 명명되지 않았더라도 이제 블랙보드 시스템의 한 형태로 볼 수 있다. 이러한 샘플러는 예를 들어 음악 전사 알고리즘에서 일반적으로 발견된다.
블랙보드 시스템은 미디어 콘텐츠 주석을 위한 대규모 지능형 시스템을 구축하는 데도 사용되어 전통적인 사회 과학 연구의 일부를 자동화했다. 이 도메인에서는 다양한 AI 알고리즘을 단일 지능형 시스템에 통합하는 문제가 자연스럽게 발생하며, 블랙보드는 분산된 모듈식 자연어 처리 알고리즘 모음이 동작을 조정할 필요 없이 중앙 공간의 데이터를 각자 주석을 달 수 있는 방법을 제공한다.
울산피피주식회사는 대한민국의 석유화학 회사로 폴리프로필렌등을 제조, 판매하는 회사이다.
인공지능의 하위 분야로서 진단(diagnosis)은 시스템의 동작이 올바른지 여부를 판단할 수 있는 알고리즘과 기술 개발과 관련이 있다. 시스템이 올바르게 작동하지 않는 경우, 알고리즘은 시스템의 어느 부분이 실패하고 어떤 종류의 오류에 직면해 있는지 가능한 한 정확하게 판단할 수 있어야 한다. 계산은 현재 동작에 대한 정보를 제공하는 관찰을 기반으로 한다.
진단이라는 표현은 시스템이 오작동하는지 여부에 대한 질문에 대한 답변과 답변을 계산하는 과정을 의미하기도 한다. 이 단어는 진단이 증상에 따라 질병을 식별하는 과정인 의학적 맥락에서 유래한다.
진단의 예는 자동차 정비공의 과정이다. 정비사는 먼저 자동차에 대한 관찰과 해당 유형의 차량에 대한 지식을 바탕으로 비정상적인 행동을 감지하려고 할 것이다. 만약 그가 행동이 비정상적이라는 것을 발견하면, 정비사는 결함이 있는 부품을 발견할 때까지 새로운 관찰을 사용하고 시스템을 테스트하여 진단을 개선하려고 할 것이다. 정비사는 차량 진단에 중요한 역할을 한다.
전문가 진단.
전문가 진단(또는 전문가 시스템에 의한 진단)은 시스템에 대한 경험을 기반으로 한다. 이 경험을 사용하여 관찰을 해당 진단과 효율적으로 연결하는 매핑이 구축된다.
경험은 다음을 통해 제공될 수 있다.
이러한 방법의 주요 단점은 다음과 같다.
약간 다른 접근 방식은 전문성에서 직접 구축하는 대신 시스템 모델에서 전문가 시스템을 구축하는 것이다. 예를 들어 이산 사건 시스템 진단을 위한 진단자를 계산하는 것이다. 이 접근 방식은 모델 기반으로 볼 수 있지만, 전문가 시스템 접근 방식의 일부 장점을 얻고 일부 단점을 겪는다.
모델 기반 진단.
모델 기반 진단은 시스템의 모델을 사용하는 귀추법의 한 예이다. 일반적으로 다음과 같이 작동한다.
시스템(또는 인공물)의 동작을 설명하는 모델이 있다. 이 모델은 시스템 동작의 추상화이며 불완전할 수 있다. 특히, 결함 동작은 일반적으로 잘 알려져 있지 않으므로 결함 모델이 표현되지 않을 수 있다. 시스템의 관찰이 주어지면 진단 시스템은 모델을 사용하여 시스템을 시뮬레이션하고 실제로 수행된 관찰을 시뮬레이션이 예측한 관찰과 비교한다.
모델링은 다음 규칙에 의해 단순화될 수 있다(여기서 formula_1는 비정상 술어이다).
formula_3 (결함 모델)
이 공식의 의미는 다음과 같다. 시스템의 동작이 비정상이 아니면(즉, 정상이면) 내부(관찰 불가능한) 동작은 formula_4이고 관찰 가능한 동작은 formula_5이다. 그렇지 않으면 내부 동작은 formula_6이고 관찰 가능한 동작은 formula_7이다. 관찰 formula_8가 주어지면, 시스템 동작이 정상인지 아닌지(formula_9 또는 formula_10)를 결정하는 것이 문제이다. 이것은 귀추법의 한 예이다.
진단 가능성.
시스템의 동작이 어떻든 상관없이 모호함 없이 고유한 진단을 결정할 수 있다면 그 시스템은 진단 가능하다고 한다.
진단 가능성 문제는 시스템을 설계할 때 매우 중요하다. 왜냐하면 한편으로는 비용을 줄이기 위해 센서 수를 줄이고 싶을 수 있고, 다른 한편으로는 결함 동작을 감지할 확률을 높이기 위해 센서 수를 늘리고 싶을 수 있기 때문이다.
이러한 문제를 다루는 여러 알고리즘이 존재한다. 한 부류의 알고리즘은 시스템이 진단 가능한지 여부에 대한 질문에 답하고, 다른 부류는 시스템을 진단 가능하게 만들고 선택적으로 비용 최적화와 같은 기준을 준수하는 센서 세트를 찾는다.
시스템의 진단 가능성은 일반적으로 시스템 모델에서 계산된다. 모델 기반 진단을 사용하는 애플리케이션에서는 이러한 모델이 이미 존재하며 처음부터 구축할 필요가 없다.
DX 워크숍.
DX는 1989년에 시작된 진단 원리에 관한 연례 국제 워크숍이다.
창발 알고리즘(emergent algorithm)은 창발적 행동을 보이는 알고리즘이다. 본질적으로 창발 알고리즘은 결합될 때 더 복잡한 행동을 보이는 일련의 단순한 빌딩 블록 행동을 구현한다. 한 가지 예는 환경 장애물에 대한 로봇 움직임을 조정하는 데 사용되는 퍼지 모션 컨트롤러의 구현이다.
창발 알고리즘은 다음과 같은 특징을 가진다.
창발 알고리즘 및 모델의 다른 예로는 셀룰러 오토마타, 인공신경망 및 떼 지능 시스템(개미 군집 최적화, 벌 군집 알고리즘 등)이 있다.
신경망 구조 탐색(Neural architecture search, NAS) 또는 신경 구조망 탐색은 기계 학습 분야에서 널리 사용되는 모델인 인공 신경망(ANN)의 설계를 자동화하는 기술이다. NAS는 수동으로 설계된 아키텍처와 동등하거나 더 나은 성능을 내는 네트워크를 설계하는 데 사용되어 왔다. NAS 방법은 사용되는 탐색 공간, 탐색 전략 및 성능 추정 전략에 따라 분류할 수 있다.
NAS는 하이퍼파라미터 최적화 및 메타 학습과 밀접하게 관련되어 있으며 자동화된 기계 학습(AutoML)의 하위 분야이다.
강화 학습(RL)은 NAS 탐색 전략의 기반이 될 수 있다. 배럿 조프(Barret Zoph)와 쿠옥 비엣 르(Quoc Viet Le)는 CIFAR-10 데이터셋을 대상으로 RL과 NAS를 적용하여 정확도 면에서 최고의 수동 설계 아키텍처에 필적하는 네트워크 아키텍처를 달성했다. 오류율은 3.65%로, 관련 수동 설계 모델보다 0.09% 더 좋고 1.05배 더 빨랐다. 펜 트리뱅크 데이터셋에서는 LSTM을 능가하는 순환 셀을 구성하여 테스트 세트의 혼란도 62.4에 도달했으며, 이는 이전 최고의 시스템보다 3.6 더 좋은 혼란도이다. PTB 문자 언어 모델링 작업에서 문자당 비트(bits per character)는 1.214를 달성했다.
대규모 데이터셋에서 모델 아키텍처를 직접 학습하는 것은 긴 과정일 수 있다. NASNet은 작은 데이터셋을 위해 설계된 빌딩 블록을 더 큰 데이터셋으로 전이하여 이 문제를 해결했다. 설계는 두 가지 유형의 합성곱 셀을 사용하여 입력 특징 맵을 합성할 때 두 가지 주요 기능을 수행하는 특징 맵을 반환하도록 제한되었다. 즉, 동일한 범위(높이 및 너비)의 맵을 반환하는 일반 셀과 반환된 특징 맵의 높이 및 너비가 2배 감소하는 감소 셀이다. 감소 셀의 경우, 셀의 입력에 적용되는 초기 연산은 두 개의 스트라이드(높이 및 너비를 줄이기 위해)를 사용한다. 설계의 학습된 측면에는 각 상위 레이어가 입력으로 어떤 하위 레이어를 취하는지, 해당 레이어에 적용되는 변환, 각 레이어에서 여러 출력을 병합하는 것과 같은 요소들이 포함되었다. 연구된 예시에서 최적의 합성곱 레이어(또는 "셀")는 CIFAR-10 데이터셋을 위해 설계된 다음, 이 셀의 복사본을 각각 고유한 매개변수와 함께 쌓아서 이미지넷 데이터셋에 적용되었다. 이 접근 방식은 상위-1 정확도 82.7%와 상위-5 정확도 96.2%를 달성했다. 이는 90억 FLOPS를 덜 사용하면서(28% 감소) 인간이 고안한 최고의 아키텍처를 능가하는 결과였다. 이 시스템은 다양한 계산 수준에서 수동 설계된 대안을 계속해서 능가했다. 이미지 분류에서 학습된 이미지 특징은 다른 컴퓨터 비전 문제로 전이될 수 있다. 예를 들어, 객체 탐지의 경우, Faster-RCNN 프레임워크와 통합된 학습된 셀은 COCO 데이터셋에서 성능을 4.0% 향상시켰다.
이른바 효율적인 신경망 구조 탐색(ENAS)에서 컨트롤러는 큰 그래프 내에서 최적의 서브그래프를 탐색하는 방법을 학습하여 아키텍처를 발견한다. 컨트롤러는 정책 기울기를 사용하여 검증 세트의 예상 보상을 최대화하는 서브그래프를 선택하도록 훈련된다. 서브그래프에 해당하는 모델은 표준 교차 엔트로피 손실을 최소화하도록 훈련된다. 여러 하위 모델이 매개변수를 공유하므로 ENAS는 다른 접근 방식보다 GPU-시간을 적게 필요로 하며 "표준" NAS보다 1000배 적게 필요하다. CIFAR-10에서 ENAS 설계는 2.89%의 테스트 오류율을 달성했으며, 이는 NASNet과 유사하다. 펜 트리뱅크에서 ENAS 설계는 55.8의 테스트 혼란도에 도달했다.
NAS에 대한 대안적인 접근 방식은 여러 그룹에서 채택된 진화 알고리즘에 기반한다. 신경망 구조 탐색을 위한 진화 알고리즘은 일반적으로 다음 절차를 수행한다. 먼저, 다양한 후보 아키텍처와 그 유효성 점수(적합도)로 구성된 풀이 초기화된다. 각 단계에서 후보 풀의 아키텍처는 변형된다(예: 5x5 합성곱 대신 3x3 합성곱). 다음으로, 새로운 아키텍처는 몇 에포크 동안 처음부터 훈련되고 유효성 점수가 얻어진다. 이어서 후보 풀에서 가장 낮은 점수를 받은 아키텍처는 더 좋고 새로운 아키텍처로 대체된다. 이 절차는 여러 번 반복되며, 따라서 후보 풀은 시간이 지남에 따라 개선된다. ANNs 진화 맥락에서 변형은 레이어를 추가하거나 제거하는 것과 같은 연산이며, 여기에는 레이어 유형 변경(예: 합성곱에서 풀링으로), 레이어의 하이퍼파라미터 변경 또는 훈련 하이퍼파라미터 변경이 포함된다. CIFAR-10 및 이미지넷에서 진화와 RL은 비슷한 성능을 보였고, 둘 다 무작위 탐색을 약간 능가했다.
베이즈 최적화.
하이퍼파라미터 최적화를 위한 효율적인 방법으로 입증된 베이즈 최적화(BO)는 NAS에도 적용될 수 있다. 이 맥락에서, 목적 함수는 여러 에포크 동안 훈련된 아키텍처를 해당 검증 오류에 매핑한다. 각 반복에서 BO는 이전에 얻은 아키텍처와 그 검증 오류를 기반으로 이 목적 함수를 모델링하기 위해 대리 모델을 사용한다. 그런 다음 탐색과 활용 사이의 균형을 제공하는 예상 개선과 같은 획득 함수를 최대화하여 평가할 다음 아키텍처를 선택한다. 획득 함수 최대화 및 목적 함수 평가는 NAS에서 종종 계산 비용이 많이 들고, 이 맥락에서 BO의 적용을 어렵게 만든다. 최근 BANANAS는 신경 예측자와 결합된 고성능 BO 인스턴스화를 도입하여 이 방향으로 유망한 결과를 달성했다.
힐 클라이밍.
다른 그룹은 네트워크 형태를 적용한 후 짧은 코사인-어닐링 최적화 실행을 따르는 힐 클라이밍 절차를 사용했다. 이 접근 방식은 경쟁력 있는 결과를 산출했으며, 단일 네트워크를 훈련하는 것과 동일한 자원 규모를 요구했다. 예를 들어, CIFAR-10에서 이 방법은 단일 GPU에서 12시간 만에 오류율 5% 미만의 네트워크를 설계하고 훈련했다.
다중 목표 탐색.
대부분의 접근 방식은 최대 예측 성능을 가진 아키텍처를 찾는 데만 초점을 맞추지만, 대부분의 실제 응용 프로그램에서는 메모리 소비, 모델 크기 또는 추론 시간(즉, 예측을 얻는 데 필요한 시간)과 같은 다른 목표가 중요하다. 이 때문에 연구자들은 다중 목표 탐색을 만들었다.
LEMONADE는 여러 목표를 효율적으로 최적화하기 위해 용불용설을 채택한 진화 알고리즘이다. 각 세대에서 자식 네트워크는 현재 ANN 모집단에 대한 파레토 프론티어를 개선하기 위해 생성된다.
Neural Architect는 네트워크 임베딩 및 성능 예측을 통한 자원 인식 다중 목표 RL 기반 NAS라고 주장된다. 네트워크 임베딩은 기존 네트워크를 훈련 가능한 임베딩 벡터로 인코딩한다. 임베딩을 기반으로 컨트롤러 네트워크는 대상 네트워크의 변환을 생성한다. 다중 목표 보상 함수는 네트워크 정확도, 계산 자원 및 훈련 시간을 고려한다. 보상은 컨트롤러 네트워크와 사전 훈련되거나 공동 훈련된 여러 성능 시뮬레이션 네트워크에 의해 예측된다. 컨트롤러 네트워크는 정책 기울기를 통해 훈련된다. 수정 후 결과 후보 네트워크는 정확도 네트워크와 훈련 시간 네트워크 모두에 의해 평가된다. 결과는 출력물을 컨트롤러 네트워크로 다시 전달하는 보상 엔진에 의해 결합된다.
원샷 모델.
RL 또는 진화 기반 NAS는 NASNet, mNASNet 및 MobileNetV3 논문에 설명된 최첨단 컴퓨터 비전 결과를 달성하기 위해 수천 GPU-일의 탐색/훈련 시간을 필요로 한다.
계산 비용을 줄이기 위해 많은 최신 NAS 방법은 가중치 공유 아이디어에 의존한다. 이 접근 방식에서는 단일 오버파라미터화된 슈퍼네트워크(원샷 모델이라고도 함)가 정의된다. 슈퍼네트워크는 하위 그래프가 다른 후보 신경망인 매우 큰 유향 비순환 그래프(DAG)이다. 따라서 슈퍼네트워크에서는 가중치가 공통 에지를 갖는 많은 수의 다른 하위 아키텍처들 사이에 공유되며, 각각은 슈퍼넷 내의 경로로 간주된다. 핵심 아이디어는 수천 개의 네트워크를 독립적으로 생성하고 훈련하는 대신 최종 설계를 위한 많은 옵션을 포함하는 하나의 슈퍼네트워크를 훈련하는 것이다. 학습된 매개변수 외에도 한 모듈에 대한 다른 모듈에 대한 선호도를 나타내기 위해 일련의 아키텍처 매개변수가 학습된다. 이러한 방법은 필요한 계산 자원을 몇 GPU-일로 줄여준다.
최근의 연구들은 이 가중치 공유 패러다임을 탐색 공간의 연속적 이완과 결합하여 기울기 기반 최적화 방법을 사용할 수 있게 한다. 이러한 접근 방식은 일반적으로 차등 가능 NAS라고 불리며 신경 아키텍처의 탐색 공간을 탐색하는 데 매우 효율적임이 입증되었다. 기울기 기반 NAS 방법 중 가장 인기 있는 알고리즘 중 하나는 DARTS이다. 그러나 DARTS는 스킵 연결의 피할 수 없는 집적으로 인한 성능 저하와 미래의 많은 알고리즘에 의해 해결된 낮은 일반화 문제에 직면한다.와 같은 방법은 헤시안 노름(Hessian norm) 기반 정규화와 무작위 스무딩/적대적 공격을 각각 도입하여 DARTS를 강화하고 검증 정확도 경관을 더 부드럽게 만드는 것을 목표로 한다. 성능 저하의 원인은 나중에 아키텍처 선택 측면에서 분석되었다.
차등 가능 NAS는 RL 기반 탐색 방법이 필요로 하는 탐색 시간의 일부만을 사용하여 경쟁력 있는 결과를 생성하는 것으로 나타났다. 예를 들어, FBNet(페이스북 버클리 네트워크의 약자)은 슈퍼네트워크 기반 탐색이 ImageNet 이미지 분류 데이터셋에서 mNASNet 및 MobileNetV2의 속도-정확도 트레이드오프 곡선을 능가하는 네트워크를 생성함을 보여주었다. FBNet은 mNASNet에 사용된 탐색 시간보다 400배 이상 적은 탐색 시간을 사용하여 이를 달성한다. 또한 SqueezeNAS는 슈퍼네트워크 기반 NAS가 Cityscapes 시맨틱 세분화 데이터셋에서 MobileNetV3의 속도-정확도 트레이드오프 곡선을 능가하는 신경망을 생성하며, SqueezeNAS는 MobileNetV3 저자들의 RL 기반 탐색에 사용된 시간보다 100배 이상 적은 탐색 시간을 사용한다.
신경망 구조 탐색 벤치마크.
신경망 구조 탐색은 비용이 많이 드는 훈련 및 평가 단계 때문에 종종 많은 계산 자원을 필요로 한다. 이는 이러한 방법의 평가에 필요한 큰 탄소 발자국으로 이어진다. 이러한 한계를 극복하기 위해 NAS 벤치마크가 도입되었으며, 이를 통해 신경망 아키텍처의 최종 성능을 몇 초 만에 질의하거나 예측할 수 있다. NAS 벤치마크는 고정된 훈련-테스트 분할, 탐색 공간 및 고정된 훈련 파이프라인(하이퍼파라미터)을 가진 데이터셋으로 정의된다. NAS 벤치마크에는 크게 두 가지 유형이 있다: 대리 NAS 벤치마크와 표 형식 NAS 벤치마크. 대리 벤치마크는 대리 모델(예: 신경망)을 사용하여 탐색 공간에서 아키텍처의 성능을 예측한다. 반면에 표 형식 벤치마크는 수렴까지 훈련된 아키텍처의 실제 성능을 질의한다. 이 두 벤치마크는 모두 질의 가능하며, 처음부터 아키텍처를 훈련하는 대신 CPU만을 사용하여 벤치마크를 질의함으로써 많은 NAS 알고리즘을 효율적으로 시뮬레이션하는 데 사용할 수 있다.
조사 논문.
생성형 AI 포르노그래피(Generative AI pornography) 또는 AI 포르노그래피(AI pornography)는 생성형 인공지능 (AI) 기술을 통해 디지털 방식으로 제작된 포르노그래피이다. 실제 배우와 카메라를 사용하는 기존의 포르노그래피와 달리, 이 콘텐츠는 AI 알고리즘에 의해 전적으로 합성된다. 생성적 적대 신경망 (GAN) 및 텍스트-이미지 모델을 포함한 이러한 알고리즘은 텍스트 설명이나 데이터 세트에서 실물과 같은 이미지, 비디오 또는 애니메이션을 생성한다.
성 산업에서 생성형 AI의 사용은 2010년대 후반에 시작되었으며, 처음에는 인공지능 예술, 음악 및 시각 콘텐츠에 중점을 두었다. 이러한 추세는 2022년 스태빌리티 AI가 스테이블 디퓨전 (SD)을 출시하면서 가속화되었다. 스테이블 디퓨전은 LAION-5B 데이터 세트의 LAION-Aesthetics 서브셋을 사용하여 텍스트 프롬프트에서 NSFW 콘텐츠를 포함한 이미지를 생성할 수 있는 오픈 소스 텍스트-이미지 모델이다. 스태빌리티 AI가 성적 이미지를 경고했음에도 불구하고, SD의 공개 출시는 예술적 및 노골적인 콘텐츠를 모두 탐구하는 전용 커뮤니티로 이어졌고, 오픈 액세스 AI와 성인 미디어에서의 사용에 대한 윤리적 논쟁을 촉발했다. 2020년까지 AI 도구는 고도로 사실적인 성인 콘텐츠를 생성하는 데 발전했으며, 인공지능 규제 요구를 증폭시켰다.
AI 생성 인플루언서.
인공지능의 응용 기술 중 하나는 OnlyFans 및 인스타그램과 같은 플랫폼에서 AI 생성 인플루언서를 만드는 것이다. 이 AI 페르소나는 실제 인간의 상호 작용을 모방할 수 있는 방식으로 사용자와 상호 작용하여 완전히 합성되지만 설득력 있는 경험을 제공한다. 틈새 시장에서 인기가 있지만, 이러한 버추얼 인플루언서는 특히 성인 엔터테인먼트 분야에서 진정성, 동의, 그리고 인간과 AI 생성 콘텐츠 사이의 경계가 모호해지는 것에 대한 논의를 촉발했다.
AI 포르노 사이트의 성장.
2023년까지 AI 생성 성인 콘텐츠 전용 웹사이트는 맞춤형 경험을 추구하는 사용자들에게 인기를 얻었다. 이러한 플랫폼은 사용자가 자신의 취향에 맞춰 AI 생성 포르노그래피를 만들거나 볼 수 있도록 한다. 이러한 플랫폼은 프롬프트와 태그를 통해 사용자가 신체 유형, 얼굴 특징, 예술 스타일을 맞춤 설정하여 다양한 취향에 맞는 AI 생성 성인 콘텐츠를 만들거나 볼 수 있도록 한다. 태그는 출력을 더욱 정교하게 만들어 틈새 시장과 다양한 콘텐츠를 만든다. 많은 사이트는 광범위한 이미지 라이브러리와 지속적인 콘텐츠 피드를 제공하여 개인화와 발견을 결합하고 사용자 참여를 향상시킨다. 따라서 AI 포르노 사이트는 독특하거나 틈새 시장 경험을 추구하는 사람들을 유치하여 성인 미디어에서 AI의 창의성과 윤리적 경계에 대한 논쟁을 촉발시킨다.
생성형 AI 포르노 "커뮤니티".
civitai.com과 같은 인기 사이트를 통해 사용자는 다양한 포르노 장면이나 효과를 생성하도록 특별히 설계된 SDXL, Flux의 오픈 소스 모델을 미세 조정하여 만들고, 업로드하고, 다운로드할 수 있다.
윤리적 문제 및 오용.
생성형 AI 포르노그래피의 성장은 비판의 원인이 되기도 했다. AI 기술은 리벤지 포르노와 AI 생성 NCII (비동의 성적 이미지)에서 볼 수 있는 것과 유사한 위험을 초래하는 비동의 포르노그래피 자료를 만드는 데 악용될 수 있다. 2023년 분석에 따르면 온라인 딥페이크 비디오의 98%는 포르노그래피이며, 피해자의 99%는 여성인 것으로 나타났다. 딥페이크의 유명인 피해자로는 스칼렛 요한슨, 테일러 스위프트, 메이지 윌리엄스 등이 있다.
오픈AI는 딥페이크 금지를 유지하면서 에로티카와 같은 NSFW 콘텐츠가 연령에 적합한 맥락에서 책임감 있게 생성될 수 있는지 여부를 탐색하고 있다. 이 제안은 오픈AI의 "안전하고 유익한" AI 개발 임무를 훼손한다고 주장하는 아동 안전 운동가들로부터 비판을 받았다. 또한 인터넷 감시 재단은 AI가 아동과 관련된 성적 학대 콘텐츠를 생성하는 데 사용될 수 있다는 우려를 제기했다.
AI 생성 비동의 성적 이미지 (AI Undress).
생성형 AI는 동의하지 않는 개인의 포르노 이미지와 비디오를 제작하는 데 광범위하게 사용되었다. 404 Media는 특정 AI 생성 포르노 봇이 텔레그램에서 월간 사용자 10만 명 이상을 보유하고 있다고 보고했다. 중국 기술 기업 알리바바는 2025년에 Wan 2.1이라는 AI 비디오 생성 모델을 출시했는데, 이 모델은 비동의 포르노를 제작하도록 수정되었다.
일부 미국 주에서는 딥페이크 앱 사용 및 인터넷 공유에 대해 조치를 취하고 있다. 2024년, 샌프란시스코는 주법 위반을 이유로 비동의 AI 누드 이미지를 생성할 수 있는 "언드레스" 앱을 폐쇄하기 위한 획기적인 소송을 제기했다. 이 사건은 캘리포니아주의 최근 입법인 SB 926, SB 942, SB 981과 일치한다. 이 법안은 아이샤 와합 상원의원과 조쉬 베커 상원의원이 주도하고 개빈 뉴섬 주지사가 서명했다. 이 법안들은 비동의 배포를 범죄화하고, 공개를 의무화하며, 피해자들이 유해 콘텐츠를 보고하고 플랫폼에서 제거할 수 있도록 권한을 부여함으로써 AI 생성 노골적인 이미지로부터 개인을 보호하는 것을 목표로 한다.
딥페이크 포르노그래피와의 차이점.
생성형 AI 포르노그래피와 딥페이크 포르노그래피 모두 재현 데이터에 의존하지만, 방법론과 윤리적 고려 사항이 다르다. 딥페이크 포르노그래피는 일반적으로 AI를 사용하여 얼굴을 겹치거나 장면을 수정하는 방식으로 실제 인물의 기존 영상을 종종 동의 없이 변경하는 것을 포함한다. 이와 대조적으로 생성형 AI 포르노그래피는 알고리즘을 사용하여 생성되며, 실제 사람의 사진을 업로드할 필요 없이 초현실적인 콘텐츠를 제작한다. 이미지 분석 전문가인 하니 파리드는 "AI 포르노"와 "딥페이크 포르노"의 차이점을 설명하기도 했다.
생성형 AI 포르노그래피의 합법성은 관할권에 따라 크게 다르며 계속해서 진화하는 문제이다. 일부 국가에서는 디지털 사칭, 음란물 또는 딥페이크 기술을 다루는 법률이 간접적으로 적용될 수 있으며, 특히 AI 생성 콘텐츠가 동의 없이 실제 인물의 초상을 포함하는 경우 더욱 그렇다. 물리적 공연자가 없다는 점은 공연자 보호 및 배포 법률에 근거하는 전통적인 규제 프레임워크를 더욱 복잡하게 만든다.
미국에서는 법적 대응이 주로 비동의 딥페이크 및 사칭에 초점을 맞추고 있다. 버지니아주, 캘리포니아주, 텍사스주와 같은 일부 주에서는 비동의 노골적인 딥페이크 콘텐츠의 제작 또는 배포를 범죄화하는 법안을 제정했다. 그러나 AI 생성 포르노그래피를 다루는 포괄적인 연방 법률은 없으며, 이는 다양한 관할권에 걸쳐 법적 해석과 집행 표준의 혼란을 야기한다.
2023년 보고서에 따르면 대한민국은 전 세계 딥페이크 포르노그래피 생산의 약 53%를 차지한다. 2024년 9월, 대한민국 국회는 성폭력범죄의 처벌 등에 관한 특례법을 개정하여 딥페이크 콘텐츠와 관련된 두 가지 중요한 개혁을 도입했다. 첫 번째는 비동의 딥페이크 자료의 소유, 시청, 구매 및 저장을 범죄화하며, 최대 3년의 징역 또는 최대 3천만 원(약 2만 달러)의 벌금형에 처한다. 두 번째 개혁은 미성년자 착취를 구체적으로 다루며, 딥페이크를 사용하여 미성년자를 위협하거나 블랙메일하는 개인은 최소 3년의 징역형에 처하고, 미성년자를 원치 않는 행위로 강요하는 경우 최소 5년의 징역형에 처한다.
소프트웨어 공학에서 블랙보드 패턴(blackboard pattern)은 크고 다양한 특수 모듈을 통합하고 복잡하고 비결정적인 제어 전략을 구현하는 시스템의 설계 및 구현을 위한 계산 프레임워크를 제공하는 행동 디자인 패턴이다.
이 패턴은 Hearsay-II 프로젝트의 구성원들이 식별했으며 음성 인식에 처음 적용되었다.
블랙보드 모델은 세 가지 주요 구성 요소를 정의한다.
첫 번째 단계는 블랙보드 구조로 이어지는 솔루션 공간(즉, 잠재적 솔루션)을 설계하는 것이다. 그런 다음 지식 소스를 식별한다. 이 두 가지 활동은 밀접하게 관련되어 있다.
다음 단계는 제어 구성 요소를 지정하는 것이다. 이는 일반적으로 실행 가능한 지식 소스의 관련성을 평가하기 위해 도메인별 휴리스틱 세트를 사용하는 복잡한 스케줄러 형태를 취한다.
사용 도메인에는 다음이 포함된다.
블랙보드 패턴은 이기종 모듈을 동적으로 결합하여 문제를 해결해야 하는 복잡한 시스템을 설계하고 구현하는 데 효과적인 솔루션을 제공한다. 이는 다음과 같은 비기능적 속성을 제공한다.
블랙보드 패턴은 여러 프로세스가 별도의 스레드에서 더 가깝게 협력하고 필요할 때 폴링 및 반응할 수 있도록 한다.
널 오브젝트 패턴(null object pattern) 또는 널 객체 패턴에 관한 내용이다.
객체 지향 컴퓨터 프로그래밍에서 널 객체는 참조된 값이 없거나 정의된 중립 (널) 동작을 가진 객체이다. 이러한 객체의 사용법과 동작 (또는 그 부재)을 설명하는 널 객체 디자인 패턴은 "Void Value"로 처음 출판되었고
나중에 Pattern Languages of Program Design 서적 시리즈에서 "Null Object"로 출판되었다.
자바 또는 C#과 같은 대부분의 객체 지향 언어에서 참조는 널일 수 있다. 메서드는 일반적으로 널 참조에 대해 호출될 수 없으므로, 어떤 메서드를 호출하기 전에 이러한 참조가 널이 아닌지 확인해야 한다.
Objective-C 언어는 이 문제에 대해 다른 접근 방식을 취하며 codice_1에 메시지를 보낼 때 아무것도 하지 않는다. 반환 값이 예상되는 경우, 객체에 대해서는 codice_1, 숫자 값에 대해서는 0, codice_3 값에 대해서는 codice_4, 또는 모든 멤버가 codice_5/0/codice_4/0으로 초기화된 구조체 (구조체 타입의 경우)가 반환된다.
객체의 부재 (예를 들어, 존재하지 않는 고객)를 전달하기 위해 널 참조를 사용하는 대신, 예상되는 인터페이스를 구현하지만 메서드 본문이 비어 있는 객체를 사용한다. 널 객체 사용의 주요 목적은 다양한 종류의 조건문을 피하여 코드를 더 집중적이고 읽고 따르기 쉽게 만드는 것이다 즉, 가독성을 향상시키는 것이다.
작동하는 기본 구현보다 이 접근 방식의 한 가지 장점은 널 객체가 매우 예측 가능하고 부작용이 없다는 것이다: 아무것도 하지 않는다.
예를 들어, 함수는 폴더의 파일 목록을 검색하고 각 파일에 대해 어떤 작업을 수행할 수 있다. 빈 폴더의 경우, 응답 중 하나는 예외를 발생시키거나 목록 대신 널 참조를 반환하는 것일 수 있다. 따라서 목록을 기대하는 코드는 계속 진행하기 전에 실제로 목록이 있는지 확인해야 하며, 이는 설계를 복잡하게 만들 수 있다.
대신 널 객체 (즉, 빈 목록)를 반환함으로써 반환 값이 실제로 목록인지 확인할 필요가 없다. 호출 함수는 평소와 같이 목록을 반복하여 효과적으로 아무것도 하지 않을 수 있다. 그러나 반환 값이 널 객체 (빈 목록)인지 확인하고 원하는 경우 다르게 반응할 수도 있다.
널 객체 패턴은 데이터베이스와 같은 특정 기능이 테스트에 사용할 수 없는 경우 테스트를 위한 스텁 역할도 할 수 있다.
이 노드 구조를 가진 이진 트리가 주어졌을 때:
Node left;
Node right;
재귀적으로 트리 크기 절차를 구현할 수 있다:
int treeSize(Node node) {
return 1 + treeSize(node.left) + treeSize(node.right);
자식 노드가 존재하지 않을 수 있으므로, 비존재 또는 널 검사를 추가하여 절차를 수정해야 한다:
int treeSize(node) {
int sum = 1;
if (node.left != null) {
sum += treeSize(node.left);
if (node.right != null) {
sum += treeSize(node.right);
그러나 이는 경계 검사와 일반 로직을 혼합하여 절차를 더 복잡하게 만들고 읽기 어렵게 만든다. 널 객체 패턴을 사용하여 특별한 버전의 절차를 만들 수 있지만 널 노드에 대해서만 가능하다:
if (node == null) {
// 삼항 연산자를 사용하는 경우:
return node != null ? 1 + treeSize(node.left) + treeSize(node.right) : 0;
이는 일반 로직과 특수 사례 처리를 분리하여 코드를 이해하기 쉽게 만든다.
다른 패턴과의 관계.
상태 패턴 및 전략 패턴의 특수 사례로 간주될 수 있다.
이것은 디자인 패턴 (책)의 패턴은 아니지만 마틴 파울러의 Refactoring 및 조슈아 케리에브스키(Joshua Kerievsky)의 Refactoring To Patterns에서 Insert Null Object 리팩토링으로 언급된다.
로버트 C. 마틴의 Agile Software Development: Principles, Patterns and Practices 17장은 이 패턴에 전념한다.
C# 6.0부터 "?." 연산자 (일명 널 조건부 연산자)를 사용할 수 있으며, 이는 왼쪽 피연산자가 널이면 단순히 널로 평가된다.
// compile as Console Application, requires C# 6.0 or higher
namespace ConsoleApplication2
string str = "test";
Console.WriteLine(str?.Length);
// The output will be:
// 4
확장 메서드 및 널 병합.
일부 Microsoft .NET 언어에서는 확장 메서드를 사용하여 '널 병합'이라고 하는 작업을 수행할 수 있다. 이는 확장 메서드가 '인스턴스 메서드 호출'인 것처럼 널 값에 대해 호출될 수 있지만 실제로는 확장 메서드가 정적이기 때문이다. 확장 메서드는 널 값을 확인하도록 만들어질 수 있으므로, 이를 사용하는 코드가 그렇게 할 필요가 없어진다. 아래 예제는 널 병합 연산자를 사용하여 오류 없는 호출을 보장하지만, 더 평범한 if...then...else를 사용할 수도 있다. 다음 예제는 널의 존재를 신경 쓰지 않거나 널과 빈 문자열을 동일하게 취급하는 경우에만 작동한다. 이 가정은 다른 응용 프로그램에서는 적용되지 않을 수 있다.
// compile as Console Application, requires C# 3.0 or higher
namespace MyExtensionWithExample {
public static class StringExtensions {
public static int SafeGetLength(this string valueOrNull) {
return (valueOrNull ?? String.Empty).Length;
public static class Program {
// define some strings
static readonly string[] strings = new[] { "Mr X.", "Katrien Duck", null, "Q" };
// write the total length of all the strings in the array
IEnumerable&lt;int&gt; query = from text in strings select text.SafeGetLength(); // no need to do any checks here
Console.WriteLine(query.Sum());
// 18
다양한 언어에서.
객체에 대한 정적 타입 참조를 가진 언어는 널 객체가 어떻게 더 복잡한 패턴이 되는지를 보여준다:
import std;
virtual ~Animal() = default;
virtual void makeSound() const = 0;
class Dog: public Animal {
virtual void makeSound() const override {
std::println("woof!");
class NullAnimal: public Animal {
여기서 아이디어는 codice_7 객체에 대한 포인터 또는 참조가 필요하지만 적절한 객체가 없는 상황이 있다는 것이다. 표준을 준수하는 C++에서는 널 참조가 불가능하다. 널 codice_8 포인터는 가능하며, 자리 표시자로 유용할 수 있지만 직접 디스패치에는 사용할 수 없다: codice_9가 널 포인터이면 codice_10는 미정의 동작이다.
널 객체 패턴은 codice_7 포인터 또는 참조에 바인딩될 수 있는 특수 codice_12 클래스를 제공함으로써 이 문제를 해결한다.
널 객체를 가져야 하는 각 클래스 계층에 대해 특수 널 클래스를 생성해야 한다. codice_12은 codice_7 계층과 관련이 없는 codice_15 기본 클래스에 대한 널 객체가 필요할 때 쓸모가 없기 때문이다.
"모든 것이 참조"인 언어 (예: Java 및 C#)와 달리 널 클래스가 전혀 없다는 것이 중요한 기능이라는 점에 유의해야 한다. C++에서는 함수 또는 메서드의 설계가 널을 허용하는지 여부를 명시적으로 명시할 수 있다.
// Animal 인스턴스를 요구하며 널을 허용하지 않는 함수.
void doSomething(const Animal&amp; animal) {
// animal은 여기서 절대로 널이 될 수 없다.
// Animal 인스턴스 또는 널을 허용할 수 있는 함수.
void doSomething(const Animal* animal) {
// animal은 널일 수 있다.
C#은 널 객체 패턴을 제대로 구현할 수 있는 언어이다. 이 예시는 소리를 내는 동물 객체와 C# 널 키워드를 대신하여 사용되는 NullAnimal 인스턴스를 보여준다. 널 객체는 일관된 동작을 제공하고, C# 널 키워드를 대신 사용했을 때 발생할 수 있는 런타임 널 참조 예외를 방지한다.
/* Null object pattern implementation:
// Animal interface is the key to compatibility for Animal implementations below.
interface IAnimal
void MakeSound();
// Animal is the base case.
abstract class Animal : IAnimal
// A shared instance that can be used for comparisons
public static readonly IAnimal Null = new NullAnimal();
// The Null Case: this NullAnimal class should be used in place of C# null keyword.
private class NullAnimal : Animal
public override void MakeSound()
// Purposefully provides no behaviour.
public abstract void MakeSound();
// Dog is a real animal.
class Dog : Animal
Console.WriteLine("Woof!");
* Simplistic usage example in a Main entry point.
IAnimal dog = new Dog();
dog.MakeSound(); // outputs "Woof!"
/* Instead of using C# null, use the Animal.Null instance.
* This example is simplistic but conveys the idea that if the Animal.Null instance is used then the program
* will never experience a .NET System.NullReferenceException at runtime, unlike if C# null were used.
IAnimal unknown = Animal.Null; //« replaces: IAnimal unknown = null;
unknown.MakeSound(); // outputs nothing, but does not throw a runtime exception
Smalltalk 원칙에 따라, 모든 것은 객체이며, 객체의 부재는 codice_1이라는 객체로 모델링된다. 예를 들어 GNU Smalltalk에서 codice_1의 클래스는 codice_18이며, codice_19의 직계 후손이다.
목적에 맞는 합리적인 객체를 반환하지 못하는 모든 연산은 대신 codice_1을 반환하여 Smalltalk 설계자들이 지원하지 않는 "객체 없음"이라는 특수 사례를 피한다. 이 방법은 고전적인 "널" 또는 "객체 없음" 또는 "널 참조" 접근 방식보다 단순하다는 장점 (특수 사례가 필요 없음)이 있다. codice_1과 함께 사용하기 특히 유용한 메시지는 codice_22, codice_23 또는 codice_24이며, Smalltalk 프로그램에서 codice_1에 대한 가능한 참조를 처리하는 것을 실용적이고 안전하게 만든다.
Lisp에서 함수는 특수 객체 codice_1을 우아하게 받아들일 수 있어 응용 프로그램 코드에서 특수 사례 테스트의 양을 줄인다. 예를 들어, codice_1은 원자이고 어떤 필드도 없지만, 함수 codice_28 및 codice_29은 codice_1을 받아들이고 그냥 반환하는데, 이는 매우 유용하며 코드를 더 짧게 만든다.
codice_1이 Lisp에서 빈 목록이기 때문에 위 서론에서 설명한 상황은 존재하지 않는다. codice_1을 반환하는 코드는 실제로 빈 목록을 반환하는 것이므로 (목록 타입에 대한 널 참조와 유사한 것이 아님), 호출자는 값이 목록인지 아닌지 테스트할 필요가 없다.
널 객체 패턴은 다중 값 처리에서도 지원된다. 프로그램이 값을 반환하지 않는 식에서 값을 추출하려고 하면, 널 객체 codice_1이 대체된다.
따라서 codice_34는 codice_35 (nil을 포함하는 한 요소 목록)을 반환한다. codice_36 식은 전혀 값을 반환하지 않지만, codice_37 함수 호출이 인자 식을 값으로 줄여야 하므로 널 객체가 자동으로 대체된다.
CLOS.
Common Lisp에서 객체 codice_1은 특수 클래스 codice_5의 유일한 인스턴스이다. 이것은 메서드가 codice_5 클래스에 특화될 수 있으며, 따라서 널 디자인 패턴을 구현한다는 의미이다. 즉, 객체 시스템에 본질적으로 내장되어 있다:
(format t "woof!~%"))
클래스 codice_5은 codice_1이 심볼이기 때문에 codice_43 클래스의 서브클래스이다.
codice_1은 또한 빈 목록을 나타내므로, codice_5은 codice_37 클래스의 서브클래스이기도 하다. codice_43 또는 codice_37에 특화된 메서드 매개변수는 따라서 codice_1 인수를 취할 것이다. 물론, codice_1에 대해 더 구체적인 일치인 codice_5 특화가 여전히 정의될 수 있다.
Common Lisp 및 많은 Lisp 방언과 달리 Scheme 방언은 이런 식으로 작동하는 nil 값을 가지고 있지 않다. codice_28 및 codice_29 함수는 빈 목록에 적용할 수 없다. 따라서 Scheme 응용 프로그램 코드는 codice_54 또는 codice_55 술어 함수를 사용하여 이 상황을 회피해야 한다. 이는 codice_1의 동작 덕분에 빈 경우와 비어 있지 않은 경우를 구별할 필요가 없는 매우 유사한 Lisp 상황에서도 마찬가지이다.
덕 타이핑 언어인 Ruby에서는 예상되는 동작을 제공하기 위해 언어 상속이 필요하지 않다.
def sound
"bark"
class NilAnimal
def sound(*); end
def get_animal(animal=NilAnimal.new)
get_animal(Dog.new).sound
=&gt; "bark"
get_animal.sound
=&gt; nil
명시적 구현을 제공하는 대신 NilClass를 직접 몽키 패치하려는 시도는 이점보다 더 예상치 못한 부작용을 낳는다.
덕 타이핑 언어인 자바스크립트에서는 예상되는 동작을 제공하기 위해 언어 상속이 필요하지 않다.
class Dog {
sound() {
return 'bark';
class NullAnimal {
function getAnimal(type) {
return type === 'dog' ? new Dog() : new NullAnimal();
['dog', null].map((animal) =&gt; getAnimal(animal).sound());
// Returns ["bark", null]
public interface Animal {
void makeSound();
public class Dog implements Animal {
public void makeSound() {
System.out.println("woof!");
public class NullAnimal implements Animal {
// silence...
이 코드는 위 C++ 예제의 변형을 Java 언어를 사용하여 보여준다. C++와 마찬가지로, codice_7 객체에 대한 참조가 필요하지만 적절한 객체가 없는 상황에서 널 클래스를 인스턴스화할 수 있다. 널 codice_7 객체는 가능하지만 (codice_59) 자리 표시자로 유용할 수 있지만 메서드 호출에는 사용할 수 없다. 이 예제에서 codice_60는 NullPointerException을 발생시킨다. 따라서 널 객체를 테스트하기 위해 추가 코드가 필요할 수 있다.
널 객체 패턴은 codice_7 타입의 객체로 인스턴스화될 수 있는 특수 codice_12 클래스를 제공함으로써 이 문제를 해결한다. C++ 및 관련 언어와 마찬가지로, 이 특수 널 클래스는 널 객체가 필요한 각 클래스 계층에 대해 생성되어야 한다. codice_12은 codice_7 인터페이스를 구현하지 않는 널 객체가 필요할 때 쓸모가 없기 때문이다.
interface Animal
public function makeSound();
class Dog implements Animal
public function makeSound()
echo "Woof...\n";
class Cat implements Animal
echo "Meowww...\n";
class NullAnimal implements Animal
$animalType = 'elephant';
function makeAnimalFromAnimalType(string $animalType): Animal
switch ($animalType) {
case 'dog':
return new Dog();
case 'cat':
return new Cat();
return new NullAnimal();
makeAnimalFromAnimalType($animalType)-&gt;makeSound(); // ..the null animal makes no sound
function animalMakeSound(Animal $animal): void
$animal-&gt;makeSound();
foreach ([
makeAnimalFromAnimalType('dog'),
makeAnimalFromAnimalType('NullAnimal'),
makeAnimalFromAnimalType('cat'),
] as $animal) {
// That's also reduce null handling code
animalMakeSound($animal);
다음 널 객체 패턴 구현은 구체적인 클래스가 해당 널 객체를 정적 필드 codice_65로 제공하는 것을 보여준다. 이 접근 방식은 .NET 프레임워크(codice_66, codice_67, codice_68 등)에서 자주 사용된다.
Public Class Animal
Public Shared ReadOnly Empty As Animal = New AnimalEmpty()
Public Overridable Sub MakeSound()
Console.WriteLine("Woof!")
Friend NotInheritable Class AnimalEmpty
Inherits Animal
Public Overrides Sub MakeSound()
이 패턴은 오류/버그가 정상 프로그램 실행처럼 보이게 만들 수 있으므로 신중하게 사용해야 한다.
널 검사를 피하고 코드를 더 읽기 쉽게 만들려는 목적으로만 이 패턴을 구현하지 않도록 주의해야 한다. 왜냐하면 더 읽기 어려운 코드가 다른 곳으로 이동하여 표준이 아닐 수 있기 때문이다. 예를 들어, 제공된 객체가 실제로 널 객체인 경우 다른 로직이 실행되어야 할 때 그렇다. 대부분의 참조 타입을 가진 언어의 일반적인 패턴은 참조를 널 또는 nil이라고 불리는 단일 값과 비교하는 것이다. 또한, 어디에서도 널 객체 대신 널을 할당하지 않는지 테스트해야 할 필요가 있다. 왜냐하면 대부분의 경우, 그리고 정적 타이핑을 가진 언어에서는 널 객체가 참조 타입이라 할지라도 컴파일러 오류가 아니지만, 패턴이 널 검사를 피하는 데 사용된 코드 부분에서는 런타임에 오류를 유발할 것이기 때문이다. 게다가, 대부분의 언어에서, 그리고 많은 널 객체가 있을 수 있다고 가정할 때 (즉, 널 객체가 참조 타입이지만 어떤 방식으로든 싱글턴 패턴을 구현하지 않는 경우), 널 또는 nil 값 대신 널 객체를 확인하는 것은 오버헤드를 발생시키며, 싱글턴 패턴 자체도 싱글턴 참조를 얻을 때 마찬가지이다.
통계학 및 기계 학습에서 확률 변수의 마르코프 블랭킷(Markov blanket) 또는 마코프 블랭킷은 시스템의 다른 모든 변수와 해당 변수를 조건부 독립으로 만드는 변수들의 집합이다. 이 개념은 확률적 그래프 모형 및 특징 선택에서 중요하다. 마르코프 블랭킷이 최소한 — 즉, 이 조건부 독립을 잃지 않고서는 어떤 변수도 제거할 수 없는 — 경우, 이를 마르코프 경계라고 한다. 마르코프 블랭킷 또는 경계를 식별하면 효율적인 통계적 추론이 가능하며 예측 또는 인과 추론을 위한 관련 변수를 분리하는 데 도움이 된다. 마르코프 블랭킷 및 마르코프 경계라는 용어는 1988년 주데아 펄에 의해 만들어졌다. 마르코프 블랭킷은 베이즈 네트워크 또는 마르코프 네트워크와 같은 확률적 그래프 모형의 구조에서 파생될 수 있다.
확률 변수 집합 formula_1에서 확률 변수 formula_2의 마르코프 블랭킷은 formula_3의 부분 집합 formula_4으로, 이에 따라 다른 변수들이 formula_2와 독립이 된다.
이는 formula_4이 formula_2를 추론하는 데 필요한 모든 정보를 적어도 포함하고 있으며, formula_9의 변수들은 중복됨을 의미한다.
일반적으로, 주어진 마르코프 블랭킷은 유일하지 않다. 마르코프 블랭킷을 포함하는 formula_3의 모든 집합 또한 마르코프 블랭킷이다. 특히, formula_3는 formula_3 내 formula_2의 마르코프 블랭킷이다.
베이즈 네트워크에서 노드의 마르코프 블랭킷은 그 부모, 자식, 그리고 자식의 다른 부모(즉, 공동 부모)로 구성된다. 이 노드들의 값을 알면 대상 노드는 네트워크의 나머지 부분과 조건부 독립이 된다. 마르코프 네트워크에서 노드의 마르코프 블랭킷은 단순히 그 즉각적인 이웃이다.
마르코프 조건.
마르코프 블랭킷의 개념은 마르코프 조건에 뿌리를 두고 있는데, 이는 확률적 그래프 모형에서 각 변수가 부모가 주어진다면 비후손 변수들과 조건부 독립이라는 것을 명시한다. 이 조건은 네트워크의 나머지 부분으로부터 변수를 보호하는 최소 분리 집합인 마르코프 블랭킷의 존재를 암시한다.
예를 들어, 사람이 물체를 중력에 대항하여 정지 상태로 유지할 때, 물체의 가속도는 직접적인 원인, 즉 손으로부터의 위쪽 힘과 아래쪽 중력 당김에 의해 완전히 결정된다. 기압이나 온도와 같은 다른 변수들은 인과적으로 무관하다.
마르코프 경계.
formula_3 내 formula_2의 마르코프 경계는 formula_3의 부분 집합 formula_17로, formula_17 자체는 formula_2의 마르코프 블랭킷이지만, formula_17의 어떤 적절한 부분 집합도 formula_2의 마르코프 블랭킷이 아니다. 다시 말해, 마르코프 경계는 최소 마르코프 블랭킷이다.
베이즈 네트워크에서 노드 formula_22의 마르코프 경계는 formula_22의 부모, formula_22의 자식, 그리고 formula_22의 자식들의 다른 부모로 구성된 노드 집합이다. 마르코프 네트워크에서 노드의 마르코프 경계는 그 이웃 노드들의 집합이다. 의존성 네트워크 (그래프 모형)에서 노드의 마르코프 경계는 그 부모들의 집합이다.
마르코프 경계의 유일성.
마르코프 경계는 항상 존재한다. 일부 완만한 조건하에서는 마르코프 경계가 유일하다. 그러나 대부분의 실용적이고 이론적인 시나리오에서는 여러 마르코프 경계가 대안적인 해결책을 제공할 수 있다. 여러 마르코프 경계가 있을 경우, 인과 효과를 측정하는 양들이 실패할 수 있다.