청킹은 모든 사람이 우연히 내리는 검색 결정입니다.

모든 검색 프로젝트에는 누군가가 숫자를 입력하는 순간이 있습니다. 500개의 토큰. 천. 튜토리얼에서 사용한 것이 무엇이든. 파이프라인이 작동하고 데모가 질문에 답하며 해당 숫자는 다시 검사되지 않습니다.

청킹은 전처리 세부 사항이 아니기 때문에 얻는 것보다 더 많은 주의를 기울일 가치가 있습니다. 어떤 사실을 함께 검색할 수 있는지 결정하는 것은 결정이며, 다운스트림에서 아무리 영리한 순위를 매겨도 청킹이 파괴된 관계를 복구할 수는 없습니다.

구체적으로 무엇이 잘못됐는가

너무 작은 덩어리는 단일 아이디어를 여러 조각으로 조각냅니다. 답변은 코퍼스에 존재하지만 개별 청크에는 관련성이 있어 보일 만큼 충분한 답변이 포함되어 있지 않으므로 점수가 높지 않으며 에이전트는 대신 자체 가정에 따라 답변합니다.

너무 큰 청크는 일치하는 부분과 함께 관련 없는 재료를 끌어당깁니다. 검색은 성공한 것처럼 보이고 컨텍스트 창은 잡음으로 가득 차고 에이전트는 잘못된 단락에 대해 미묘하게 뭔가를 생성합니다. 이번 실패는 첫 번째 실패보다 더 나쁘다. 왜냐하면 눈에 띄는 격차보다는 자신감 있는 결과물을 만들어내기 때문이다.

두 가지 실패는 모두 외부에서 동일해 보입니다. 에이전트는 누구도 즉시 설명할 수 없는 방식으로 잘못된 답변을 제공합니다.

구조가 크기를 이긴다

팀이 수행하는 가장 유용한 변화는 토큰 수에 대한 생각을 멈추고 문서 구조에 대한 생각을 시작하는 것입니다.

정책 문서에는 섹션이 있습니다. 지원 아카이브에는 티켓당 하나의 문제가 있습니다. API 참조에는 항목당 하나의 엔드포인트가 있습니다. 그 경계는 당신이 경계를 필요로 하는 것과 같은 이유로 사람에 의해 설정되었습니다. 경계는 하나의 아이디어가 멈추고 다른 아이디어가 시작되는 지점을 표시합니다. 기본 규칙이 아닌 대체 수단으로 크기 제한을 사용하여 분할하는 것은 길이만으로 분할하는 것보다 지속적으로 성능이 뛰어납니다.

문서에 사용 가능한 구조가 없는 경우 중복은 저렴한 완화 방법입니다. 경계를 넘어 한두 문장을 전달하는 데에는 저장 비용이 들고 그 외에는 거의 비용이 들지 않으며, 핵심 문장이 분할을 지나 하나의 토큰에 도달하는 특정 사례를 구출합니다.

메타데이터가 과소평가되었습니다

덩어리는 단순한 텍스트가 아닙니다. 그것은 텍스트에 해당 문서가 속한 문서, 그 위의 섹션 제목, 작성된 날짜, 소유한 팀, 대체되었는지 여부 등 해당 문서가 어디서 왔는지에 대해 알고 있는 모든 정보를 포함합니다.

해당 메타데이터를 통해 에이전트는 순위를 매기기 전에 필터링할 수 있으며, 이는 일반적으로 임베딩 변경보다 정확도가 더 높습니다. "현재 버전의 규정 준수 핸드북을 검색하는 것"은 "모든 것을 검색하고 현재 버전의 점수가 가장 높기를 바랍니다"보다 근본적으로 쉬운 문제입니다.

또한 모든 잘못된 출력에 뒤따르는 질문에 대한 답도 제공합니다. 이는 어디서 나온 것입니까? 출처를 전달하는 청크는 디버깅을 고고학에서 조회로 전환합니다.

평가해 보세요. 논쟁하지 마세요.

청킹 전략은 긴 의견과 짧은 증거를 생성하는 일종의 주제입니다. 탈출구는 에이전트 작업의 다른 모든 곳과 동일합니다. 평가를 먼저 작성하세요.

사람들이 시스템에 실제로 묻는 30~40개의 실제 질문과 각 질문에 답해야 하는 구절을 모아보세요. 그런 다음 해당 구절이 전혀 검색되는지 여부를 측정합니다. 검색과 생성을 통합하는 최종 답변이 잘 읽히는지 여부가 아니라 올바른 자료가 모델에 도달했는지 여부입니다.

이를 통해 청킹은 논쟁이 아닌 실험이 됩니다. 전략을 변경하고 세트를 다시 실행하고 더 많은 것을 검색하는 버전을 유지하십시오. 이 하네스를 초기에 구축한 팀은 청킹 논쟁을 완전히 중단하는 경향이 있습니다. 이제 문제를 해결하는 저렴한 방법이 있기 때문입니다.

실행 중인 에이전트에 연결하는 방법

검색 품질은 에이전트 작업과 별개의 문제가 아닙니다. 모든 호출에 200개의 토큰을 추가하는 검색 변경은 비용 변경이고, 회상을 향상시키는 검색 변경은 품질 변경입니다. 둘 다 에이전트가 수행하는 다른 모든 작업과 동일한 평가 루프에 속합니다.

이것이 Oran의 평가가 행동, 구조, 대기 시간 및 비용 기준을 함께 평가하는 이유이며, Optimizer가 동일한 평가에 대해 자체 변경 사항을 측정하는 이유입니다. 비용을 절약하기 위해 컨텍스트를 다듬는 것은 검색에서 여전히 필요한 것을 찾는 경우에만 절약됩니다.

어디서부터 시작해야 할까요?

이미 프로덕션에 검색 시스템이 있고 평가 세트가 없는 경우, 조잡한 평가 세트라도 먼저 평가 세트를 빌드하십시오. 한 달 간의 튜닝보다 오후에 더 많은 것을 알려줄 것입니다. 개발자 문서에서는 메커니즘을 다루고, 에이전트 오케스트레이션 시스템 페이지에서는 평가 및 비용 계층이 어떻게 적용되는지 다룹니다.