페이지온도토론

SFReaders 사이트에 대해 페이지온도에 대해 google의 PageRank 개념을 빌려 실험해봤습니다.

노스모크의 각 페이지에 일정량의 에너지가 있다고 보고 그 에너지가 링크를 통해 흘러나갑니다. A 란 페이지에 B와 C로의 링크가 있다면 A의 에너지의 절반은 B로, 또 절반은 C로 흘러갑니다. 다시 B의 에너지는 B와 연결된 페이지로 흘러가고요. 이런 식으로 흐르다보면 어떤 페이지는 많은 에너지를 가지고, 어느 페이지는 적은 에너지를 가지게 됩니다. 나중에 가서 많은 에너지를 가지는 페이지가 중요한 페이지가 되는 셈이죠.

1. 이 모델을 썼을 때: 분류분류 페이지로 에너지가 모이더군요. 분류패턴을 따라 흐른 에너지가 결국엔 분류분류 페이지에 고이게 되네요. 노스모크도 크게 다르지 않을 듯..
   
   
2. 반대로 링크가 아닌 역링크를 통해 에너지가 흐르도록 한 경우: 뜨거운 페이지들에 관한 링크를 많이 가지고 있다면 이 페이지도 뜨겁다고 봐야겠죠? 이런 식으로 했더니 FrontPage로 흐릅니다. MoinMoin도 뜨거워지고요. 이들에 관한 Link를 가진 SystemPages도 온도가 올라갑니다. 주로 MoinMoin을 처음 설치할 때에 따라오는 페이지(WikiSeed)들의 온도가 높았습니다.
   
   
3. 이 두 모델을 함께 쓸 경우: 휴고상페이지가 가장 뜨거웠습니다. 하지만 SystemPages 쪽의 온도도 높아 실용성은 없습니다. 첫번째 경우에 대한 가중치를 높일 경우에는 비교적 쓸만했습니다.
   
   
4. A의 이웃 페이지 B와 C에 무조건 1/2씩 보내지 않고 분모에 일정 값(5를 택했습니다.)을 더해 1/7씩 흐르게 했습니다. 5/7의 에너지는 낭비되는 셈이죠. 링크가 많은 페이지라면 이런 낭비도 줄어들겠죠? 분류분류처럼 고정적인 링크로 흐르는 에너지가 줄어 꽤 유용한 결과가 나오네요.
   
   
5. 몇몇 중요하다고 생각되는 페이지(예컨데 FrontPage)의 온도를 일부러 높였습니다. (무조건 100을 더한다거나 하는 식으로.) 예상과는 달리 전체엔 결과엔 큰 영향을 미치지 못했습니다.
   
   
6. 어느 경우나 고아 페이지는 썰렁했습니다.
   
   

물론 RecentChanges를 중심으로 이슈가 형성되는 위키위키에 어울리는 모델은 아니지만, 정적인 에너지가 어디가 제일 높은지 계산해보는 것도 사이트의 특성을 파악하는데 도움이 될 듯 싶습니다.

이런 식으로 계산을 하면 페이지의 구조적 특징이 잘 나타나겠군요. 모든 페이지맵에 대해서 어떤 특정한 의미에서의 터미널포인트가 어디인지 생각해 볼 수 있을 거 같습니다. 그렇지만 페이지온도와는 별 상관이 없어보입니다. 이것은 페이지의 온도가 이미 결정된 상태에서 사이트의 구조가 어디로 집중되어있는지를 나타낼 뿐입니다. 페이지온도가 정해지면, 이런 실험을 통해서 사이트의 구조를 조정하는데 유용해 보입니다. --naya

문서들간의 링크정보를 이용해 점수주기 계산을 하게 되면, 당연히 링크를 많이 받은 녀석의 점수가 올라갑니다. 분류이름 페이지들이 여러 곳에서 링크를 받기 때문에, 점수가 올라가는 것이 당연합니다. 이러한 링크를 분석하는 것은 "권위 있는/인기 높은 페이지"를 찾아내는 것이죠.

그런데 위의 계산을 하실 때, 어떤 방식으로 계산을 하신 것인지 궁금하네요. 아마도 링크정보를 모두 추출하고, 각 페이지에 기본값을 준 후에, 매 링크마다 페이지온도를 계산하면서 iterative하게 계산하셨을 걸로 추측되는데 말입니다. DeadLink 같은 것을 잘못 셈하게 되면, iteration을 할수록 전체 페이지온도가 떨어지는 현상이 나타날 겁니다.

