임베딩에서 "충분히 좋다"는 것에 안주하지 마세요

검색 시스템은 관련성이 있어 보이지만 여전히 사용자에게 실망스러운 결과를 반환할 수 있습니다. 이것이 "충분히 좋은" 임베딩의 문제입니다. 모델은 관련된 문장을 서로 가까이 배치하지만 중요한 의미를 놓칠 수 있습니다. '구독 취소'와 '구독 일시 중지'를 거의 동일한 요청으로 처리할 수 있습니다. 사용자의 실제 목적을 무시한 채 제품명과 일치할 수도 있습니다. 지원 검색, 제품 카탈로그 및 문서 도우미에서 이런 일이 발생하는 것을 보았습니다. 시스템은 쿼리에 연결된 내용을 반환하지만 유용한 내용은 반환하지 않습니다. 그런 다음 사용자는 질문을 반복하거나, 문구를 변경하거나, 검색 경험에 대한 신뢰를 중단합니다. 더 나은 임베딩은 더 나은 프로세스에서 시작됩니다. ## 임베딩이 보존해야 하는 사항 이해 임베딩은 텍스트를 숫자 표현으로 변환합니다. 유사한 의미는 벡터 공간에서 서로 가깝게 위치해야 합니다. 텍스트에 다음과 같은 세부 정보가 포함되기 전까지는 간단해 보입니다. - 제품 모델 - 버전 번호 - 사용자 역할 - 날짜 - 법적 조건 - 부정 - 단계별 지침 - 결과가 다른 유사한 용어 다음 두 문장을 생각해 보세요. - "최대 3개월 동안 계획을 일시 중지할 수 있습니다." - “3개월 이내에는 요금제를 취소할 수 있습니다.” 말은 겹치지만 행동은 다릅니다. 약한 임베딩으로 인해 너무 가까워질 수 있습니다. 유용한 시스템은 일시 중지와 취소 간의 차이를 보존해야 합니다. 나는 벡터가 얼마나 자연스러워 보이는가에 따라 임베딩을 판단하지 않습니다. 완전한 검색 작업에 도움이 되는지 여부로 판단합니다. ## 실제 사용자 질문으로 시작 일반 벤치마크 데이터는 모델을 비교하는 데 도움이 될 수 있지만 사용자가 검색하는 방법을 보여주지는 않습니다. 나는 다음에서 실제 쿼리를 수집하는 것을 선호합니다. - 검색 로그 - 지원 티켓 - 채팅 대화 - 판매 질문 - 내부 지식 요청 - 실패한 검색 - 반복적인 페이지 방문으로 이어진 쿼리 개인 정보를 제거하고 의도에 따라 질문을 그룹화합니다. 그룹에는 환불, 계정 액세스, 배송 변경 또는 기술 설정에 대한 질문이 포함될 수 있습니다. 그런 다음 작은 참조 세트를 만듭니다. 각 쿼리에 대해 상단 근처에 표시되어야 하는 문서를 기록합니다. 초기 문제를 찾기 위해 대규모 컬렉션이 필요하지 않습니다. 100~300개의 쿼리로 구성된 집중 세트는 문구, 청크 크기, 메타데이터 및 순위와 관련된 문제를 드러낼 수 있습니다. 유용한 테스트 기록은 다음과 같습니다. 텍스트 쿼리: 첫 번째 결제 후 연간 요금제를 일시 중지할 수 있나요? 관련 조항: 첫 번째 청구 주기 후에 연간 요금제를 일시 중지할 수 있습니다. 일시 중지는 최대 3개월 동안 지속됩니다. 관련이 있지만 잘못된 구절: 연간 요금제는 구매 후 3개월 이내에 취소할 수 있습니다. 이 예는 주제 유사성 이상의 것을 테스트합니다. 조치, 시기, 정책 세부 사항을 테스트합니다. ## 모델을 변경하기 전에 텍스트를 개선하세요. 많은 임베딩 문제는 잘못된 입력 텍스트에서 시작됩니다. 문서에는 제목, 단락, 표, 각주가 포함될 수 있습니다. 추출 프로세스에서 이러한 섹션을 혼합하면 포함 시 혼란스러운 콘텐츠 블록이 수신됩니다. 저는 보통 네 가지 영역을 확인합니다. ### 1. 제목 유지 환불에 관한 문단은 제목이 포함될 때 더 많은 의미를 갖습니다. 삽입 대신: 텍스트 요청은 배송 후 14일 이내에 이루어져야 합니다. 사용: text 반품 — 기한 반품 요청은 배송 후 14일 이내에 이루어져야 합니다. ``` 추가된 컨텍스트는 벡터에 더 명확한 신호를 제공합니다. ### 2. 관련 내용을 함께 유지 조건의 중간에 끝나는 청크는 다음 문장의 의미를 잃을 수 있습니다. 잘못된 분할:text 기기에 제조상의 결함이 있는 경우 고객은 환불을 요청할 수 있습니다. Better Split:텍스트가 있는 경우 환불이 불가능합니다. 기기에 제조상의 결함이 있는 경우 고객이 환불을 요청할 수 있습니다. 잘못된 사용으로 인해 손상이 발생한 경우 환불이 불가능합니다. ``` 청크 경계는 고정된 문자 수만 사용하기보다는 의미를 따라야 합니다. ### 3. 너무 큰 청크를 피하세요. 큰 청크에는 여러 주제가 포함될 수 있습니다. 그러면 벡터는 명확한 대답 대신 광범위한 혼합을 나타냅니다. 제품 가이드에서는 설치, 유지 관리, 보증 범위 및 문제 해결을 한 섹션에서 논의할 수 있습니다. 보증 적용 범위에 대한 쿼리로 전체 섹션을 검색할 수 있지만 유용한 부분을 식별하기가 더 어려워집니다. 작은 청크는 종종 검색에 도움이 되지만 매우 작은 청크는 컨텍스트를 제거할 수 있습니다. 습관적으로 숫자를 선택하는 대신 여러 사이즈를 테스트하고 결과를 확인합니다. ### 4. 주요 식별자를 그대로 유지하세요. 모델명, 오류 코드, 계획명, 기술 용어 등을 여러 부분으로 나누어서는 안 됩니다. 예를 들어, "계정 확인 중 오류 PX-204"를 별도의 조각으로 분할하면 키워드 검색과 의미 검색이 모두 약화될 수 있습니다. 청크는 의미를 부여하는 설명과 함께 식별자를 유지해야 합니다. ## 최종 순위와 별도 검색 임베딩은 후보를 찾는 데 좋습니다. 모든 순위 결정을 혼자서 내릴 필요는 없습니다. 실제 검색 흐름은 다음을 사용할 수 있습니다. 1. 의미에 대한 밀집 검색 2. 이름, 코드 및 정확한 문구에 대한 키워드 검색 3. 제품, 언어, 날짜 또는 액세스 수준에 대한 메타데이터 필터 4. 최종 주문에 대한 재순위 지정 사용자가 "PX-204 로그인 오류"를 검색한다고 가정합니다. 의미론적 모델은 다른 코드를 사용하는 계정 확인 오류에 대한 문서를 검색할 수 있습니다. 키워드 일치는 정확한 코드를 보호할 수 있습니다. 두 가지 검색 방법을 함께 사용할 수 있습니다. 나는 종종 모든 쿼리를 처리하기 위해 하나의 방법을 요구하는 것보다 시스템이 의미론적 신호와 어휘적 신호를 결합할 때 더 나은 결과를 봅니다. 메타데이터에도 동일하게 적용됩니다. 모바일 앱에 대한 쿼리는 문구가 유사하다는 이유만으로 이전 데스크톱 가이드를 반환해서는 안 됩니다. 필터는 최종 순위 단계 전에 이러한 유형의 노이즈를 줄일 수 있습니다. ## 쉬운 일치뿐만 아니라 어려운 예제 테스트 쉬운 쿼리는 거의 모든 임베딩 시스템을 건강해 보이게 만듭니다. 하드 쿼리는 어디에서 중단되는지 보여줍니다. 다음을 포함하는 테스트 케이스 구축: - 동의어 - 오타 - 짧은 쿼리 - 긴 질문 - 부정적인 표현 - 유사한 제품 - 유사한 정책 - 여러 언어 - 두문자어 - 버전 번호 - 컨텍스트가 누락된 쿼리 각 쿼리에 대해 올바른 구절이 상위 결과에 나타나는지 확인합니다. Recall@K 및 MRR과 같은 측정값을 추적할 수 있지만 사람의 검토는 여전히 중요합니다. 결과는 사용자의 요구에 응답하지 못하더라도 관련된 것으로 간주될 수 있습니다. 또한 오탐지도 검토합니다. 매우 유사해 보이는 잘못된 결과는 모델이 혼동하는 내용을 보여주기 때문에 무작위 누락보다 더 유용한 경우가 많습니다. 예: 텍스트 쿼리: 청구 내역을 잃지 않고 소유권을 이전하려면 어떻게 해야 합니까? 일치하지 않음: 파일을 다른 계정으로 어떻게 전송하나요? 유용한 일치: 관리자가 완료하면 계정 소유권 이전이 청구 내역을 보존합니다.두 구절 모두 이체와 계좌에 대해 언급하고 있습니다. 단 하나만 사용자의 전체 의도를 해결합니다. ## 배포 후 변경 사항을 확인하세요. 콘텐츠가 변경되면 삽입 품질이 바뀔 수 있습니다. 새로운 제품 이름은 이전 제품 이름과 유사할 수 있습니다. 정책 업데이트는 보관된 페이지와 충돌할 수 있습니다. 기능 출시 후 고객 언어가 변경될 수 있습니다. 지난 분기에는 잘 작동했던 검색 시스템이 대용량 문서를 가져온 후에는 좋지 않은 결과를 낳을 수도 있습니다. 각 콘텐츠나 모델 업데이트의 일부로 작은 평가 세트를 유지하는 것이 좋습니다. 새로운 결과를 이전 버전과 비교해보세요. 다음 사항에 주의하세요. - 올바른 결과를 잃은 쿼리 - 새로운 잘못된 일치 - 상위 결과 순서 변경 - 빈 결과 비율 - 반복 검색 - 빠른 반환이 뒤따르는 클릭 - 검색에 실패한 지원 질문 사용자 피드백을 통해 오프라인 테스트에서 놓친 문제를 알 수 있습니다. 사람들이 반복적으로 결과를 열고 다시 검색하면 결과가 관련되어 있지만 충분하지 않을 수 있습니다. ## 임베딩 모델을 무시하지 마세요. 텍스트 준비와 순위 디자인이 중요하지만 모델은 여전히 ​​성능에 영향을 미칩니다. 모델을 비교할 때 다음을 사용하십시오. - 문서 - 청킹 규칙 - 쿼리 세트 - 필터 - 인덱스 설정 - 순위 지정 프로세스 모델은 공개 테스트에서 강력해 보일 수 있지만 도메인 언어에서는 성능이 좋지 않을 수 있습니다. 더 작은 모델은 명확한 지원 기사에 적합할 수 있는 반면, 특수 모델은 기술 용어 또는 다국어 콘텐츠에 도움이 될 수 있습니다. 비용과 속도도 결정에 포함됩니다. 약간 더 나은 검색 기능을 제공하지만 허용할 수 없는 지연을 생성하는 모델은 제품에 적합하지 않을 수 있습니다. 올바른 선택은 하나의 점수가 아닌 전체 사용자 경험에 달려 있습니다. ## 디버깅을 위한 충분한 정보 저장 벡터 데이터베이스는 블랙박스가 되어서는 안 됩니다. 각 청크에 대해 다음과 같은 유용한 필드를 유지하십시오. - 소스 문서 - 제목 경로 - 제품 또는 콘텐츠 유형 - 언어 - 게시 날짜 - 액세스 규칙 - 청크 위치 - 소스 버전 결과가 잘못된 것으로 보이는 경우 이러한 필드는 원인을 설명하는 데 도움이 됩니다. 벡터는 괜찮았지만 문서가 오래되었다는 것을 알 수 있습니다. 필터가 가장 좋은 구절을 제거한 것을 발견할 수 있습니다. 두 개의 청크가 동일한 가이드의 서로 다른 버전에서 나온 것을 볼 수 있습니다. 결과가 어떻게 생성되었는지 시스템이 보여줄 수 있으면 디버깅이 훨씬 쉬워집니다. ## "충분히 좋음"을 목표가 아닌 테스트 결과로 취급합니다. 유용한 제품을 지원하기 위해 임베딩이 완벽할 필요는 없습니다. 작업, 콘텐츠, 사용자 언어와 일치해야 합니다. 나는 세 가지 질문에 중점을 둡니다. - 쿼리 근처에 올바른 의미가 나타나는가? - 순위 시스템이 최고의 통로를 충분히 높은 곳에 배치할 수 있나요? - 사용자가 검색을 반복하지 않고 작업을 완료할 수 있습니까? 이들 중 하나라도 '아니요'라고 대답하면 임베딩 모델을 변경해도 문제가 해결되지 않을 수 있습니다. 원인은 약한 청크, 컨텍스트 누락, 잘못된 필터, 오래된 콘텐츠 또는 완전 일치 지원 부족일 수 있습니다. 좋은 검색은 전체 시스템에서 나옵니다. 임베딩은 해당 시스템의 일부이며 그 가치는 벡터 검색이 단독으로 얼마나 수용 가능한지에 따라 측정되는 것이 아니라 사용자가 찾을 수 있는 답변으로 측정됩니다.

