솔루션을 평가하고 버그를 찾는 데 Markov 체인을 사용하는 방법. Python 스크립트 사용

교육 중에 학생들에게 무슨 일이 일어나고 이러한 이벤트가 결과에 어떤 영향을 미치는지 이해하는 것이 중요하므로 고객 경험 지도인 고객 여정 지도를 구축합니다. 결국 학습 과정은 지속적이고 통합적인 것이 아니라 학생의 상호 연결된 일련의 사건과 행동이며 이러한 행동은 학생마다 크게 다를 수 있습니다. 이제 그는 수업을 마쳤습니다. 다음에 무엇을 하게 될까요? 숙제하러 갈까? 모바일 애플리케이션이 출시되나요? 그는 진로를 바꾸고 교사를 바꿔달라고 요청할 것입니까? 다음 강의로 바로 가실 건가요? 아니면 실망해서 그냥 떠날까요? 이 지도를 분석하여 과정을 성공적으로 이수하거나 반대로 학생의 "중퇴"로 이어지는 패턴을 식별하는 것이 가능합니까?

일반적으로 CJM을 구축하는 데는 전문적이고 매우 비싼 비공개 소스 도구가 사용됩니다. 그러나 우리는 최소한의 노력을 필요로 하는 간단하고 가능하다면 오픈 소스를 만들고 싶었습니다. 그래서 Markov 체인을 사용하자는 아이디어가 떠올랐고 우리는 성공했습니다. 우리는 지도를 구축하고, 학생 행동에 대한 데이터를 그래프 형태로 해석했으며, 글로벌 비즈니스 문제에 대한 완전히 불투명한 답변을 확인했으며, 심지어 깊이 숨겨진 버그까지 발견했습니다. 우리는 오픈 소스 Python 스크립트 솔루션을 사용하여 이 모든 작업을 수행했습니다. 이 기사에서는 매우 명확하지 않은 결과가 나온 두 가지 사례에 대해 이야기하고 모든 사람과 스크립트를 공유할 것입니다.

따라서 Markov 체인은 이벤트 간의 전환 확률을 보여줍니다. 다음은 Wikipedia의 기본 예입니다.

여기서 "E"와 "A"는 이벤트이고 화살표는 이벤트 사이의 전환(이벤트에서 동일한 이벤트로의 전환 포함)이며 화살표의 가중치는 전환 확률(“가중 방향 그래프”)입니다.

무엇을 사용하셨나요?

회로는 학생 활동 로그가 제공되는 표준 Python 기능으로 교육되었습니다. 결과 행렬의 그래프는 NetworkX 라이브러리에 의해 구성되었습니다.

로그는 다음과 같습니다.

이는 학생 ID, 이벤트 이름, 이벤트 발생 시간 등 세 개의 열로 구성된 테이블을 포함하는 csv 파일입니다. 이 세 가지 필드는 클라이언트의 움직임을 추적하고 지도를 구축하고 궁극적으로 Markov 체인을 얻는 데 충분합니다.

라이브러리는 생성된 그래프를 .dot 또는 .gexf 형식으로 반환합니다. 전자를 시각화하려면 무료 Graphviz 패키지(gvedit 도구)를 사용할 수 있습니다. 우리는 .gexf 및 Gephi도 무료로 작업했습니다.

다음으로 Markov 체인을 사용하는 두 가지 예를 제시하고 이를 통해 우리의 목표, 교육 프로세스 및 Skyeng 생태계 자체를 새롭게 살펴볼 수 있습니다. 글쎄, 버그를 수정하세요.

첫 번째 사례: 모바일 애플리케이션

우선 가장 인기 있는 제품인 일반 과정을 통해 학생의 여정을 살펴보았습니다. 그 당시 저는 스카이엥 아동부에서 일하고 있었는데, 우리는 모바일 애플리케이션이 우리 아이들의 청중에게 얼마나 효과적으로 작동하는지 확인하고 싶었습니다.

로그를 가져와 스크립트를 통해 실행하면 다음과 같은 결과가 나타납니다.

시작 노드는 Start General이고, 하단에는 학생이 "잠들었다", 코스 변경, 코스 완료라는 XNUMX개의 출력 노드가 있습니다.

