검색하기

키워드 매칭이 아니라 의미와 연결로 찾는다. `@`귀속, 인과·시간 질문, 결과 읽는 법.

AiAkiv 검색은 키워드 매칭이 아니라 의미 + 연결 검색이다. 잘 쓰면 키워드로는 불가능한 질문에 답한다.

기본: 그냥 자연어로 물어본다

ak 전투 시스템 설계가 어떻게 바뀌었어?

검색은 기본이 hybrid(이벤트 + 엔티티, 의미 기반)라서 단어가 안 겹쳐도 찾는다. 결과 각각에는:

  • reason: 왜 이게 걸렸는지(유사 임베딩 / 공유 엔티티 / 순차 연결 등)
  • 연결 지도(hint): 결과들이 어떤 스레드·엔티티·주제로 엮이는지

결과를 목록 그대로만 훑지 말고 reason과 연결 지도를 같이 읽어라. "최신/관련"을 물을 땐 유사 임베딩 표시가 이름이 바뀐 동의어를 가리키는 경우가 많다. 따라가면 더 나온다.

요약이 부족하면 원문을 가져온다

검색은 이벤트 요약을 준다. 요약은 LLM 생성물이라 드물게 부정확할 수 있다. 정확한 내용이 필요하면 원문 조회로 이벤트 원문을 가져온다.

@로 작성자·팀을 좁힌다

누가 쓴 기억인지는 서버가 저장 시점에 자동으로 찍는다(위조 불가). 검색 쿼리 맨 앞의 @handle이 귀속 필터다.

  • @[email protected]: 그 사용자의 이벤트를 최신순으로 브라우즈
  • @[email protected] 세이브 버그: 그 사용자 범위 안에서 검색
  • @팀이름 ... 팀 귀속 콘텐츠로 필터

AiAkiv에 붙는 앱이 남긴 기록만 보려면 맨 앞에 #앱이름을 붙인다. 앱은 아직 준비 중이라 지금 쓸 수 있는 이름은 없고, 앱이 나오면 그 이름이 여기에 더해진다(예: 계획 앱이 나오면 #plan). 기호 없이 물으면 평소대로 일반 검색이다.

일반 태그는 @로 시작할 수 없어서, "누가 썼는가"는 클라이언트나 AI가 위조할 수 없다.

키워드가 못 하는 질문: AiAkiv의 자리

이런 질문이 AiAkiv가 빛나는 곳이다. 키워드가 구조적으로 실패하기 때문이다.

  • 인과·시간 도약: "이 버그의 원인이 된 과거 결정은?" 버그 이벤트에서 원인 링크·시간축을 거슬러 과거 결정으로. (저장할 때 원인을 이어둔 게 여기서 살아난다 → 저장하기.)
  • 공유 엔티티 연결: "인벤토리와 세이브가 왜 같이 바뀌었어?" 두 사건이 공유하는 엔티티로.
  • 변화 이력: "밸런스 조정 히스토리 보여줘". 같은 주제의 사건들을 시간축 위에 나열.

가장 최근 것을 여는 열린 질문도 좋다: "가장 최근 버그랑 그 원인이 뭐야?" 특정 버그를 전제하지 않아도, 그래프가 최근 사건과 그 인과를 물어온다.

관계로 묻기: ak 그래프

"이 이름이 나오는 기억 중에서만", "이 태그 안에서만"처럼 찾을 범위를 먼저 정해 두고 묻고 싶을 때는 앞에 ak 그래프를 붙인다. AI가 질문을 그래프 질의로 옮겨 실행한다.

ak 그래프 세이브 포맷이 나오는 기억 중에서 로드 버그를 고친 기록
ak 그래프 balance 태그가 붙은 기억 중에서 적 체력을 바꾼 것
ak 그래프 인벤토리와 세이브 포맷이 모두 나오는 기억
  • 첫째는 "세이브 포맷"이 나오는 기억 안에서, 문장과 뜻이 가까운 순으로 고른다.
  • 둘째는 같은 일을 태그 안에서 한다.
  • 셋째는 두 이름이 한 기억에 같이 나오는 것을 모은다.

이름과 태그는 저장된 표기 그대로 맞춰 찾는다. 표기가 헷갈리면 AI가 먼저 확인한다.

AI는 답과 함께 실행한 질의와 그 뜻을 한 줄로 보여 준다. 무엇을 찾았는지 눈으로 확인할 수 있게 하려는 것이다.

실행한 질의: START a = events(entity: "세이브 포맷", text: $q, k: 20) RETURN a, a.score ORDER BY a.score DESC, a.id (뜻: "세이브 포맷"이 나오는 기억 중 "로드 버그를 고친 기록"과 뜻이 가까운 20건)
  • ak 그래프만 보내면 AI가 따라 쓸 수 있는 예문 셋을 보여 준다.
  • ak 그래프 없이 물어도 연결에 관한 질문이면 AI가 스스로 그래프 질의를 쓸 수 있다. ak 그래프는 그래프 질의를 바로 부르는 방법이다.
  • "확인 못 함"과 "없음"은 다르다. 결과가 0건인데 AI가 "범위를 다 살펴보지 못했다"고 하면, 없다는 뜻이 아니라 이번에 확인하지 못했다는 뜻이다. 범위를 끝까지 살펴보고 0건이면 그때가 "없음"이다.
  • 서버에 따라 이 기능이 꺼져 있을 수 있다. 그때 AI는 가능한 방법으로 대신 찾고, 꺼져 있다는 사실을 알려 준다.

문법 전체·응답 읽는 법·한계는 관계로 묻기에 모았다.

검색 범위는 서버가 정한다

검색 범위(도메인·태그)는 서버가 접근 정책으로 결정한다. 클라이언트가 쿼리로 좁히거나 넓힐 수 없다. 응답의 searched_scope가 실제 적용된 범위를 알려준다. "내 팀에서 내가 읽을 수 있는 것"이 상한이다. 특정 도메인만 보고 싶으면 결과를 거르지, 쿼리에 도메인 필터를 넣지 않는다(그러면 데이터가 조용히 빠질 수 있다).

다음