많은 팀은 모델을 벡터 데이터베이스에 연결하자마자 임베딩이 콘텐츠를 이해할 것으로 기대합니다. 첫 번째 검색은 종종 유망해 보입니다. 그런 다음 작은 문제가 나타납니다. 고객이 환불에 대해 문의했지만 시스템이 배송 물품을 검색합니다. 개발자가 '로그인 시간 초과'를 검색하면 시스템에서 비밀번호 재설정에 대한 문서를 반환합니다. 제품 이름에는 여러 버전이 있으므로 유사한 텍스트가 잘못된 항목을 가리킵니다. 나는 임베딩 품질이 모델보다 더 많은 것에 달려 있다는 것을 발견했습니다. 좋은 결과는 일반 텍스트, 적절한 청크, 유용한 메타데이터 및 정기적인 테스트에서 나옵니다. ## 검색 문제부터 시작합니다. 사용자가 찾고자 하는 내용을 적는 것부터 시작합니다. 지원팀은 다음과 같은 질문에 답변해야 할 수도 있습니다. - "손상된 품목을 반품할 수 있습니까?" - "표준 배송은 얼마나 걸리나요?" - "결제가 거부된 이유는 무엇입니까?" - “배송지 변경이 가능한가요?” 이러한 질문은 모두 주문이나 결제에 대해 언급하기 때문에 관련성이 있어 보입니다. 그들의 답변은 다른 문서에 있을 수 있습니다. 검색 시스템은 단순히 공유된 단어를 일치시키는 것이 아니라 사용자의 의도를 이해해야 합니다. 나는 지원 티켓, 웹사이트 로그, 내부 팀으로부터 실제 검색어를 수집합니다. 작은 세트의 실제 질문은 대량의 꾸며낸 예보다 더 많은 것을 드러낼 수 있습니다. ## 임베딩을 만들기 전에 콘텐츠를 정리하세요. 소스 텍스트가 좋지 않으면 임베딩 모델의 품질이 제한될 수 있습니다. 반복되는 탐색 메뉴, 손상된 HTML, 추적 텍스트 및 중복 페이지를 제거합니다. 사용자가 주제를 이해하는 데 도움이 되는 정보를 보관합니다. - 제품 이름 - 서비스 조건 - 날짜 - 위치 - 사용자 요구 사항 - 예외 - 단계별 지침 또한 주요 용어를 명확하게 합니다. “표준 계획”이라고 적힌 페이지는 계획을 식별하는 제목 없이 저장되면 혼란스러울 수 있습니다. 나는 "표준 요금제: 고객은 구매 후 30일 이내에 취소할 수 있습니다."와 같은 완전한 내용을 선호합니다. 이 문장은 “고객은 30일 이내에 취소할 수 있습니다”보다 더 많은 의미를 담고 있습니다. ## 콘텐츠에 맞는 청크 크기를 선택하세요. 청크가 너무 짧으면 컨텍스트가 손실될 수 있습니다. 너무 긴 청크에는 관련되지 않은 여러 주제가 포함될 수 있습니다. 제품 설명서의 경우 제목과 지원 단계가 포함된 한 섹션을 사용할 수 있습니다. 법적 정책 또는 가격 책정 페이지의 경우 조건 및 예외가 포함된 완전한 규칙을 유지할 수 있습니다. 유용한 덩어리에는 다음이 포함되는 경우가 많습니다. - 명확한 제목 - 하나의 주요 아이디어 - 해당 아이디어를 이해하는 데 필요한 세부 정보 - 소량의 주변 컨텍스트 문장을 덩어리로 나누는 것을 피합니다. 관련 물품도 함께 보관하고 있어요. 시간 제한이 없는 반품 규칙은 정답처럼 들리지만 핵심 조건을 생략하는 답변을 생성할 수 있습니다. 모든 프로젝트에 맞는 단일 청크 크기는 없습니다. 동일한 검색 질문으로 여러 옵션을 테스트하고 결과를 비교합니다. ## 텍스트 옆에 메타데이터 유지 임베딩은 텍스트의 의미를 나타냅니다. 메타데이터는 필터와 비즈니스 컨텍스트를 추가합니다. 각 청크에 대해 다음을 저장할 수 있습니다. - 문서 제목 - 제품 또는 서비스 이름 - 언어 - 지역 - 고객 유형 - 출판 날짜 - 액세스 수준 - 소스 URL - 버전 번호 "모바일 요금제 취소"를 검색하려면 국가 필터가 필요할 수 있습니다. "최신 API 제한"을 검색하려면 버전 필터가 필요할 수 있습니다. 메타데이터가 없으면 잘못된 지역이나 버전의 의미상 유사한 콘텐츠가 결과에 입력될 수 있습니다. 나는 메타데이터를 나중에 고려하는 것이 아니라 검색 설계의 일부로 취급합니다. ## 모델을 콘텐츠와 일치시킵니다. 일반 텍스트에 대해 훈련된 임베딩 모델은 일반적인 질문에 잘 작동할 수 있습니다. 기술 검색 시스템에는 제품 코드, 소프트웨어 용어 또는 짧은 쿼리를 보다 강력하게 처리해야 할 수도 있습니다. 고객이 사용하는 언어, 문서 스타일, 쿼리 길이를 사용하여 모델을 테스트합니다. 모델은 영어 지원 콘텐츠에서는 잘 작동하지만 혼합 언어 문서, 약어 또는 업계 용어에서는 다르게 작동할 수 있습니다. 나는 하나의 예에서 모델을 선택하지 않습니다. 다음을 사용하여 테스트 세트를 만듭니다. - 일반적인 검색 - 간단한 검색 - 자세한 질문 - 철자 오류 - 제품 이름 - 필요할 때 다른 언어 - 날짜 또는 버전 번호가 포함된 쿼리 테스트 세트는 모델과 설정을 비교할 수 있는 안정적인 방법을 제공합니다. ## 정확한 용어가 중요한 경우 하이브리드 검색을 사용하세요. 임베딩은 의미 기반 검색에 유용합니다. 모든 정확한 용어를 잘 처리하지 못할 수도 있습니다. 사용자는 다음을 검색할 수 있습니다. - "ERR_CONN_RESET" - "SKU-48391" - "v2.4.7" - "AC-19 환불 코드" 키워드 시스템은 이러한 정확한 문자열을 보다 안정적으로 찾을 수 있습니다. 나는 종종 벡터 검색과 키워드 검색을 결합한 다음 두 신호를 모두 사용하여 결과의 ​​순위를 매깁니다. 이 접근 방식은 쿼리에 자연어와 정확한 식별자가 혼합되어 있을 때 도움이 됩니다. 시맨틱 레이어는 “결제가 왜 실패했나요?”를 연결할 수 있습니다. 결제 문제 해결 가이드와 함께 키워드 레이어는 해당 가이드 내에서 특정 오류 코드를 찾을 수 있습니다. ## 재순위 단계 추가 벡터 검색은 일반적으로 관련된 여러 구절을 반환할 수 있습니다. 순위 조정자는 쿼리와 후보 구절을 함께 검토한 다음 가장 관련성이 높은 항목을 더 높게 배치할 수 있습니다. 데이터베이스에 다음과 같은 유사한 문서가 많이 포함되어 있는 경우 이 단계를 사용합니다. - 여러 버전의 제품 지침 - 대규모 지식 기반 - 유사한 이름을 가진 여러 계획 - 공통 문구를 공유하는 지원 기사 순위를 다시 매겨도 잘못된 소스 콘텐츠는 수정되지 않습니다. 초기 검색에서 유용한 후보 그룹이 반환될 때 가장 잘 작동합니다. ## 실제 질문을 통한 측정 검색 검색 시스템은 결과가 '좋다'는 것만으로 판단되어서는 안 됩니다. 나는 작은 평가 테이블을 사용합니다. 각 쿼리에 대해 다음을 기록합니다. - 예상되는 문서 또는 구절 - 상위 결과에 나타나는지 여부 - 해당 위치 - 구절에 충분한 맥락이 포함되어 있는지 여부 - 결과가 올바른 제품 또는 지역에 속하는지 여부 100개의 지원 질문을 테스트한다고 가정합니다. 82개 질문에 대한 처음 5개 결과에 올바른 구절이 나타나면 유용한 기준이 있는 것입니다. 숫자만으로는 모든 문제를 설명할 수 없으므로 실패한 검색을 유형별로 검토합니다. 한 소매 팀에서는 대부분의 실패가 오래된 제품 페이지에서 비롯된다는 사실을 발견할 수 있습니다. 다른 팀에서는 청크가 배송 규칙을 예외와 분리한다는 것을 알 수 있습니다. 수정 방법은 오류 패턴에 따라 다릅니다. ## 의미가 바뀌는 문구 주의 작은 문구 차이가 검색에 영향을 미칠 수 있습니다. - "취소 후 환불" - "환불 후 취소" - "배송 후 환불 불가" - "배송 전에만 환불 가능" 이 문구는 많은 단어를 공유하지만 다른 규칙을 설명합니다. 나는 그들이 수정하는 진술에 가까운 조건을 유지합니다. 또한 의미가 있는 경우 제목, 레이블, 표 컨텍스트를 보존합니다. 테이블 관리가 필요합니다. '기본 요금제 | 사용자 5명 | $20'라는 행은 별도의 조각으로 추출되면 의미를 잃을 수 있습니다. 임베딩을 만들기 전에 읽을 수 있는 텍스트로 변환합니다. ## 임베딩을 연결하여 신중하게 답변 생성 검색과 답변 생성은 별도의 작업입니다. 검색 결과가 강력하다고 해서 정답이 보장되는 것은 아닙니다. 언어 모델은 여전히 ​​다른 버전의 구절을 결합하거나 지원되지 않는 세부 사항으로 공백을 채울 수 있습니다. 소스 정보를 답변 레이어에 전달하고 검색된 콘텐츠 내에 머물도록 요청합니다. 또한 사용 사례에 검토가 필요한 경우 인용이나 소스 링크를 표시합니다. 지원 상담원, 규정 준수 팀, 기술 사용자는 응답하기 전에 원래 내용을 확인해야 할 수도 있습니다. 시스템에 정보가 충분하지 않은 경우 더 자세한 내용을 명확하게 요청하는 것이 확실한 추측보다 안전합니다. ## 콘텐츠 변경 후 시스템 검토 지식 기반은 시간이 지남에 따라 변경됩니다. 새로운 가격, 제품 버전, 정책 및 도움말 문서가 검색에 영향을 미칠 수 있습니다. 각 레코드의 소스 버전과 포함 날짜를 추적합니다. 문서가 변경되면 레이블 없이 이전 버전과 새 버전을 혼합해 두는 대신 관련 청크를 업데이트합니다. 다음 후 검색 성능을 검토합니다. - 주요 제품 출시 - 정책 업데이트 - 새로운 언어 추가 - 고객 질문 변경 - 검색 인터페이스 재설계 사용자 피드백은 여기에 도움이 됩니다. "도움이 되지 않는" 작업, 재구성된 쿼리 또는 지원 담당자의 수정으로 인해 누락된 동의어나 불분명한 문구가 드러날 수 있습니다. ## 실용적인 작업 흐름 저는 많은 임베딩 프로젝트에 이 순서를 사용합니다. 1. 실제 사용자 검색을 수집합니다. 2. 유용한 결과로 간주되는 것이 무엇인지 정의하십시오. 3. 소스 콘텐츠를 정리하고 정리합니다. 4. 제목과 컨텍스트를 사용하여 청크 크기를 테스트합니다. 5. 필터 및 버전에 대한 메타데이터를 추가합니다. 6. 적합한 임베딩 모델을 비교합니다. 7. 정확한 용어가 중요한 경우 의미 검색과 키워드 검색을 결합하세요. 8. 많은 결과가 유사해 보일 때 순위 재지정을 추가하세요. 9. 레이블이 지정된 쿼리 세트로 테스트합니다. 10. 실패를 검토하고 소스 콘텐츠를 업데이트합니다. 가장 유용한 교훈은 간단합니다. 임베딩은 명확한 정보 아키텍처를 대체할 수 없습니다. 원본 콘텐츠가 중복되거나 불완전하거나 컨텍스트가 누락된 경우 검색 환경에 이러한 문제가 반영됩니다. 나는 임베딩을 더 큰 검색 시스템의 일부로 취급합니다. 저는 실제 질문으로 테스트하고, 각 청크 내부에 중요한 컨텍스트를 유지하고, 모든 결과를 올바른 제품, 버전 및 대상과 연결합니다. 이 프로세스를 통해 시스템은 요청을 이해하지 못한 채 단어를 일치시키는 대신 사용자가 의미하는 바를 더 잘 이해할 수 있습니다.

