추천 토픽이 토픽 제목과 내용을 고려한다면 정말 훌륭한 기능이 될 것 같습니다. 예를 들어, '애널리틱스’에 대한 토픽을 읽는 중이라면, 유사한 내용을 포함하는 토픽을 현재 추천 결과에 섞어 보여주는 식입니다.
이것이 효율적으로 구현된다면, 신규 방문자와 활성 사용자 모두의 참여도를 높이는 확실한 성과로 이어질 것이라고 확신합니다. 내용까지 고려하지 않고 제목만 사용하더라도 마찬가지입니다.
6개의 좋아요
효율적으로 구축하기에는 매우 복잡한 기능이며, 그 깊이는 끝이 없습니다. 어느 시점부터는 기계 학습(ML)을 고려하게 되고, 그 깊이는 점점 더 깊어집니다.
관련 콘텐츠를 결정하는 데 AI를 활용하는 방식의 매력은 잘 이해합니다. 이는 거의 '셀프 서비스(self-service)'로 만들 수 있는 Support 주제에서 매우 유용할 수 있습니다. 질문을 게시하면 ML이 10개의 후보를 골라 답변으로 게시하고, 사용자는 이를 수락하거나 삭제할 수 있습니다. 마찬가지로 익명 사용자가 지원(support) 항목을 찾을 때 관련 콘텐츠를 표시하는 것도 유용합니다.
그러나… 이는 거대하고 방대한 작업입니다. 내년 로드맵에는 포함되어 있지 않습니다. 다만 @eviltrout은 언젠가 AI/ML로 실험해 보고 싶어 하며, 이 프로젝트는 그러한 실험과 관련이 있을 수 있는 유형입니다.
@codinghorror는 여전히 DJ random의 열렬한 팬입니다. 그는 DJ random이 수많은 복잡한 알고리즘보다 뛰어난 성능을 낼 수 있다고 믿기 때문이죠(실제로 그런 경우가 많습니다).
7개의 좋아요
DJ 랜덤은 정말 훌륭하지만, 시간과 카테고리/태그를 기준으로 제한을 두고 있어요. 그 부분이 중요하거든요.
3개의 좋아요
안녕하세요,
여기 새로 온 사람이라, 같은 이야기를 반복하고 있다면 죄송합니다.
@sam 님이 말씀하신 대로 깊은 구렁이가 있다는 데 동의하지만, 한편으로 토픽 모델링 기술은 이미 꽤 성숙했고, 좋은 오프더셸(Off-the-shelf) 도구들도 많이 존재합니다. 최근 진행한 프로젝트에서 약 500만 건의 특허 제목과 초록을 분석했으며, 제 멋진 새 디스커스 사이트에서 약 1,000개 규모의 토픽을 분석하는 것은 식은 죽 먹기일 것입니다. 게다가 우리 커뮤니티에는 이를 실현할 충분한 에너지가 있을 수도 있습니다.
전문가분들께 여쭙고 싶은 것이 있습니다. 플러그인을 설계하는 방향으로 생각하는 것이 좋을까요, 아니면 디스커스 소스 코드(깃허브에서 다운로드한 것)를 직접 수정하는 방향으로 생각하는 것이 좋을까요?
파이썬으로 디스커스 토픽을 스크래핑하는 방법에 대해 이 글을 찾았지만, 아직 제대로 동작하도록 만들지 못했습니다. 이와 유사한 방법으로 데이터를 오프라인으로 가져와 모델을 구축한 뒤, 나중에 쿼리하도록 로드할 수 있을 것입니다.
참고로, 좋은 도구 대부분은 파이썬으로 되어 있습니다…
4개의 좋아요
기능적으로는 새 주제를 작성할 때 “당신의 주제는 …과 유사합니다” 패널에 가장 잘 맞습니다.
1개의 좋아요
여기서는 소스 코드를 해킹하는 것보다 플러그인을 사용하는 것을 확실히 권장합니다. 이 기능을 코어에 포함시킬 가능성은 매우 낮습니다. 그 이유는 막대한 Python 의존성이 필요하고, 학습 등을 위한 방대한 UI가 요구되기 때문입니다.
학습 메커니즘 등 관련 작업이 매우 많습니다. 학습을 수행할 메커니즘에 대한 개요를 설명해 주실 수 있나요? 구체적으로 어떤 모델을 사용하는 것을 권장하시나요? 특정 토픽에 게시글이 100개, 1000개 있을 때 어떻게 처리하시나요?
시그널로 무엇을 사용하시며, 각 항목(조회수/카테고리/태그 등)에 어떤 강도를 부여하시나요?
이 프로젝트에 매우 큰 관심을 가지고 있지만, 상당히 방대한 작업이라고 느껴집니다.
3개의 좋아요
학습 메커니즘 등에 많은 작업이 필요합니다. 학습을 수행할 메커니즘에 대해 설명해 주시겠습니까? 어떤 모델을 사용하는 것을 권장하시나요?
현재 제 팀이 사용하는 도구는 gensim에서 나옵니다. 표준 python 모듈 인터페이스를 갖추고 있습니다. 수년 동안 충분히 테스트되어 왔습니다.
제가 떠올리는 설정은 다음과 같습니다:
- 먼저: 문서 집합 선택: 모든 주제 루트일 수도 있고, 모든 게시글일 수도 있습니다.
가끔씩(예: 주 1회? 월 1회? 포럼 트래픽에 따라), doc2vec 모델을 빌드합니다:
- discourse 주제를 md 텍스트 파일(또는 파일들)로 스크래핑하여, 제목+주제 본문을 추출합니다. 이제 각 주제를 gensim 알고리즘용 문서, 즉 "document"로 생각합니다.
- 표준 NLP 도구를 사용하여 문서를 처리하고, 단어 스테밍 등을 수행합니다.
doc2vec(gensim 구현)을 사용하여 각 문서를 d차원 공간의 벡터로 매핑하는 모델을 빌드합니다. 메타 파라미터 d는 실험을 통해 선택해야 합니다. Google은 특허 모델에 d=40을 사용합니다. Google Scholar에서 어떤 d를 사용하는지는 정확히 모르겠습니다. 저는 보통 d=200을 사용합니다. 공간의 각 차원은 의미적 내용과 관련된 "기능(feature)"으로 생각할 수 있습니다.- (참고: doc2vec 알고리즘은 단어 시퀀스를 학습하도록 설계된 신경망을 훈련시켜 기능 공간을 구축합니다. 신경망에는 d차원의 은닉층이 있으며, 은닉층의 출력은 잠재적 기능 공간을 형성합니다)
- 모델 빌딩은 문서 수에 따라 무거운 작업입니다. 38년치 특허 = 500만 개의 문서; doc2vec 모델은 8코어 구형 머신에서 하룻밤이 걸립니다.
- 선택적인 흥미로운 추가 작업: d차원 기능 공간의 문서 클라우드를 클러스터링합니다.
- 클러스터링을 위한 시중 도구, 예를 들어 python sklearn 라이브러리에서 사용할 수 있습니다.
- 클러스터링은 *신흥 분류(emergent classification)*를 제공합니다. 흥미로운 연구 질문에는 이러한 분류가 키워드(또는 discourse 태그) 카테고리와 어떻게 겹치는지가 포함됩니다.
이것은 오프라인에서 수행됩니다. 그런 다음 온라인에서:
- 모델이 로드됩니다.
- 모델이 로드되면, 새로운 문서를 파싱하고 d차원 기능 공간에서의 위치를 모델에 쿼리하는 것은 상대적으로 가벼운 작업입니다.
- 이 새로운 문서는 모델 재빌딩을 트리거하지 않는다는 점에 유의하세요. 온라인 쿼리에 대해 모델은 정적(static)입니다. 새로운 문서는 다음(예: 주간) 모델 빌드 시점에 통합됩니다.
- 그 후 마지막 가벼운 작업은 기능 공간에서 가까운 문서가 무엇인지 묻는 것입니다. 가까운 문서 목록을 가져오는 gensim 도구가 있지만, numpy를 직접 사용하여 모든 문서 벡터를 kd-tree와 같은 구조에 로드하여 가까운 점에 대한 빠른 쿼리를 직접 수행할 수도 있습니다.
주제가 100개의 게시글을 가질 때? 1000개의 게시글을 가질 때 어떻게 되나요?
오프라인 부분은 문서 수에 따라 대략 선형적으로 확장되지만, 1만~10만 개의 문서라면 매우 관리 가능해야 합니다. 100만 개의 문서도 주간 배치 처리에는 괜찮습니다.
신호(signal)로 무엇을 사용하시겠습니까? 그리고 각 항목(조회수/카테고리/태그 등)에 어떤 강도를 부여하시겠습니까?
이 컨텍스트에서 새 주제에 대한 '신호 강도’는 새 주제의 벡터 공간 임베딩에서 기존 문서 벡터까지의 (역)거리로 직접 해석됩니다. 이 신호를 다른 고려 사항(좋아요, 조회수 등)으로 장식할 수 있지만, 이들은 제가 설명하는 기본 알고리즘에 대한 추가적인 장식품에 불과합니다.
저(또는 누군가)가 스크래핑을 작동시키는 데 성공하면, 위에서 설명한 오프라인 부분은 꽤 쉽고 기계적입니다.
어려운 부분(제게는)은 온라인 부분으로, discourse rails와 소수의 python 호출(예: gensim 도구로) 간의 인터페이스가 필요합니다. 이러한 종류의 인터페이스에 대한 예제가 있다면 참고하는 데 도움이 될 것입니다.
6개의 좋아요
@Bcat : '자신의 것으로 교체’하신 부분이 어떻게 구현되었는지 궁금합니다. 확인해볼 수 있는 플러그인이나 저장소가 있으신가요?
여기서 까다로운 성능 관련 부분은 RPC 메커니즘입니다. 모든 주제(topic) 뷰마다 완전히 새로운 Python 프로세스를 시작하는 것은 원치 않을 것입니다.
HTTP 호출조차도 너무 느릴 수 있습니다.
아마도 … related_topics (topic_id, related_topic_id, rank) 테이블을 채우는 것은 어떨까요? 그러면 사람들이 새로운 주제를 게시할 때 WebHooks를 통해 테이블이 빠르게 업데이트되도록 하고, Ruby가 Python을 호출할 필요가 없게 됩니다.
Discourse 측 구현은 꽤 쉬울 것입니다. 단순히 이 메서드를 재작성하여 새로운 related_topics 테이블에서 정보를 조회하도록 하면 됩니다.
2개의 좋아요
기존 방식이 작동하지 않아 구글 광고로 교체했습니다. 구글이 제안하는 주제들은 매우 똑똑합니다.
기존 방식에 대해서는 기본 제안을 끄고, /search를 호출한 후 주제 목록을 반환하는 JS 스니펫으로 대체했습니다.
2개의 좋아요
테이블 구현에 대한 조언을 주셔서 감사합니다. 다만 테이블 방식이 확장성에 문제가 있을 것 같습니다. N개의 주제에 대해 크기가 $N^2$인 테이블이 필요하므로, 10^4개의 주제가 있다면 테이블에는 10^8개의 항목이 들어가게 됩니다.
새 주제를 파싱하고 임베딩을 생성한 뒤 가장 가까운 이웃을 찾는 과정을 위해 Python 호출을 피할 방법이 보이지 않습니다. 과거에는 웹 인터페이스를 구축한 적이 있지만, 이번에는 Python 프로세스를 별도로 실행하고 소켓이나 파이프를 통해 Discourse와 통신하는 방식이 더 끌릴 것 같습니다. 이는 실제 Python 호출보다는 파일을 읽고 쓰는 것에 가깝게 동작할 것입니다. (어쨌든 모든 것이 제 서버에서 실행되니까요…)
죄송하지만 제가 완전히 오해하고 있는 건 아닌지 모르겠습니다?
토픽이 100개 있고 각 토픽에 관련 토픽 5개가 표시된다면, 테이블 크기가 500보다 클 필요가 왜 있나요?
1개의 좋아요
N개의 주제 => 벡터 공간 표현에서 N개의 점.
각 점 사이의 거리를 나타내는 행렬은 N^2입니다. (행렬은 대칭이므로 독립적인 값은 N*(N-1)/2개입니다.) 여기서 제가 언급한 N^2이 바로 이것입니다.
하지만 기발한 자료 구조(예: kd-tree)를 사용하면 N^2 크기의 차이를 계산하는 브루트 포스 탐색 없이도 가장 가까운 이웃을 찾을 수 있습니다.
어쨌든, 저는 파이썬으로 이 모든 작업을 수행하는 방법을 알고 있으며, 귀하가 언급한 작은 테이블, 즉 5개의 가장 가까운 주제에 대한 N x 5 테이블을 반환할 수 있습니다.
1개의 좋아요
그런 다음, 파이썬으로 이를 매일 실행하면 파이썬을 Discourse DB에 직접 연결하여 이 캐시 테이블을 생성할 수 있습니다.
그런 다음, Discourse 플러그인 부분은 다소 자명합니다. 위치 X에서 선택하는 대신 위치 Y(다른 테이블)에서 선택하게 됩니다.
더 이상 단일 요청을 위해 두 프로그래밍 언어를 오가야 하는 파이프라인과 씨름할 필요가 없습니다.
여기서 제안된 AI 접근 방식은 흥미롭고 이상적인 해결책이 될 수 있을 것 같습니다.
더 기술적이지 않은 접근 방식도 검토할 가치가 있지 않을까 생각합니다. ‘추천 주제(Suggested Topics)’ 섹션에 “주제 추천” 버튼을 포함하는 것입니다. 이 버튼을 클릭하면 사용자가 사이트 내 다른 주제에 대한 링크를 게시하고, 두 주제가 왜 관련이 있는지에 대한 간단한 설명을 남길 수 있습니다.
적절한 목업은 아니지만, 우리가 같은 이해를 하고 있는지 확인하기 위해, 다음과 같은 것을 의미합니다:
참고로, 저는 특정 주제에서 표현된 관점을 지지하고 반박하는 두 가지 유형의 주제 추천에 관심이 있습니다. 예를 들어, 누군가 기후 변화가 큰 문제가 아니라고 주장하는 주제를 만들 경우, 사이트 사용자들이 그 논리를 반박하거나 지지하는 관련 주제를 추천할 수 있기를 바랍니다.
이는 덜 논쟁적인 주제에도 유용할 수 있습니다. 여기에서 주제에 답글을 달 때 저는 관련 주제가 있는지 확인하기 위해 사이트의 검색 기능을 자주 활용합니다. 사용자가 관련 주제를 추천할 수 있도록 허용하면 그 노력이 보존될 수 있습니다. 예를 들어, 이 주제를 읽으면서 Discourse의 최근 AI 활용에 대해 생각하게 되었습니다: Discourse Disorder. 제 생각에, 해당 주제가 이 주제의 추천 주제 목록에 나타나고, Discourse가 포럼과 AI를 통합하는 방법을 검토하고 있다는 언급이 포함된 노트가 함께 표시되는 것이 관련성이 있을 것 같습니다.
3개의 좋아요
업데이트: 이제 Discourse AI 플러그인에 구현되었습니다 
5개의 좋아요