구글의 PageRank는 모든 웹페이지를 동일한 것으로 간주하고, 다시 말해 웹페이지를 웹사이트 대문페이지와 개별페이지와 같은 식으로 구분하는 것 없이 분석합니다. 그러나 실제로 더 정확히 분석할 때에는 페이지들의 덩어리, 특히 웹사이트와 웹사이트의 페이지들에 대해 특별한 처리가 필요합니다. 이러한 방식으로 하이퍼링크를 분석하는 것이 Kleinberg에 의해 처음 제안되었고, 구글의 PageRank는 성능을 위해 이것을 훨씬 단순화시켜서 구현한 것입니다.

참고로, 구글이 문서를 잘 찾아주는 것은 PageRank보다는 AnchorText라는 녀석 때문입니다(그런데도 구글은 PageRank가 가장 중요한 요소인 것처럼 fake를 쓰고 있습니다. 특허를 출원한 것이 PageRank이기 때문에 마케팅용으로 써먹기 위해서일 수도 있고, 경쟁업체들을 혼란스럽게 해서 쉽게 따라하지 못하게 장난치는 것일 수도...). AnchorText라는 것은 특정 단어, 주제와 해당 페이지의 연관관계를 확실히 알게 해주는 가장 중요한 요소입니다. 특정 페이지를 향한 하이퍼링크를 만들어 내면서, 링크에 적는 텍스트가 AnchorText입니다. 위키위키의 경우에는 이 AnchorText와 링크받은 페이지의 제목이 완전히 일치하기 때문에, AnchorText로 더 효과를 볼 거리가 없습니다. --Aragorn

페이지온도를 열역학적으로 정의하고자 한다면 먼저 기본 개념들을 물리학적으로 정의를 해야할 것이다. 페이지온도가 중요한 것이 아니라 페이지온도 상승한다는 것과 낮아진다는 것이 어떤 노스모크에서 어떤 의미를 갖는지부터 확실해 해야한다. 그러면 페이지온도는 자연스럽게 정의된다. 페이지온도가 상승한다고 하는 것은 그 페이지의 진화가 일어나기 위한 포텐셜에너지가 크다거나, 실제로 운동에너지를 통해서 진화가 일어나고 있는 것을, 페이지온도가 하강한다고 하는 것은 그 페이지가 진화의 과정에서 도태되고 있으며, 내부적으로 진화의 가능성이 줄어드는 것이라고 가정하면, 다음과 같이 페이지온도를 계산해볼 수 있다. (물론 페이지온도가 상승한다는 것과 하강한다는 것이 의미하는 바를 다르게 정의할 수도 있다고 생각한다.)

노스모크 페이지의 에너지 : (페이지간에 작용하는 포텐셜 에너지 + 페이지의 운동에너지)

잠정적으로 '페이지의비열'은 모두 같다고 가정한다.

페이지의 포텐셜에너지 : 페이지를 읽은 사람의 수*C2 + 페이지의 링크의 수*링크의 Hit Number * C3 for all links--> 페이지가 진화하는 잠재적 에너지가 된다.
페이지의 운동에너지 : 수정된 내용의 질과 양 / 한번의 수정 * C4 for all corrections --> 페이지가 진화하는 직접적인 에너지가 된다.

이렇게 되면 노스모크의 각각의 페이지는 하나의 System의 Particle로 고려된 것이며, 노스모크라는 System은 3000개가 넘는 Particle로 결합된 것이다. 이번에는 노스모크를 그 System이라고 생각하면,

노스모크 : Thermal System with interaction.

노스모크의온도 : 노스모크의 페이지들의 온도의 평균온도 --> 항상 그 상태의 평균적인 상태가 Equilibrium상태라고 가정..실제로 Equilibrium이 되려먼 각 페이지들의 에너지에 대한 확률 분포가 Boltzman's Distribution을 따를 것이다. 즉, 어떤 에너지구간의 페이지의 수의 분포는 exp(-B*E)에 비례하는 값이 되어야한다.
노스모크의페이지의 전체에너지 : 노스모크의 모든 페이지들의 에너지의 총합

State : 노스모크의 State는

1. 노스모크의 회원수
   
2. 노스모크의 페이지수
   
3. 노스모크의 회비
   
4. 노스모크의 시스템의 상태
   

실제로 노스모크라는 시스템을 위와 같은 방법으로 모델링해서 테스트를 하기 위해서는 어떤 페이지의 에너지를 측정하려면, 각 페이지에서 그 페이지로 향하는 모든 링크를 조사하고 그 링크들의 Hit Number를 관찰하고, 그 페이지로 바로 들어가는 (Go를 통해서.,.) 횟수를 조사하면 된다. 이런 걸 하려면, 프로그램을 조금 수정해서 링크들이 클릭될때 counting해서 각각의 페이지에 Data를 기록해주던지, 아니면, 간단한 데이타베이스를 만들어서 온도를 측정하고, 이 시스템이 Equilibrium에 이르렀는지도 계산해보고, 언제 어떻게 Equilibrium에 이르게 될지도 계산해보고, 모든 state에 대해서 하나하나 확인해볼 수 있을 것이다. 그런데 지금 중요한 것은 각각의 state들을 어떻게 나눌 것인가 하는 것이다. state들이 많으면 많을 수록 partition function을 계산하는데 어려움을 겪게 될 것이다.

