https://preview.redd.it/47cb5u96tn9h1.png?width=3024&format=png&auto=webp&s=b1cee93477970b8b0a636c37be657fecd38ba968
https://preview.redd.it/t45iv1a6tn9h1.png?width=3018&format=png&auto=webp&s=beef94ac59848eb1d61fbf9ac25c3d201201d47a

"로컬 AI 어시스턴트"라고 하면 보통 "API를 감싼 래퍼 (wrapper)"를 의미하곤 하기에, 이 커뮤니티에서 (당연하게도) 이를 지적할 것을 고려하여 엔지니어링 과정을 공유합니다.

문제점: 배터리를 방전시키거나 실제로 하고 있는 작업의 GPU를 가로채지 않으면서, 노트북에서 편안하게 실행되는 모델만을 사용하여 원시 화면 캡처(screen capture)와 회의 녹취록(meeting transcripts)을 쿼리 가능한(queryable) 형태로 변환하는 것입니다.

결과적으로 효과를 본 방법:

• OCR은 LLM의 역할이 아닙니다. Apple의 Vision 프레임워크가 온디바이스 OCR을 수행하며, LLM은 픽셀을 읽느라 토큰을 낭비하지 않습니다. 속도와 정확도 측면 모두에서 큰 이점입니다.
• 증류 (Distillation)는 유휴 상태(idle)에서 배치(batch) 단위로 실행됩니다. 4B급 모델 (Gemma)이 기기가 바쁘지 않을 때 캡처 내용을 프로젝트별 노트로 요약합니다. 무거운 작업은 여유 시간에 처리되므로 포그라운드(foreground) 작업은 빠릿하게 유지됩니다.
• 검색 (Retrieval)은 순수 벡터 방식이 아닌 하이브리드 방식입니다. 정확한/어휘적 검색을 위한 SQLite FTS와 의미론적 검색을 위한 LanceDB를 결합했습니다. 순수 벡터 검색은 정확한 식별자(티켓 번호, 에러 문자열 등)를 계속 놓쳤고, FTS만으로는 의역된 표현을 놓쳤습니다. 둘을 함께 사용하니 견고해졌습니다.
• 컨텍스트(context)가 타이트하다면 작은 모델도 괜찮습니다. 비결은 더 큰 모델을 쓰는 것이 아니라, 작은 모델에게 작고 관련성 높으며 잘 검색된 조각(slice)을 제공하는 것입니다. 제가 겪은 "로컬 모델이 멍청하다"는 실패 사례의 대부분은 검색 실패가 모델의 문제인 것처럼 위장한 것이었습니다.

솔직한 한계점: 현재는 macOS + Apple Silicon 환경에 최적화되어 있습니다 (ScreenCaptureKit과 Neural Engine에 크게 의존함). Intel 환경에서도 작동하지만 OCR과 추론(inference) 속도가 눈에 띄게 느립니다. 화자가 겹치는 음성에 대한 화자 분리(Diarization) 품질은 여전히 별로입니다.

전체 프로젝트는 AGPL 라이선스입니다. 이곳의 다른 분들이 유휴 상태 스케줄링(on-idle scheduling)과 FTS+벡터 융합 가중치(FTS+vector fusion weighting)를 어떻게 처리하고 있는지 궁금합니다. 깔끔한 게시물을 위해 링크는 댓글에 남기겠습니다.

코드: https://github.com/off-grid-ai/desktop. 소스에서 빌드하세요. 누군가 의견을 나누고 싶다면 스케줄러 내부 구현이나 검색 융합(retrieval fusion)에 대해 기꺼이 자세히 설명해 드리겠습니다.

제출자: /u/alichherawalla
[링크] [댓글]