💭 긴 텍스트 벡터화: 벡터화도 결국 사람처럼 "맥락"이 필요하다

https://honge1122.tistory.com/124

[나의 고민] 코드 짜고 나면 항상 찝찝해요

위 고민을 기록하고 나서 좋은 점:

회사에서 과업을 미리 끝냈을 때 바로 주석으로 달려가서(?) 리팩토링을 할 기회를 get 할 수 있다!!!

 

 

 

🧩 배경    

- 왜 이런 고민을 하게 되었는가? (팀 구조, 업무 환경 등)

팀에서 내가 맡은 과업 중 하나로, Azure OpenAI 기반으로 LLM 응답을 임베딩/검색 등을 처리하는 로직을 짜야한다.

당연한 말이지만 LLM(글 작성기준 gpt 4.1 사용 중)이 반환하는 텍스트 길이가 들쑥날쑥하고,

우리가 사용하는 임베딩 모델(large)은 최대 인풋토큰값이 8191이라 그거보다 많이 나온 텍스트는 청킹 해서 벡터화를 해주어야 한다.

어찌 보면 긴 텍스트 처리의 한계?를 발견한 셈인 거다.

 

 

 

💭 고민의 내용   

 

- 구체적으로 어떤 문제를 겪고 있는지
- 그로 인해 어떤 감정이나 제약이 생겼는지

 

임베딩 모델 스펙 상, 안전 마진을 남겨놓고 max_tokens=8000으로 잡았다.

근데 단순히 토큰 수 기준으로 잘라버리면 문맥이 끊겨서 검색/매칭 품질이 떨어질 것이다. 안 봐도 비디오다.

또 중간에 다른 팀원이 len(text)와 실제 토큰 수를 혼동하여 제대로 분할 기준을 잡지 못하는 상황도 발생했다.

 

즉, 우리는 토큰 수를 정확히 파악하여 max_tokens를 기준으로 토큰 제한 + 문맥 단절 방지

이 두 가지를 확실히 가져가야 한다.

 

 

🛠️ 해결을 위한 시도들

- 내가 해본 노력들 (구글링, 커뮤니티, 사이드 프로젝트 등)

1. 구글링, 공식문서 정독

LangChain에 SemanticChunker가 있더라.

SemanticChunker 내부 동작을 파악하며 RecursiveCharacterTextSplitter에

 

2. 커뮤니티/블로그 글 참고

공식 사이트를 본 뒤에, 커뮤니티/블로그 글을 참고했다.

create_documents와 split_text 메서드 차이를 이해하고 버전별 fallback 로직 구현을 시도하기로 결정.

 

3. 간단 test

이 배움을 다른 팀원에게 빠르게 공유하기 위해선 일단 간단한 검증이라도 하는 것이 예의!

max_tokens=80으로 낮춰서 실험하고, 실제 청킹/임베딩 동작을 디버깅했다.

 

3-1. SemanticChunker 사용: 청킹 전략 재정립

LangChain에 SemanticChunker가 있더라.

시맨틱청커로 의미 단위로 텍스트를 분할하고, 여전히 길면 RecursiveCharacterTextSplitter로 토큰 단위 분할하기.

최종적으론 모든 청크가 max_tokens 이하임을 보장하게 된다.

3-2. 기존 로직은 존중해야 한다!

의미 기반 분할은 LangChain의 힘을 빌리지만 최종 벡터화는 기존 로직을 타도록 했다.

dimension(3072) 등과 같은 세부 설정 세팅을 유지.

 

3-3. 토큰 수 카운트는?: 이것도 랭체인의 힘을 빌리자. tiktoken

len(text) 대신 tiktoken으로 토큰 수를 정확히 카운트하고 분기를 타게 해야 한다.

 

📈 변화  

- 그 과정에서 작게나마 달라진 점

 

max_tokens 초과 텍스트도 안정적으로 벡터화할 수 있게 됐다.

문맥이 끊기지 않고, 지속적인 테스트가 필요한 부분이지만 검색/매칭 품질도 개선될 것이라는 기대감을 확보해 놓은 상태.

 

아 그리고

Azure SDK와 LangChain 임베딩 객체의 역할을 명확히 구분할 수 있게 되었다. 쓸데없는 에러를 줄인 셈!

 

 

 

 

 📌 회고 & 다음 목표  

- 이번 경험을 통해 얻은 인사이트
- 앞으로 이런 방향으로 개선해보려 한다 등

 

1. 인사이트

• 임베딩은 단순 "토큰 자르기"가 아니라, 모델 제약 + 문맥 보존 + @ 를 함께 고려해야 품질이 나온다.
• 오픈 소스/라이브러리는 버전 차이가 심하니 fallback, 안전장치 넣는 게 중요!

2. 다음 목표

• chunk_size, overlap 같은 파라미터를 조정하여 실제 검색 정확도를 벤치마크 할 것.
• 의미 기반 청킹 + 토큰 기반 세부 분할을 표준 유틸 함수로 정리하여 팀에서 공통활용하도록 패키징.