구조화된 인덱스: AI 에이전트가 문서의 '수량'에 어떻게 답변하는지
구조화된 인덱스는 에이전트가 문서에 이미 포함된 필드(제목, 가격, 레벨, 링크, 이미지)와 의미 기반 검색을 위해 사용하는 벡터 검색을 함께 활용하여 구축한 작은 테이블입니다. 벡터 검색은 질문과 유사하게 읽히는 구문을 찾아내지만, 카운팅하거나 숫자로 필터링하거나 그룹화할 수는 없습니다. 구조화된 인덱스는 이러한 작업을 처리하며, 에이전트가 단편에서 재구성하는 대신 링크나 식별자를 정확하게 인용할 수 있게 합니다.
"몇 개 있나요?"라고 묻으면 에이전트는 우연히 검색된 네 개의 구절에서 답합니다. 링크를 요청하면 실제 링크를 건네줄 수도 있지만, 다른 항목에 속한 링크일 수 있습니다. 링크는 열리고, 이미지가 렌더링되며, 아무런 오류도 발생하지 않습니다. 이것이 어떻게 일어나는지, 그리고 어떻게 막을 수 있는지 설명합니다.
각 문서에는 고유한 색상이 있습니다. 왼쪽 — 오늘 작동하는 방식의 검색 — 에서는 답변의 제목은 한 문서에서, 링크는 다른 문서에서 가져오며, 색상 불일치가 즉시 드러납니다. 오른쪽에서는 검색된 각 조각이 자체 문서의 사실을 함께 전달하며, 링크가 링크가 아닙니다: 모델이 주소는 보지 못한 채 복사한 자리 표시자입니다. 실제 값은 출력 과정에서 대체되므로, 섞일 여지가 없습니다.
검색은 구절을 찾지만 컬렉션을 보지 못합니다
벡터 검색은 유사도에 기반합니다: 질문은 공간 내의 방향이 되며, 가장 가까운 구절이 반환됩니다. 이는 "이것이 X에 대해 무엇을 말하는가"에는 정확히 맞지만, "몇 개 있는가", "200자 미만의 것은 무엇인가", "카테고리별 개수는 얼마인가"에는 구조적으로 무용지물입니다. — 이러한 질문은 전체 컬렉션에 관한 것이며, 검색은 항상 가장 가까운 몇 개만 살펴봅니다.
이러한 문제를 튜닝으로 해결할 수 없습니다. 유사도 검색이 총계를 반환하게 만드는 임계값은 존재하지 않습니다. 총계란 구절이 아니기 때문입니다.
두 번째, 더 조용한 실패: 청크는 문서가 아닙니다
긴 문서는 검색이 올바른 단락을 찾을 수 있도록 청크로 분할됩니다. 그러나 제목, 제품 코드, 링크, 이미지는 헤더에 있으므로, 이는 청크 1에 존재함을 의미합니다. 실제로 질문에 답한 구절은 청크 7일 수 있습니다.
따라서 모델은 세 개 또는 네 개의 서로 다른 문서에서 온 네 개 또는 다섯 개의 조각을 들고 있으며, 어떤 링크가 어떤 제목에 속하는지 파악해야 합니다. 모델은 추측합니다. 그리고 추측이 틀리면 답변이 잘못되어 보이지 않습니다: 링크는 실제이며, 열리고, 이미지가 렌더링됩니다 — 단지 다른 항목에 속할 뿐입니다. 오류가 발생하지 않습니다. 아무도 알아차리지 못합니다.
4,500개 문서로 구성된 카탈로그에서 테스트 답변 20개 중 11개가 제목을 다른 문서의 링크와 짝지었습니다. 위의 자리 표시자 메커니즘을 사용하면 동일한 20개 답변이 20개 모두 정확했습니다.
구조화된 인덱스란 무엇인가
그것은 문서마다 한 행으로 이루어진 작은 테이블이며, 문서가 이미 포함하고 있는 필드들로 구성됩니다. 아무것도 발명되지 않으며 아무것도 다시 쓰이지 않습니다 — 값은 문자 단위로 복사됩니다.
이것이 설정되면 에이전트는 하나의 방법이 아닌 두 가지 방법으로 답변할 수 있습니다:
| 질문 | 답변 제공자 |
|---|---|
| "공룡에 관한 것이 있나요?" | 벡터 검색 |
| "몇 개 있나요?" | 테이블 |
| "공룡에 관한 것이지만, 5세 아동에게 적합해야 합니다" | 테이블 필터링, 벡터 검색 랭킹 |
| "링크와 표지 이미지는 무엇인가요?" | 테이블, 정확히 인용 |
필드를 정의하지는 않지만, 최종 결정권은 가집니다
플랫폼은 몇 개의 문서를 읽고 필드를 제안한 후, 이를 유지하기 전에 전체 컬렉션과 대조하여 각 필드를 검증합니다. 문서의 5분의 1에서만 나타나는 필드는 삭제되며 보고됩니다. 왜냐하면 이를 필터링하면 나머지 문서가 묵시적으로 제외되기 때문입니다.
다음 두 가지 유형의 입력은 사용자가 제공합니다:
정확해야 하는 필드. 고객에게 보낼 링크는 무엇이며, 세 가지 코드 중 고객이 다시 인용할 코드는 무엇인가 — 사용자의 데이터는 이를 명시하지 않으며, 추론할 수도 없습니다. 미리 이름을 지정하면 해당 필드는 원문 그대로 추출되며 원문 그대로 인용됩니다.
평문으로 된 수정 사항. "저자를 추적하여 사람들이 그들의 다른 책을 찾을 수 있도록 하십시오." "일러스트레이터로 필터링하고 싶습니다." "표지 링크를 제거하십시오." 변경 사항은 기존 테이블에 대한 패치로 제안되며, 다시 쓰기가 아닙니다. 따라서 한 필드에 대한 요청이 다른 필드에 영향을 줄 수 없습니다. 문서에 없는 항목 — 내보내기에서 한 번도 존재하지 않은 출판 연도 — 을 요청하면 빈 열을 추가하는 대신 그렇게 알려줍니다.
이것은 또한 귀하의 데이터에 대해 무엇을 알려주는가
모든 필드는 수락되기 전에 전체 컬렉션에 걸쳐 측정되므로, 보고서는 일반적으로 아무도 알지 못했던 사항들을 정기적으로 표면화합니다. 수천 권의 타이틀로 구성된 실제 카탈로그 중 하나에서, 10분의 1이 페이지 수를 0으로 가지고 있음을 발견했습니다 — 짧은 책이 아니라, 누락된 값이 0으로 기록된 것이었으며, 이는 모든 평균을 낮추고 "가장 짧은" 항목에서 큰 동점을 초래했을 것입니다.
이 검사는 어딘가에서 발생해야 합니다. 오늘날 그것은 보통 고객이 잘못된 답변을 알아차렸을 때 발생합니다.
적용되지 않는 경우
문서가 산문 — 기사, 녹취록, 서신 — 인 경우, 테이블로 만들 항목이 없으며, 플랫폼은 모든 값이 서로 다른 인덱스를 생성하는 것보다 인덱스를 구축하지 않기로 합니다. 그러한 테이블은 의미 있는 방식으로 카운트하거나 그룹화할 수 없으며, 이를 보유하는 것은 답변이 좋지 않은 질문을 유발할 뿐입니다.
벡터 검색은 그러한 자료에 대해 적절하고 유일한 도구입니다.
자주 묻는 질문
- 에이전트가 고객에게 제가 어떤 제품을 몇 개나 보유하고 있는지 알려줄 수 없는 이유는 무엇인가요?
- 벡터 검색은 질문과 유사하게 읽히는 몇몇 구문을 반환할 뿐이며, 이러한 구문들의 수를 세는 것은 불가능합니다. 이는 튜닝 문제가 아니며, 검색이 총계를 반환하도록 하는 설정은 존재하지 않습니다. 구조화된 인덱스는 문서에 이미 포함된 필드에서 구축된 작은 테이블을 쿼리하여 카운팅, 범위 및 그룹화 질문을 처리하며, 벡터 검색은 의미 관련 질문을 계속 처리합니다.
- 에이전트가 링크나 제품 코드를 임의로 생성하나요?
- 필드가 정확함(exact)으로 표시된 경우 그렇지 않습니다. 해당 값은 모델에 전혀 표시되지 않으며, 모델은 플레이스홀더를 받으며 플랫폼이 출력 시 저장된 값을 대체합니다. 모델은 본 적이 없는 URL을 오타낼 수 없습니다. 이는 직감보다 더 중요한 사항입니다. 일반적인 실패 사례는 링크를 임의로 생성하는 것이 아니라, 다른 항목에 속한 실제 링크를 반환하여 링크가 정상적으로 열리고 올바르게 보이는 경우입니다.
- 이것을 구축할 수 있는 문서의 종류는 무엇인가요?
- 기계 판독 가능한 헤더를 공유하는 문서입니다: 메타데이터 테이블, YAML front matter, 또는 Field: value 라인 등이 해당됩니다. 제품 내보내기, 카탈로그, 의약품 설명서, 정책 일정표 및 과정 목록은 일반적으로 해당됩니다. 일반 산문은 해당되지 않으며, 플랫폼은 무의미한 테이블을 구축하지 않고 대신 그 사실을 알립니다. 모든 값이 다른 테이블은 의미 있게 카운팅하거나 그룹화할 수 없습니다.
- 제가 직접 필드를 정의해야 하나요?
- 아니요. 플랫폼은 몇몇 문서를 읽어서 필드를 제안한 후, 전체 컬렉션과 비교하여 모든 필드를 검증한 후 유지합니다. 이후 일반 언어로 필드를 추가, 이름 변경 또는 삭제할 수 있으며, 제목, 링크, 이미지, 코드와 같이 정확히 추출해야 하는 필드를 미리 지정할 수 있습니다. 고객에게 보낼 링크가 무엇인지는 데이터가 명시하지 않는 비즈니스 사실이기 때문입니다.
- 이를 추가하면 지식 기반이 다시 처리되나요?
- 아니요. 임베딩이 다시 계산되지 않습니다. 필드는 문서에 이미 포함된 텍스트에서 직접 읽히므로, 인덱스를 구축하거나 변경하는 데 재인덱싱 비용이 들지 않으며 이미 작동 중인 벡터 검색을 방해하지 않습니다.
- 문서를 추가하거나 제거할 때 어떻게 최신 상태를 유지하나요?
- 새로운 문서는 이미 확립된 규칙을 사용하여 가져오는 즉시 읽히므로, 모델 대기 시간이 발생하지 않습니다. 인덱스 자체는 해당 인덱스가 필요한 다음 질문이 있기 전에 필요에 따라 다시 구축됩니다. 천 개의 문서를 추가한다고 해서 천 번의 재구축이 트리거되지는 않습니다.
에이전트가 알아야 할 것의 대부분은 이미 어딘가에 적혀 있습니다 — 당신의 웹사이트에, 그리고 당신 팀이 이미 고객에게 보내는 PDF에. URL에서 가져오기는 공개된 절반을 다루고, 업로드가 나머지를 다룹니다.
스토리라인은 에이전트가 각 최종 사용자와 함께 따라가는 방향 그래프입니다 — 모든 노드는 하나의 단계(고유한 태스크, 지식, 도구)이고, 출구는 조건을 지니며, 각 사람의 진행 상황·프로필·메모는 세션과 채널을 넘어 저장되고 재개됩니다. 이것은 에이전트를 점(point) 작업을 하는 어시스턴트에서, 다단계 서비스를 스스로 수행하는 존재로 바꿉니다.
다이내믹 플래너는 대화를 지켜보다가, 사용자가 에이전트의 영역 안에서 진짜로 여러 단계가 필요한 일을 하려 하고 어떻게 진행해야 할지 눈에 띄게 막막해할 때, 그 일을 임시 스토리라인 — 체크리스트로 움직이는 단계별 계획 — 으로 펼칠지 제안합니다. 에이전트는 그 계획을 한 번에 한 단계씩, 사용자가 볼 수 있는 진행 상황과 함께 실행합니다. 계획 수립은 검증을 거쳐 한 번만 일어나고, 실행은 결정적입니다.
장문 작성은 에이전트가 먼저 개요를 계획하고, 시작하기 전에 필요한 모든 것을 요청하며, 각 섹션을 귀하의 자료와 공개 출처에 대해 조사한 후 섹션별로 작성하여 재시작 시에도 유지되는 작업을 통해 완성된 다중 섹션 문서(예: 제출 서류, 시장 진출 보고서, 실사 메모)를 생성합니다. 채팅 옆의 캔버스에서 문서를 편집하고, 선택한 구절을 통해 어떤 구절이든 다시 작성할 수 있으며, 모든 버전이 보관됩니다.