Grokipedia는 텍스트 정보를 LLM이 연산하는 수단인 K-V, 즉 벡터화 시킨 것을 저장해서 공개했다는 것이 중요한 Contribution인것 같습니다.
이 연산 부분이 실제로 모든 LLM에서 매번 이루어지는 작업이며, Context Length에 무시못할 부분을 차자히는게 맞고 연산량에 큰 Bottle neck이 되는것도 맞아서 “연산 속도” 또는 “재연산의 불필요성”의 측면에서 좋은 효율을 가져와줄 수 있어보이네요.
Grok이 검색을 더 잘하는 이유는 Browser를 더 적극적으로 활용하도록 설계된 것이 이유입니다. 실제로 Gemini는 Deep Research를 켜지 않는 이상 Browsing을 그렇게까지 활용하지 않더군요.
하지만 Google은 이미 이미지, 장표, 영상 등의 이해에서 좋은 성능을 보인다는 것을 증명했습니다. 이는 우리가 아무 이미지나 넣어도 잘 해석하는 Gemini를 보면 알 수 있어보입니다. 또 Youtube에서 이미 여러 실시간 번역, Summarize등의 기능을 확인할 수 있기 때문에 Google이 못해서 안하는 것은 아닌것 같습니다.
어디까지나 이건 개발의 방향성 차이같습니다.
구글은 기능은 있지만 수익성과 실용성을 위해 그런 기능을 활용하지 않는 것이고, Grok은 또 다른 전략을 택한다고 보는게 맞다고 볼 수 있습니다.
때문에 Grokipedia가 Grok이 검색을 더 잘할 것이다 그래서 Gemini를 이길 수 있다로 이어지는 점은 불분명해 보입니다.
검색을 하는 것으로만 한정하여 Task를 쪼개어 보자면 아마 3가지 단계가 필요할 것 같습니다.
1. 사용자의 의도가 무엇인지 = 검색을 어떤 단어로 할 것인지
2. 검색된 결과를 어떻게 해석할 것인지
3. 검색된 결과를 어떻게 User에게 보여줄 것인지
기술적 관점에서 Grokipedia는 1번 단계에서 검색을 하고 나온 Text정보를 Vector화 하는 부분을 미리 해둔(Prefill) 서비스입니다.
이것은 결국 1번 단계 “수행 시간을 단축”하는 기능입니다. 그리고 결국 “Text정보를 Vector화”하는 것은 아마도 Grok의 성능이 upper bound이겠죠.
나머지 2번 3번도 매우 중요한 과제이기 때문에 이 부분을 어떻게 처리하느냐에 따라달렸습니다.
grok이 앞으로 Grokipedia에서 자신의 검색을 수행한다면 수익성, 효율성 측면에선 좋아질 수 있습니다만 이게 검색시장에서 결국 승자가 되기엔 Kick이 없습니다.
정보는 매번 새로 생겨나니까요. 그리고 결국 Grok은 또 다시 Google에 가야합니다.
Grokipedia는 텍스트 정보를 LLM이 연산하는 수단인 K-V, 즉 벡터화 시킨 것을 저장해서 공개했다는 것이 중요한 Contribution인것 같습니다.
이 연산 부분이 실제로 모든 LLM에서 매번 이루어지는 작업이며, Context Length에 무시못할 부분을 차자히는게 맞고 연산량에 큰 Bottle neck이 되는것도 맞아서 “연산 속도” 또는 “재연산의 불필요성”의 측면에서 좋은 효율을 가져와줄 수 있어보이네요.
Grok이 검색을 더 잘하는 이유는 Browser를 더 적극적으로 활용하도록 설계된 것이 이유입니다. 실제로 Gemini는 Deep Research를 켜지 않는 이상 Browsing을 그렇게까지 활용하지 않더군요.
하지만 Google은 이미 이미지, 장표, 영상 등의 이해에서 좋은 성능을 보인다는 것을 증명했습니다. 이는 우리가 아무 이미지나 넣어도 잘 해석하는 Gemini를 보면 알 수 있어보입니다. 또 Youtube에서 이미 여러 실시간 번역, Summarize등의 기능을 확인할 수 있기 때문에 Google이 못해서 안하는 것은 아닌것 같습니다.
어디까지나 이건 개발의 방향성 차이같습니다.
구글은 기능은 있지만 수익성과 실용성을 위해 그런 기능을 활용하지 않는 것이고, Grok은 또 다른 전략을 택한다고 보는게 맞다고 볼 수 있습니다.
때문에 Grokipedia가 Grok이 검색을 더 잘할 것이다 그래서 Gemini를 이길 수 있다로 이어지는 점은 불분명해 보입니다.
검색을 하는 것으로만 한정하여 Task를 쪼개어 보자면 아마 3가지 단계가 필요할 것 같습니다.
1. 사용자의 의도가 무엇인지 = 검색을 어떤 단어로 할 것인지
2. 검색된 결과를 어떻게 해석할 것인지
3. 검색된 결과를 어떻게 User에게 보여줄 것인지
기술적 관점에서 Grokipedia는 1번 단계에서 검색을 하고 나온 Text정보를 Vector화 하는 부분을 미리 해둔(Prefill) 서비스입니다.
이것은 결국 1번 단계 “수행 시간을 단축”하는 기능입니다. 그리고 결국 “Text정보를 Vector화”하는 것은 아마도 Grok의 성능이 upper bound이겠죠.
나머지 2번 3번도 매우 중요한 과제이기 때문에 이 부분을 어떻게 처리하느냐에 따라달렸습니다.
grok이 앞으로 Grokipedia에서 자신의 검색을 수행한다면 수익성, 효율성 측면에선 좋아질 수 있습니다만 이게 검색시장에서 결국 승자가 되기엔 Kick이 없습니다.
정보는 매번 새로 생겨나니까요. 그리고 결국 Grok은 또 다시 Google에 가야합니다.
물론 이렇게 노하우를 쌓으며 앞지를 방법을 모색할 수도 있구요 :)
그래도 이런걸 서비스화 한것은 개인 개발자입장에선 반가운 소식일 수 있겠네요 ㅎㅎ