• 잠들다, "잠들다" - 이것은 그가 더 이상 수업을 듣지 않는다는 것을 의미하며, 아마도 떨어졌을 가능성이 높습니다. 우리는 낙관적으로 이 상태를 "잠자기"라고 부릅니다. 왜냐하면... 이론적으로 그는 여전히 공부를 계속할 기회가 있습니다. 우리에게는 최악의 결과입니다.
• 일반을 삭제하고 코스를 변경했습니다. 일반에서 다른 것으로 전환하고 Markov 체인에서 길을 잃었습니다.
• 과정 완료, 과정 완료 - 이상적인 조건, 개인이 수업의 80%를 완료했습니다(모든 수업이 필요한 것은 아닙니다).

성공적인 수업 노드에 참여한다는 것은 교사와 함께 우리 플랫폼에서 수업을 성공적으로 완료한다는 것을 의미합니다. 코스 진행 상황과 원하는 결과("코스 완료")에 대한 접근 방식을 기록합니다. 학생들이 가능한 한 많이 참석하는 것이 우리에게 중요합니다.

모바일 애플리케이션(앱 세션 노드)에 대한 보다 정확한 정량적 결론을 얻기 위해 각 최종 노드에 대해 별도의 체인을 구축한 다음 에지 가중치를 쌍으로 비교했습니다.

• 앱 세션에서 다시 앱 세션으로
• 앱 세션부터 성공적인 수업까지;
• 성공적인 수업부터 앱 세션까지.

왼쪽은 과정을 마친 학생들, 오른쪽은 '잠든' 학생들

이 세 가지 가장자리는 학생의 성공과 모바일 앱 사용 간의 관계를 보여줍니다. 우리는 과정을 이수한 학생들이 잠들었던 학생들보다 지원서에 더 강한 연관성을 가질 것으로 기대했습니다. 그러나 실제로 우리는 정반대의 결과를 얻었습니다.

• 우리는 다양한 사용자 그룹이 모바일 애플리케이션과 다르게 상호 작용하도록 했습니다.
• 성공적인 학생들은 모바일 애플리케이션을 덜 집중적으로 사용합니다.
• 잠들어 있는 학생들은 모바일 앱을 더 적극적으로 사용합니다.

이는 잠든 학생들이 모바일 애플리케이션에서 점점 더 많은 시간을 보내기 시작하고 결국에는 영원히 모바일 애플리케이션에 남아 있다는 것을 의미합니다.

처음에는 놀랐지만, 곰곰이 생각해 보니 이는 지극히 자연스러운 효과였다. 한때 저는 모바일 애플리케이션과 YouTube 문법 강의라는 두 가지 도구를 사용하여 혼자서 프랑스어를 공부했습니다. 처음에는 시간을 50 대 50의 비율로 나눴습니다. 하지만 응용 프로그램이 더 재미 있고 게임화가 있으며 모든 것이 간단하고 빠르고 명확하지만 강의에서는 그것에 대해 탐구하고 무언가를 적어야합니다. , 노트북으로 연습하세요. 점차적으로 저는 스마트폰 점유율이 100%가 될 때까지 더 많은 시간을 스마트폰에 사용하기 시작했습니다. 스마트폰에 XNUMX시간을 소비하면 작업이 완료되었다는 잘못된 느낌을 갖게 되어 가서 아무것도 듣고 싶지 않게 됩니다. .

그런데 어떻게 이런 일이 있을 수 있습니까? 결국 우리는 특별히 모바일 애플리케이션을 만들었습니다. 그 안에 에빙하우스 곡선이 세워졌습니다., 게임화하여 사람들이 시간을 보낼 수 있도록 매력적으로 만들었습니다. 그러나 그것이 사람들의 주의를 산만하게 할 뿐이라는 것이 밝혀졌습니다. 사실 그 이유는 모바일 애플리케이션 팀이 업무를 너무 잘 처리했기 때문에 그 결과 멋지고 자급자족 가능한 제품이 되어 우리 생태계에서 벗어나기 시작했기 때문입니다.

연구 결과, 주요 학습 과정에 방해가 되지 않도록 모바일 애플리케이션을 어떻게든 변경해야 한다는 것이 분명해졌습니다. 그리고 어린이와 성인 모두. 이 작업은 현재 진행 중입니다.

두 번째 사례: 버그 온보딩