MarshallMcLuhan은 미디어가 가지는 정보의 양으로 "뜨거운 미디어"와 "차가운 미디어"를 구분하였다. 정보의 양이 많으면 "뜨거운 미디어"이고 그 반대는 반대. 아마도 각각의 페이지에 대해서도 같은 적용을 할 수 있지 않을까?

세리자와가 보기에는 약간 문제가 있어 보이다. 온도는 다음과 같이 정의되는데,

T = 1/(dS/dE)

• T: 온도
  
• E: 에너지
  
• S: 엔트로피
  
  

엔트로피=정보 이므로 단위 에너지당 정보 전송량이 많을 수록 온도가 낮다. 즉, McLuhan의 정의와는 반대가 되는 셈이다.

위키페이지에는 다음과 같이 적용할 수 있다.

무엇보다 변경되는 글자 수가 에너지 입출입에 대략 선형적으로 비례한다고 할 수 있다. 그러면 변경되는 글자 수와 실제 텍스트에 추가되거나 삭제되는 정보의 양에 비율에 따라 온도가 결정된다.

1. 토론페이지에서 텍스트가 계속 추가 되지만, 다양한 내용은 별로 없고 중언부언한다면 이것은 온도가 높은 뜨거운 페이지에 해당한다. 이 경우 Refactoring을 하면 대량의 텍스트가 없어지지만, 소실되는 정보는 역시 별로 없다.
   
2. Refactoring == CoolingDown! Refactoring이 어느 정도 진행되면 그 때부터는 조금만 텍스트를 지워도 정보가 상당히 손실되는 지점에 다다른다. 이 때가 페이지의 온도가 낮아지는 상태이다.
   
3. 페이지의 온도가 낮아져도 또 중언부언 하면 온도가 높아지지만, 알짜정보만을 추가하면 페이지 온도를 낮게 유지할 수 있다. 그러므로 Don't heat'em! Keep'em cool, guys!
   
   

나를잊어줘가 학창 시절에 일반게시판 검색 엔진을 만든 적이 있다. 게시판 URL과 HTML 구조 데이터를 입력하면, 에이전트가 주기적으로 방문하여 제목, 작성자, 작성날짜, 본문, 조회수 등을 추출하였다. 제목과 본문에 대한 검색을 지원하였고, 문서 클러스터링 과정을 거쳐 키워드 기반 검색 및 브라우징 기능을 제공하였다. 그리고, 게시물에 대한 인기도를 계산하여 인기도 순으로 보여주는 기능도 있었다. 인기도는 최근의 게시물 중에서 조회수가 높을수록 인기도가 높은 값을 갖도록 의도되었다. 그런데, 인기도는 단순히 조회수만 가지고 쓸 수가 없었다. 왜냐하면, 최근의 게시물보다 과거의 게시물이 아무래도 조회수가 높기 마련이어서 조회수로 정렬을 하게 되면 과거의 글이 항상 앞쪽에 나오기 때문이었다. 그래서, 시간에 따라 인기도가 감소하도록 하기 위해 반감기를 도입하였다. 예를 들면 이런 것이다. 우선 반감기를 얼마로 할 것인지 정한다. 일단 5라고 정했다 치자. 여기서 5의 의미는 5일이 지나면, 게시물의 인기도가 반으로 떨어진다는 뜻이다. 현재 어떤 게시물의 조회수가 100이다. 그러면, 게시물의 인기도는 100에서 시작한다. 만약, 조회수가 더 이상 증가하지 않으면 5일 후에 이 게시물의 인기도는 반으로 떨어져서 50이 된다. 중간에 조회수가 증가하면 다시 그 조회수를 인기도로 간주한다. 반감기를 통해서 과거의 글들에 대한 인기도를 낮추고, 최근의 글들에 대한 인기도를 높이는 효과를 거둘 수 있었다.

페이지온도 함수에 시간 t를 포함시키는 건 어떨까해서 써 봤습니다. --나를잊어줘

토론과 같은 뜨거운페이지의 온도를 낮추기 위해서 며칠을 두고본 후에 답변을 다는 여유를 가진다. 생각도 정리되고 덜 감정적인 답변을 달 수 있고, SignalToNoiseRatio를 높일 수 있을 것이다. -- 아무개

See also 페이지온도 뜨거운페이지

위키위키분류 토론분류