피드로 돌아가기
Dev.toAI/ML
원문 읽기
소규모 데이터셋에서 SQL Vector 기반 Semantic Search가 Azure AI Search 대비 13% 빠른 응답 속도 달성
Building Hybrid Semantic Search in ASP.NET Core — SQL Vector, Azure AI Search, and the Bugs Between Them
AI 요약
Context
기존 ASP.NET Core MVC 레거시 환경과 Repository 패턴의 제약 속에서 Hybrid Semantic Search 구현 시도. 단순 튜토리얼과 달리 실제 운영 데이터의 품질 저하와 EF Core의 타입 매핑 한계라는 현실적 제약에 직면함.
Technical Solution
- 안정성 확보를 위한 Keyword Search 우선 실행 후 Semantic Search를 수행하는 순차적 시퀀싱 구조 설계
- EF Core의 float[] 미지원 문제를 MemoryMarshal을 이용해 byte[]로 변환하여 저장하고 런타임에 캐스팅하는 Two-Property Pattern 적용
- 임베딩 벡터의 변별력 확보를 위해 단순 텍스트가 아닌 {제목, 저자, 카테고리, 설명}을 조합한 고밀도 Seed Data 포맷 구축
- Repository 패턴의 수동 매핑 누락으로 인한 데이터 유실을 방지하기 위해 모델 변경 시 Update 메서드의 명시적 동기화 프로세스 적용
- 소규모 카탈로그 환경에서 네트워크 홉을 줄이기 위해 별도의 Search 서비스 대신 DB 내부 Cosine Similarity 계산 방식 채택
Impact
- SQL Vector 평균 응답 속도 584ms로 Azure AI Search의 671ms 대비 약 13% 성능 우위 기록
- 두 방식 간의 Top-1 결과 일치율 100%를 통해 소규모 규모에서의 In-process Cosine 구현 정밀도 검증
- 전체 응답 시간의 대부분(400~750ms)이 Azure OpenAI Embedding API 네트워크 지연에서 발생함을 식별
Key Takeaway
데이터 규모가 임계치(수십만 건)에 도달하기 전까지는 복잡한 ANN 인덱싱 서비스보다 단순한 Brute-force 스캔과 네트워크 홉 제거가 더 효율적인 아키텍처 결정임.
실천 포인트
1. AI 모델 도입 전 Seed Data의 컨텍스트 풍부도를 검토하여 벡터 변별력 확보 여부를 확인하십시오.
2. EF Core 사용 시 [NotMapped] 속성이 쿼리 필터(Where절)에서 무시됨을 인지하고 실제 매핑 컬럼을 기준으로 필터링하십시오.
3. 레거시 Repository 패턴의 수동 매핑 구조에서 신규 컬럼 추가 시 데이터 유실 가능성을 체크리스트에 포함하십시오.
4. 외부 검색 엔진 도입 전, 데이터 규모에 따른 Brute-force 계산 비용과 네트워크 왕복 비용(Round-trip)을 정량적으로 비교하십시오.