질문-응답 진행을 구현하기위한 알고리즘 / 템플릿 필요

Structured Matcher 패턴과 그 구현을 사용하여 제안하고 싶습니다.

구조적 매처는 작고 별개의 대안 중에서 선택할 때 유용합니다. 복잡한 결정을 관련 요인에 대한 간단한 결정으로 분해 한 다음 이러한 요인에 대한 결정을 사용하여 결정합니다.

모든 의사 결정 유형을 view (UI 컨트롤, 웹 페이지, 양식 등)로 표시 할 수 있다고 생각합니다. (고객의) 작업 중에이 의사 결정 트리를 작성하려면 의사 결정 트리 (미리 정의)가 있거나 모든 정보를 수집해야합니다. 두 번째 경우 Sponsor-Selector 패턴 (예 :)을 사용하여 이전 결정에 기반한 통계를 사용하여 최상의 결정을 선택할 수 있습니다.

자세한 내용 을 검토하십시오.

전문가 시스템이 필요한 것 같습니다.

내가 이것에 대해 한 일이 있었지만, 당신은 가장 기본적인 질문으로 시작하여 게임 "20 질문"과 매우 흡사합니다.

내가 선호하는 방법은 전자 상거래 사이트와 유사하며 여러 필터를 적용하여 결과를 구체화합니다.

처음에 (단 하나의 질문을하기 전에) 데이터베이스의 모든 솔루션이 적합 할 수 있음을 고려하십시오.

하나의 질문에 대답하면 (답은 "예/아니오"또는 유한 수라고 가정) 솔루션의 목록을 좁 힙니다. 몇 가지 더 대답하고 더 좁히십시오.

시각적으로 두 개의 열로 구성합니다. 하나는 질문 (하나는 질문 당 하나를 선택하는 가능한 대답)과 다른 하나는 가능한 솔루션입니다.

혜택:

• 항상 솔루션을 보여줍니다 (스마트 알고리즘을 가정하면 관련성, 확률 등으로 주문할 수도 있습니다)
• 질문에 대한 선호 순서를 쉽게 결정하고 일부를 건너 뛰고 다시 돌아올 수 있습니다.

비유로 돌아가서 온라인으로 TV를 구매한다고 가정하고 원하는 화면 크기를 선택할 수 있습니다. 이 모델에서 질문은 "원하는 화면 크기는 얼마입니까"이고 다양한 크기는 답변이됩니다.

다른 접근 방식은 Windows의 문제 해결사와 비슷합니다. 제안이나 질문을 한 다음 이것이 도움이되었는지 여부를 나타낼 수 있습니다. 이에 따르면 문제 해결 담당자가 다음 질문을하거나 다른 수정 사항을 제안합니다.

단점은 일반적으로 반환 할 수없는 단계를 건너 뛰면 프로세스의 현재 위치 (얼마나 많은 질문이 있는지)를 알 수 없다는 것입니다. 결과 (가능한 솔루션)는 하나씩 제안됩니다.

제목에 언급하면 ​​UI와 알고리즘에 대한 이중 질문입니다.

귀하의 도움말 운영자도 지식이 거의 없기 때문에 매우 간단한 UI가 필요하다고 생각합니다. 한 번에 하나의 질문으로 마법사 을 제공하는 것이 가장 간단합니다. 각 단계는 다른 질문을 제거합니다. 마지막 단계는 더 이상 질문이 없을 때 가능한 솔루션 목록입니다.

두 번째 부분은 알고리즘이기 때문에 약간의 주제입니다. 기본적으로 각 단계에서 가장 다른 질문을 제거 할 수있는 질문을해야합니다. 실제로 가장 좋은 질문은 나머지 질문의 절반을 제거하는 질문입니다. 대답이 '예'이면 절반이 제거되고 대답이 '아니오'이면 나머지 절반이 제거됩니다. 이것은 결정 트리 모델 에서 영감을 얻었습니다.