검색결과가 관련성이 없다고 느껴진다면 문제는 검색창이 아닐 수도 있습니다. 시스템이 언어를 이해하는 방식일 수도 있습니다. 키워드 검색은 일치하는 단어를 찾습니다. 임베딩 기반 검색은 의미를 살펴봅니다. 이러한 차이는 사용자가 다양한 방식으로 질문을 작성하거나, 업계 용어를 사용하거나, 필요한 정확한 페이지 이름을 지정하지 않고 문제를 설명할 때 중요합니다. 실제 문제는 데이터 준비 프로세스 내부에 있는 동안 팀이 검색 필터를 조정하는 데 시간을 소비하는 것을 보았습니다. 약한 텍스트 덩어리, 누락된 컨텍스트, 열악한 테스트로 인해 강력한 검색 모델이라도 혼란스러운 결과를 반환할 수 있습니다. ## 임베딩으로 검색을 개선하는 방법 임베딩은 텍스트를 의미를 나타내는 숫자 그룹으로 변환합니다. 비슷한 의미를 가진 텍스트는 임베딩 공간에서 서로 더 가깝게 나타나는 경향이 있습니다. 예: - "내 계정 비밀번호를 어떻게 재설정할 수 있나요?" - “비밀번호를 잊어버려서 로그인할 수 없습니다.” 이 문장들은 다른 단어를 사용하지만 비슷한 필요성을 설명합니다. 의미 검색 시스템은 기본 키워드 검색보다 이들을 더 효과적으로 연결할 수 있습니다. 동일한 접근 방식이 도움이 될 수 있습니다. - 제품 문서 - 고객 지원 포털 - 내부 지식 기반 - 전자 상거래 제품 검색 - 법률 또는 기술 문서 검색 - 질문 답변 시스템 임베딩은 사람과 동일한 방식으로 콘텐츠를 이해하지 않습니다. 시스템이 텍스트를 비교하는 데 도움이 되는 수학적 표현을 생성합니다. 결과의 품질은 모델, 소스 콘텐츠, 검색 설정에 따라 달라집니다. ## 깨끗한 소스 콘텐츠로 시작 임베딩 모델을 사용하기 전에 더 나은 검색이 시작됩니다. 소스 문서에서 다음 항목을 확인합니다. - 반복되는 탐색 메뉴 - 오래된 지침 - 손상된 서식 - 누락된 제품 이름 - 중복된 페이지 - 불분명한 제목 - 관련되지 않은 여러 주제를 결합한 콘텐츠 5가지 다른 문제가 포함된 지원 문서는 약한 임베딩을 생성할 수 있습니다. 시스템은 어떤 부분이 사용자의 질문과 일치하는지 결정하는 데 어려움을 겪을 수 있습니다. 보다 명확한 구조는 도움이 됩니다. 제목: 청구 이메일 변경 목적: 청구서 및 계정 알림에 사용되는 이메일 업데이트 단계: 계정 설정 열기, 청구 선택, 이메일 편집 및 저장 제한: 계정 관리자만 이 변경을 수행할 수 있습니다. 이 형식은 짧고 단절된 문장으로 가득 찬 페이지보다 검색 시스템에 더 유용한 컨텍스트를 제공합니다. ## 실용적인 청크 크기를 사용하십시오. 큰 문서는 포함되기 전에 더 작은 섹션으로 나누어야 하는 경우가 많습니다. 이 프로세스를 청킹이라고 합니다. 너무 큰 청크에는 여러 주제가 포함될 수 있습니다. 너무 작은 청크는 답변을 이해하는 데 필요한 컨텍스트를 잃을 수 있습니다. 나는 일반적으로 관련 정보를 함께 보관합니다. - 아래 단락이 있는 제목 - 답변이 있는 질문 - 조건이 있는 절차 - 제한이 있는 제품 기능 - 해결 방법이 있는 문제 해결 문제 예를 들어 이 청크는 잘 작동할 수 있습니다. > 월별 보고서를 내보내려면 보고서를 열고 월을 선택하고 CSV를 선택한 다음 내보내기를 클릭합니다. 뷰어 액세스 권한이 있는 사용자는 보고서를 볼 수 있지만 내보낼 수는 없습니다. 권한 세부정보는 내보내기 지침과 함께 유지되어야 합니다. 해당 줄을 분리하면 단계를 설명하지만 액세스 규칙을 놓친 답변이 나올 수 있습니다. 모든 프로젝트에 맞는 단일 청크 크기는 없습니다. 실제 쿼리로 여러 옵션을 테스트하고 결과를 비교합니다. ## 유용한 메타데이터를 유지하세요. 텍스트만으로는 충분한 정보를 제공할 수 없습니다. 메타데이터는 검색 시스템이 콘텐츠를 필터링하고 순위를 매기는 데 도움이 됩니다. 유용한 필드는 다음과 같습니다. - 제품 영역 - 언어 - 문서 유형 - 고객 계획 - 게시 날짜 - 지역 - 사용자 역할 - 액세스 수준 - 콘텐츠 상태 회사에 기본 계획과 엔터프라이즈 계획에 대한 별도의 설정 가이드가 있다고 가정해 보세요. 검색 시스템이 텍스트만 비교하는 경우 사용자는 잘못된 지침을 받을 수 있습니다. 메타데이터 필터는 사용자의 계정 유형을 올바른 문서 세트와 일치시켜 이러한 위험을 줄일 수 있습니다. 액세스 제어는 신중하게 처리할 가치가 있습니다. 문서의 단어가 쿼리와 일치한다는 이유만으로 문서가 검색 결과에 표시되어서는 안 됩니다. 검색 권한은 기본 애플리케이션과 동일한 규칙을 따라야 합니다. ## 의미론적 검색과 키워드 검색 결합 임베딩은 유용하지만 모든 상황에서 키워드 검색을 대체하지는 않습니다. 키워드 일치는 사용자가 다음을 검색할 때 유용할 수 있습니다. - 오류 코드 - 모델 번호 - 제품 이름 - 티켓 ID - 파일 이름 - 정확한 기술 용어 의미 검색은 자연스러운 질문 및 관련 단어에 잘 작동합니다. 하이브리드 검색은 두 가지 방법을 결합합니다. 예를 들어, 사용자는 다음을 검색할 수 있습니다. > AX-220 드라이버 설치 후 오류 E104 오류 코드와 모델 번호가 밀접하게 일치해야 합니다. '설치 후'라는 문구는 의미 검색이 해석에 도움이 될 수 있다는 의미를 추가합니다. 실용적인 순위 시스템은 다음 사항에 가중치를 부여할 수 있습니다. - 정확한 키워드 일치 - 의미적 유사성 - 문서의 최신성 - 제품 또는 계획 메타데이터 - 사용자 권한 - 과거 상호 작용 신호 올바른 균형은 검색 목표에 따라 다릅니다. 지원 포털은 기술 식별자를 중요하게 생각할 수 있습니다. 제품 검색 페이지에서는 의미와 사용자 선호도에 더 많은 비중을 둘 수 있습니다. ## 실제 질문으로 검색 품질 측정 검색 시스템은 작은 데모에서는 인상적으로 보일 수 있지만 일반 사용자에게는 여전히 성능이 좋지 않습니다. 실제 검색 동작을 바탕으로 테스트 세트를 구축합니다. 여기에는 다음이 포함될 수 있습니다. - 일반적인 질문 - 철자가 틀린 용어 - 간단한 쿼리 - 긴 설명 - 제품 코드 - 컨텍스트가 누락된 질문 - 결과를 반환하지 않아야 하는 쿼리 각 쿼리는 다음과 같은 판단을 받습니다. - 관련성 - 부분적으로 관련됨 - 관련 없음 - 유용한 결과 없음 소규모 지원 팀이 각 쿼리에 대한 상위 3~5개 결과를 검토할 수 있습니다. 이는 대규모 연구팀을 필요로 하지 않고도 실용적인 벤치마크를 생성합니다. 고객 지원 사례를 고려해보세요. 한 소프트웨어 회사는 사용자가 "송장 다운로드"를 검색했지만 결과가 일반 청구 페이지로 연결된다는 사실을 알아냈습니다. 데이터를 검토한 결과, 유용한 기사에 '수출 청구서'라는 문구가 사용된 것을 발견했습니다. 팀에서는 페이지 제목을 개선하고, 계정 권한 세부정보를 단계 근처에 유지하고, 청구를 위한 메타데이터를 추가하고, 키워드 및 의미 검색을 모두 테스트합니다. 이제 콘텐츠와 검색 방법이 동일한 사용자 요구를 지원하므로 검색 결과가 더욱 유용해졌습니다. 개선은 다음과 같은 데이터로 측정해야 합니다. - 관련 결과 클릭 - 검색 재구성 비율 - 결과 없음 비율 - 유용한 페이지를 열기까지의 시간 - 검색 후 지원 요청 - 사용자 피드백 낮은 결과 없음 비율이 도움이 되지만 모든 답변이 정확하다는 것을 증명하지는 않습니다. 관련성은 여전히 ​​검토가 필요합니다. ## 일반적인 삽입 문제에 주의하세요. 일부 문제는 구현 중에 자주 나타납니다. 오래된 콘텐츠 오래된 기사는 올바른 단어가 포함되어 있기 때문에 순위가 높을 수 있습니다. 출판 상태와 업데이트 날짜를 추가한 다음 트래픽이 많은 페이지를 검토하세요. 중복된 콘텐츠 동일한 가이드의 여러 복사본으로 인해 사용자 클릭이 분할되어 일관되지 않은 답변이 생성될 수 있습니다. 가능하다면 하나의 기본 버전을 유지하세요. 컨텍스트 누락 "저장을 클릭하세요"라는 청크는 페이지 이름이나 작업이 없으면 의미가 없을 수 있습니다. 주변 정보를 충분히 추가하세요. 혼합 언어 다국어 검색 시스템에는 언어 인식 임베딩, 별도의 색인 또는 언어 메타데이터가 필요할 수 있습니다. 지원되는 각 언어의 쿼리를 테스트합니다. 민감한 정보 액세스 규칙이 약한 경우 삽입 시스템이 비공개 콘텐츠를 노출할 수 있습니다. 사용자가 문서를 연 후가 아니라 결과를 반환하기 전에 권한을 적용하세요. 불명확한 실패 동작 일부 쿼리는 지식 베이스에 좋은 답변이 없습니다. 시스템은 느슨하게 관련된 페이지를 답변으로 제시하는 대신 신뢰할 수 있는 일치 항목을 찾을 수 없다고 말할 수 있어야 합니다. ## 유지 관리의 검색 피드백을 제품, 정책 및 사용자 언어 변경에 따라 검색 품질도 변경합니다. 나는 다음을 검토합니다. - 클릭이 없는 쿼리 - 반복적으로 재구성되는 쿼리 - 조회수는 많지만 만족도가 낮은 페이지 - 새로운 제품 용어 - 티켓이 자주 발생하는 지원 주제 - 참여도가 떨어지는 문서 사용자 피드백은 측정항목이 표시하지 않는 격차를 드러낼 수 있습니다. 사용자는 페이지를 찾아 읽고 핵심 조건이 누락되어 지원팀에 문의할 수 있습니다. 간단한 피드백 옵션으로 다음과 같은 질문을 할 수 있습니다. > 이 결과가 도움이 되었나요? 답변이 모든 문제를 설명하지는 않지만 쿼리 로그 및 콘텐츠 검토와 결합되면 팀에 유용한 신호를 제공합니다. ## 실용적인 작업 흐름 저는 명확한 작업 프로세스를 사용합니다. 1. 실제 검색어를 수집합니다. 2. 원본 문서를 정리하고 정리합니다. 3. 제목, 컨텍스트, 메타데이터를 추가합니다. 4. 여러 청크 접근 방식을 테스트합니다. 5. 승인된 콘텐츠에 대한 임베딩을 생성합니다. 6. 의미론적 및 키워드 검색을 설정합니다. 7. 권한 및 메타데이터 필터를 적용합니다. 8. 실제 사용자 질문을 통해 결과를 검토합니다. 9. 관련성, 결과 없는 쿼리 및 재구성을 추적합니다. 10. 콘텐츠를 업데이트하고 테스트를 반복합니다. 이 작업은 임베딩 모델 선택에만 국한되지 않습니다. 깨끗한 콘텐츠와 신중한 평가가 결합된 작은 모델은 잘못 구조화된 데이터에 연결된 큰 모델보다 사용자에게 더 나은 서비스를 제공할 수 있습니다. 더 나은 임베딩은 더 스마트한 결과를 지원할 수 있지만 전체 시스템이 중요합니다. 명확한 소스 콘텐츠, 적합한 청크, 유용한 메타데이터, 하이브리드 검색 및 정기적인 테스트는 사용자에게 질문에서 답변까지 더 나은 경로를 제공합니다.

