개인 AI에서 가장 어려운 문제는 LLM이 아니다

사람들이 개인 AI 비서 구축의 어려운 부분을 상상할 때, 보통 모델을 떠올립니다. 어떤 LLM을 사용할지, 어떤 프롬프트를 쓸지, 어떤 파인튜닝(fine-tune)을 할지 말입니다. 저희 경험에 따르면, 모델은 가장 쉽게 교체할 수 있는 부분이며 사용자가 가장 적게 알아차리는 부분이기도 합니다. 어려운 문제들은 그 주변 곳곳에 있습니다.

이것은 실제 작업이 숨어있는 장소들을 모아놓은 실용적인 목록입니다. 벤치마크가 아닌, 이 분야에서 구축하며 얻은 의견을 바탕으로 작성되었습니다.

1. 마찰 없이 정보를 수집하는 것 (Getting information in with no friction)

비서는 자신이 얼마나 많은 것을 포착했는지에 따라 그 가치가 결정됩니다. 그리고 사람들은 다른 활동 중간중간에 무언가를 기록합니다. 걸으면서, 채팅 스레드에서, 이메일을 전달하면서 말입니다. 무언가를 저장하는 것이 기억하는 것보다 더 많은 노력을 필요로 한다면, 그것은 일어나지 않습니다.

이는 복잡하고 멀티모달(multimodal) 입력(텍스트, 음성 메모, 전달된 메시지, 웹 페이지)을 지원하고, 사용자에게 양식을 작성하도록 요청하지 않으면서 사용 가능한 형태로 변환하는 것을 의미합니다. 이와 관련하여 사용자 측면은 캡처 인박스 방식에서 다루었습니다.

2. 시간 이해 (Understanding time)

'다음 주 금요일', '2주 후에', '회의 다음 날'. 상대적인 날짜는 모호하며, 사용자의 시간대와 메시지가 전송된 시점에 따라 달라집니다. 하나라도 잘못 해석하면 잘못된 시간에 알림이 오게 되어 신뢰를 빠르게 무너뜨립니다. 저희는 AI 리마인더가 상대적 날짜를 잘못 읽는 이유에서 실패 모드에 대해 작성한 적이 있습니다.

3. 신원 및 개체 (Identity and entities)

'샘'은 지난달의 '샘'과 같은 사람일까요? '치과의사'는 사람일까요, 장소일까요, 아니면 달력 항목일까요? 메모 전반에 걸쳐 참조를 해결하는 것은 프롬프트만으로는 해결할 수 없는 데이터 모델링(data-modelling) 문제입니다. AI가 메모에서 사람, 장소, 날짜를 추출하는 방법을 참고하세요.

4. '관련성'의 의미를 아는 검색 (Retrieval that knows what

의미적 유사성(Semantic similarity)은 필요하지만 충분하지 않습니다. 최신성(recency), 대체(supersession), 그리고 정확한 조회(exact lookups) 또한 필요합니다. 이 점은 개인 메모를 위한 검색 증강 생성(retrieval-augmented generation for personal notes)에서 논의했습니다.

5. 여러 플랫폼에 존재하는 것 (Being present on many surfaces)

사용자들은 채팅 앱, 이메일, 브라우저, 달력 등 다양한 곳에 존재합니다. 여러 플랫폼을 지원한다는 것은 일관된 동작(consistent behaviour), 공유 상태(shared state), 그리고 각 플랫폼마다 다른 제약 조건을 의미합니다. 웹 UI에서 작동하는 기능이 메시징 스레드에서는 불가능할 수 있습니다.

6. 일정 관리 및 후속 조치 (Scheduling and follow-through)

단순히 반응만 하는 비서는 챗봇에 불과합니다. 후속 조치를 취한다는 것은 백그라운드 작업(background jobs), 재시도(retries), 알림 전송(notification delivery), 그리고 무음 시간 존중(respecting quiet hours)을 의미하며, 이는 모두 친근한 인터페이스를 입은 고전적인 분산 시스템 문제(distributed-systems problems)입니다.

7. 신뢰, 개인 정보 보호 및 제어 (Trust, privacy and control)

개인 데이터는 민감합니다. 내보내기(Export), 삭제(deletion), 그리고 명확한 권한 설정(clear permissions)은 법적 각주가 아니라 제품 기능입니다. 연결된 앱 및 AI 권한 검토하기를 참고하세요.

빌더에게 의미하는 바 (What this means for builders)

• LLM을 깨끗한 인터페이스 뒤에 있는 교체 가능한 구성 요소로 취급하십시오.
• 캡처(capture), 시간 파싱(time parsing), 개체 해상도(entity resolution)에 조기에 투자하십시오.
• 검색을 단일 벡터 쿼리(single vector query)가 아닌 파이프라인으로 설계하십시오.
• 첫날부터 여러 플랫폼을 염두에 두고 구축하십시오.
• 똑똑하게 만들기 전에 일정 관리를 신뢰할 수 있게 만드십시오.

이 중 어느 것도 화려하지 않으며, 어떤 것도 리더보드에서 움직이지 않습니다. 하지만 바로 이 지점에서 데모와 일상 사용 제품의 차이가 발생하는 경향이 있습니다.

이것은 Brinn에서 우리가 하고 있는 작업입니다. Brinn은 WhatsApp, 이메일, 웹 및 데스크톱 전반에 걸친 알림, 목록 및 기억을 위한 개인 AI입니다. 만약 여러분도 비슷한 것을 구축하고 있다면, 예상치 못하게 어려웠던 부분은 무엇이었나요?