온보딩은 신규 학생 등록 ​​시 선택적 추가 절차로, 향후 잠재적인 기술적 문제를 제거합니다. 기본 시나리오에서는 랜딩 페이지에 등록한 사람이 자신의 개인 계정에 액세스한 후 연락을 받고 입문 레슨을 받는 것으로 가정합니다. 동시에 우리는 입문 수업에서 기술적 어려움의 상당 부분을 지적합니다. 잘못된 버전의 브라우저, 마이크 또는 사운드가 작동하지 않고 교사가 즉시 해결책을 제안할 수 없으며 이 모든 것이 특히 어려울 때입니다. 아이들에게. 따라서 우리는 귀하의 개인 계정에 추가 애플리케이션을 개발했습니다. 여기서는 브라우저, 카메라, 마이크를 확인하고 입문 수업 중에 부모님이 근처에 있는지 확인하는 네 가지 간단한 단계를 완료할 수 있습니다. 자녀 교육).

다음 몇 가지 온보딩 페이지에는 다음과 같은 깔때기가 표시되어 있습니다.

1: 세 가지 약간 다른(클라이언트에 따라) 로그인 및 비밀번호 입력 양식으로 시작 블록.
2: 추가 온보딩 절차에 동의하는 확인란입니다.
2.1-2.3: 부모 존재 여부, Chrome 버전 및 사운드를 확인합니다.
3: 최종 블록.

매우 자연스러워 보입니다. 처음 두 단계에서 대부분의 방문자는 작성하고 확인할 것이 있다는 것을 깨닫고 떠나지만 시간이 없습니다. 고객이 세 번째 단계에 도달했다면 거의 확실하게 마지막 단계에 도달할 것입니다. 깔대기에서 아무것도 의심할 이유가 하나도 없습니다.

그럼에도 불구하고 우리는 전통적인 XNUMX차원 퍼널이 아닌 마르코프 체인을 사용하여 온보딩을 분석하기로 결정했습니다. 좀 더 많은 이벤트를 켜고 스크립트를 실행한 결과 다음과 같은 결과가 나왔습니다.

이 혼란 속에서 명확하게 이해할 수 있는 것은 무엇인가 잘못되었다는 것입니다. 온보딩 프로세스는 선형적이며 이는 설계에 내재되어 있으므로 연결망이 있어서는 안 됩니다. 그리고 여기에서 사용자가 단계 사이에 던져져 있고 그 사이에는 전환이 전혀 없어야 한다는 것이 즉시 분명해집니다.

이 이상한 그림에는 두 가지 이유가 있을 수 있습니다.

• 떼가 로그 데이터베이스에 들어갔습니다.
• 제품 자체에 오류가 있습니다. - 온보딩.

첫 번째 이유는 사실일 가능성이 높지만 이를 테스트하는 것은 상당히 노동 집약적이며 로그를 수정해도 UX 개선에 도움이 되지 않습니다. 그러나 두 번째 경우가 있다면 긴급하게 조치를 취해야 했습니다. 그래서 우리는 노드를 살펴보고, 존재해서는 안 되는 엣지를 식별하고, 발생 원인을 찾아보았습니다. 우리는 일부 사용자가 멈춰서 원을 그리며 걷고, 다른 사용자는 중간에서 처음으로 떨어지고, 다른 사용자는 원칙적으로 처음 두 단계에서 벗어날 수 없음을 확인했습니다. 우리는 데이터를 QA로 옮겼습니다. 그리고 예, 온보딩에 버그가 많다는 것이 밝혀졌습니다. 이것은 일종의 부산물이고 약간의 버팀목이며 충분히 깊이 테스트되지 않았습니다. 왜냐하면... 우리는 어떤 문제도 예상하지 못했습니다. 이제 전체 녹음 과정이 변경되었습니다.

이 이야기는 QA 분야에서 마르코프 체인의 예상치 못한 적용을 보여주었습니다.

직접 해보십시오!

나는 내 것을 게시했다 Markov 체인 훈련을 위한 Python 스크립트 공개 도메인에서 - 건강을 위해 사용하십시오. GitHub에 대한 문서, 여기에서 질문을 할 수 있습니다. 모든 것에 답변해 드리겠습니다.

음, 유용한 링크: NetworkX 라이브러리, Graphviz 시각화 장치. 그리고 여기 Habré에 대한 기사가 있습니다. 마르코프 체인에 대해 기사의 그래프는 다음을 사용하여 만들어졌습니다. 지피.

출처 : habr.com