Pi, 이제 Jev 지원함.

내 걱정은 Jev의 실용성과 Pi의 방향성에 관한 거야. Jev가 일상적인 코딩 워크플로우에 추가적인 복잡함을 감수할 만큼의 이점을 주는지 아직 확신이 안 서. 신뢰성, 비용, 지연 시간 측면에서 의미 있는 개선이 있는지, 그리고 그게 실전에서 얼마나 일관되게 유지되는지 궁금해.

내가 Pi에서 좋아하는 점 중 하나는 핵심 기능은 작게 유지하고, 취향을 타는 워크플로우는 확장 프로그램으로 남겨두는 거였어. 공유 분류기 API를 추가하는 게 에이전트에 특정 워크플로우를 박아넣는 것과는 다르다는 건 알지만, 분류기를 일급 모델 타입으로 만드는 건 결국 공유 추상화에 발을 들이는 거라, 그 결정이 너무 이른 건 아닌가 싶어.

현재 인터페이스도 지금의 Jev 작동 방식에 너무 가깝게 모델링된 것 같아. 그게 좋은 일반 설계가 될 수도 있겠지만, 다양한 구현과 사용 사례를 거치며 어떤 부분이 잘 일반화되는지 알 만큼 충분한 경험이 쌓였을까? 분류기 자체가 새로운 건 아니지만, 이 특정 인터페이스가 성숙해질 시간이 충분했는지가 문제야.

Jev가 실제로 어디에 도움이 되는지, 그리고 더 넓은 분류기 API가 어떤 모습이어야 할지 배우기 위해서라도 확장 프로그램을 통해 먼저 탐색했으면 좋았을 텐데. 이 단계에서 굳이 핵심 모델 계층에 넣어야 했던 특별한 이유가 있었을까?

동의함. 이제 누군가 Pi를 포크해서 미니멀리즘 접근 방식으로 유지보수할 때가 된 것 같다.

이제 Pi 비대화 제거 가이드가 필요함. 이런 거 다 필요 없다고.

솔직히 Jev가 어떻게 작동하는지, 왜 추가 구독료를 내야 하는지 아직 잘 모르겠어. 지금 워크플로우에 만족해서 굳이 찾아볼 생각도 안 들고.

구독료 낼 필요 전혀 없음. 그 모델들은 감자(저사양 PC)에서도 돌아갈 정도로 가벼워. 이미 널린 게 많음, https://github.com/wfzyx/von, https://github.com/NandhaKishorM/laya 등

LLM은 생성형 AI고, Jev는 텍스트를 입력받아 제로샷으로 처리하는 단순 분류기야(그래서 클래스를 위해 재학습할 필요가 없음). 게다가 반환되는 확률값도 보정되어 있어(X 클래스가 정답일 확률이 얼마인지). LLM은 그런 식으로 확률이 보정되어 있지 않거든.