많은 팀이 프롬프트를 변경하여 챗봇, 검색 도구 또는 추천 시스템을 개선합니다. 실제 문제는 종종 프로세스 초기에 발생합니다. 즉, 텍스트가 약한 임베딩으로 바뀌었습니다. 임베딩이 의미를 포착하지 못하면 관련 콘텐츠가 벡터 공간에서 멀리 떨어져 있게 됩니다. 사용자가 "개봉된 기기를 반품할 수 있나요?"라고 질문합니다. 두 페이지 모두 "반품"과 "기기"를 언급하기 때문에 시스템은 미개봉 제품에 대한 페이지를 검색합니다. 대답은 유창하게 들리지만 잘못된 소스를 기반으로 작성되었습니다. 이런 패턴을 자주 봅니다. 더 나은 임베딩 품질은 더 깨끗한 데이터, 적합한 모델, 실제 사용자 질문을 반영하는 테스트 프로세스에서 시작됩니다. ### 모델이 아닌 콘텐츠로 시작하세요. 강력한 임베딩 모델은 불분명하거나 잡음이 많은 텍스트를 복구할 수 없습니다. 기술 설정을 변경하기 전에 원본 자료를 검토합니다. 반복되는 탐색 메뉴, 깨진 HTML, 중복 페이지, 이전 정책 버전, 컨텍스트가 누락된 텍스트를 제거합니다. "이 수수료는 30일 후에 적용됩니다"와 같은 문장은 문서에 "이 수수료"가 무엇을 의미하는지 명시되어 있지 않으면 사용하기 어렵습니다. 또한 유용한 구조도 유지합니다. - 제품 이름 - 기능 라벨 - 섹션 제목 - 정책 날짜 - 고객 계획 이름 - 지역 또는 언어 정보 - 문서 버전 깨끗한 문서는 임베딩 모델에 각 구절의 의미를 나타내는 데 충분한 컨텍스트를 제공합니다. ### 벡터 크기를 늘리기 전에 청킹을 개선하세요. 청킹은 각 벡터가 전달하는 의미의 정도를 제어합니다. 너무 짧은 청크는 문장의 주어를 잃을 수도 있습니다. 너무 긴 청크에는 관련되지 않은 여러 주제가 포함될 수 있습니다. 두 경우 모두 검색 품질이 저하될 수 있습니다. 저는 습관적으로 하나를 선택하기보다는 여러 개의 청크 크기를 테스트하는 경우가 많습니다. 지원 지식 기반의 경우 150~400단어 정도가 시작점으로 적합할 수 있습니다. 기술 매뉴얼에는 절차가 이전 정의에 따라 다르기 때문에 더 큰 섹션이 필요할 수 있습니다. 유용한 청크 실행 방법은 다음과 같습니다. - 본문 텍스트와 함께 제목 유지 - 중간에 단계별 프로세스 생략 방지 - 각 관련 청크 내에 제품 이름 유지 - 컨텍스트가 여러 섹션에 걸쳐 계속될 때 작은 겹침 사용 - 모든 청크와 함께 문서 제목 및 섹션 경로 저장 청크는 하나의 명확한 질문에 답하거나 하나의 명확한 작업을 지원해야 합니다. 그러면 검색과 검토가 더 쉬워집니다. ### 모델을 언어 및 작업에 일치시킵니다. 임베딩 모델은 언어 범위, 입력 제한, 검색 동작 및 학습 데이터가 다릅니다. 영어 제품 페이지에서는 잘 작동하는 모델이 혼합 언어 지원 콘텐츠에서는 안정성이 떨어질 수 있습니다. 사용자가 실제로 묻는 질문과 모델을 비교합니다. 저는 일반적인 벤치마크 점수에만 의존하지 않습니다. 기본 테스트 세트의 경우 다음을 수집합니다. - 고객 메시지의 자연스러운 질문 - 짧은 키워드 검색 - 길고 상세한 질문 - 철자 오류가 있는 질문 - 제품 닉네임을 사용하는 질문 - 날짜 또는 지역별로 필터링이 필요한 질문 - 답변이 다른 유사한 질문 각 질문에는 신뢰할 수 있는 관련 구절이 필요합니다. 이를 통해 느낌으로 출력을 판단하는 대신 검색 결과를 비교할 수 있습니다. 유용한 측정에는 호출@k, 정밀도@k 및 평균 상호 순위가 포함됩니다. 상위 5개 결과에 올바른 구절이 나타나면 Recall@5는 해당 성공을 기록합니다. 관련 없는 구절이 결과 목록을 채우면 정밀도에 문제가 있음을 나타냅니다. ### 메타데이터에 의미 추가 벡터는 의미 있는 콘텐츠를 나타냅니다. 비즈니스 규칙을 완전히 나타내지 못할 수도 있습니다. 두 개의 문서가 동일한 기능을 설명한다고 가정합니다. 하나는 캐나다 고객에게 적용되고, 다른 하나는 영국 고객에게 적용됩니다. 그들의 텍스트는 매우 유사할 수 있습니다. 메타데이터로 이를 구분할 수 있습니다. 다음과 같은 필드를 첨부합니다. - 국가 - 언어 - 제품 - 고객 계획 - 출판 날짜 - 문서 상태 - 액세스 수준 - 콘텐츠 유형 검색 시스템은 벡터 검색 전후에 이러한 필드를 필터로 사용할 수 있습니다. 이렇게 하면 사용자가 잘못된 상품이나 정책 기간에 답변을 받을 가능성이 줄어듭니다. ### 의미론적 검색과 키워드 검색 결합 임베딩은 의미를 잘 처리합니다. 정확한 단어는 여전히 중요합니다. 사용자는 모델 번호, 오류 코드, 송장 ID 또는 법률 용어를 검색할 수 있습니다. 키워드 시스템은 벡터 검색 시스템보다 더 안정적으로 정확한 문자열을 일치시킬 수 있습니다. 많은 비즈니스 시스템에서 나는 하이브리드 접근 방식을 사용합니다. 1. 의미 유사성을 위해 벡터 검색을 실행합니다. 2. 정확히 일치하는 키워드 검색을 실행하세요. 3. 결과를 순위 지정 방법으로 병합합니다. 4. 제품, 언어, 날짜 또는 액세스에 대한 필터를 적용합니다. 5. 결과 집합을 더 자세히 비교해야 할 경우 순위 조정기를 사용하세요. 이 설정은 검색 시스템에 사용자가 의미하는 것과 사용자가 사용한 단어라는 두 가지 신호를 제공합니다. ### 어려운 쿼리를 의도적으로 테스트하기 쉬운 질문은 약한 시스템을 건강해 보이게 만들 수 있습니다. 실패를 일으킬 가능성이 가장 높은 사례를 포함하는 테스트 세트를 구축합니다. - 비슷한 표현이 포함된 두 개의 문서 - 동일한 정책의 이전 버전과 새 버전 - 철자가 비슷한 제품 이름 - 세부 정보가 누락된 질문 - 비공식 언어를 사용하는 질문 - 두 가지 주제를 결합한 질문 - 관련 답변이 없는 질문 소스에 신뢰할 수 있는 답변이 포함되어 있지 않으면 시스템은 일치를 강제해서는 안 됩니다. 나는 관련 없는 구절을 기반으로 한 자신감 있는 답변보다 “해당 요청에 대한 지원을 찾을 수 없습니다.”라는 명확한 답변을 선호합니다. ### 실제 검색 로그 검토 오프라인 테스트는 구조를 제공합니다. 사용자 행동은 테스트 세트가 놓친 내용을 보여줍니다. 나는 검색 결과를 검토합니다. - 클릭 없음 - 반복적인 재구성 - 긴 읽기 시간 - 낮은 평가의 답변 - 인력 지원으로의 에스컬레이션 - 잘못된 제품 영역의 결과 나와 협력한 한 지원 팀은 고객이 "구독 취소"를 검색한 반면 도움말 센터에서는 "서비스 계획 종료"를 사용한다는 사실을 발견했습니다. 임베딩 모델만이 유일한 문제는 아니었습니다. 고객이 거의 사용하지 않는 내부 언어를 사용하는 콘텐츠입니다. 콘텐츠와 메타데이터에 고객 용어를 추가하면 질문과 소스 페이지 간의 연결이 개선되었습니다. ### 작고 신중한 단계로 업그레이드 모델, 청크 크기, 필터 및 순위 지정 방법을 동시에 변경하면 결과를 설명하기가 어렵습니다. 테스트당 하나의 주요 요소를 변경합니다. - 소스 콘텐츠 정리 - 청크 경계 조정 - 두 임베딩 모델 비교 - 메타데이터 필터 추가 - 하이브리드 검색 추가 - 순위 조정기 테스트 - 실패 사례 검토 쿼리, 예상 소스, 검색된 결과 및 시스템 버전을 기록합니다. 간단한 스프레드시트로 초기 단계를 지원할 수 있습니다. 대규모 시스템에는 평가 파이프라인이 필요할 수 있습니다. 목표는 맥락 없이 점수를 쫓는 것이 아닙니다. 목표는 재시도 횟수와 수동 검토 횟수를 줄여 사용자가 올바른 정보를 찾을 수 있도록 돕는 것입니다. 꾸준한 점검을 통해 더 나은 임베딩 품질이 구축됩니다. 깨끗한 소스 텍스트는 모델에 더 명확한 의미를 제공합니다. 적합한 청크는 컨텍스트를 보존합니다. 메타데이터는 비즈니스 규칙을 보호합니다. 하이브리드 검색은 자연스러운 질문과 정확한 용어를 모두 지원합니다. 집중 테스트 세트는 시스템이 여전히 놓치고 있는 부분을 보여줍니다. 검색 결과가 신뢰할 수 없다고 느껴질 때 프롬프트를 다시 작성하는 것부터 시작하지 않습니다. 원본 문서에서 검색된 구절까지의 데이터 경로를 검사합니다. 이것이 바로 많은 품질 향상이 시작되는 곳입니다. 우리는 산업 분야에서 광범위한 경험을 가지고 있습니다. 전문적인 조언을 원하시면 저희에게 연락하세요: Hu Haifeng: 928464224@qq.com/WhatsApp +8613855932323.

1. Reimers Nils 및 Gurevych Iryna 2019 Siamese BERT 네트워크를 사용한 Sentence-BERT 문장 임베딩 2. Karpukhin Vladimir Oguz Barlas 외 2020 Dense Passage Retrieval for Open-Domain Question Answering 3. Gao Luyu Ma Xueguang Lin Jimmy Callan Jamie 2021 COIL 정보 검색에서 정확한 어휘 일치 재방문 상황별 반전 목록 사용 4. Khattab Omar 및 Zaharia Matei 2020 ColBERT BERT를 통한 상황별 후기 상호 작용을 통한 효율적이고 효과적인 구절 검색 5. Thakur Nandan Reimers Nils Daxenberger Johannes Gurevych Iryna 2021 바이 인코더 문장 임베딩 모델 개선을 위한 증강 SBERT 데이터 증강 방법 6. 형식 Thibault Piwowarski Benjamin Clinchant Stéphane 2021 1단계 순위를 위한 SPLADE 희소 어휘 및 확장 모델