[LangChain RAG 구축 시리즈 Ep.06] 📝 텍스트 vs 구조형 데이터: 어떻게 임베딩할까?

이 글에서는 자연어 텍스트와 구조형 JSON 데이터를 임베딩할 때
어떻게 접근 방식이 달라야 하는지,
그리고 각각 어떤 방식으로 가공해야 검색 성능을 극대화할 수 있는지를 실습과 함께 알아보겠습니다.

---

🤖 임베딩은 텍스트 기반이다

우리가 사용하는 임베딩 모델 대부분은
텍스트의 의미를 숫자로 표현하는 것에 최적화돼 있습니다.

즉, 단순한 숫자 나열이나 키-값 구조보다는
사람이 이해할 수 있는 문장 구조를 더 잘 이해합니다.

---

🔍 구조형 데이터 vs 자연어 텍스트

항목	구조형(JSON 등)	자연어 텍스트
예시	{"name": "product", "type": "string"}	"product라는 이름의 문자열 컬럼"
임베딩 적합도	❌ 낮음	✅ 높음
추천 처리 방식	자연어로 가공 필요	그대로 사용 가능

---

🧪 실습: 같은 정보를 임베딩했을 때 차이 보기

from langchain.embeddings import OpenAIEmbeddings

embedding = OpenAIEmbeddings()

# 1. 구조형 데이터 그대로
structured_input = '{"name": "product", "type": "string"}'

# 2. 문장으로 가공
natural_input = 'product라는 이름의 컬럼이며, 타입은 string입니다.'

# 임베딩
vec1 = embedding.embed_query(structured_input)
vec2 = embedding.embed_query(natural_input)

➡️ 결과: 자연어 문장 형태의 벡터가 더 의미 중심의 임베딩으로 처리됨
➡️ 검색/질의에 훨씬 유리함

---

🧠 왜 자연어로 바꿔야 할까?

이유	설명
LLM 최적화	LLM은 자연어에 최적화되어 훈련됨
의미 인식	"type": "string"보다는 "문자열 타입"이 의미 전달이 명확
질문 대응	사용자 질문은 대부분 자연어 → 문서도 자연어가 적합

---

📄 예시: Iceberg metadata의 두 가지 표현 방식 비교

1) 구조형 JSON (원본)

{
  "schema": {
    "fields": [
      { "name": "product_name", "type": "string" }
    ]
  }
}

2) 자연어로 가공한 문서

🧾 테이블 컬럼:  
- product_name: 문자열(string) 타입

✅ 이 방식으로 가공해야 "상품 이름 컬럼이 있는 테이블은?" 같은 질문에 대응할 수 있습니다.

---

🛠️ 실습에서 자주 쓰이는 문장 템플릿

📂 테이블명: {{table_name}}  
🧾 컬럼 목록:  
- {{column_name}} ({{type}})  
🧩 파티션 기준: {{partition_column}}  

이런 형식으로 metadata.json을 정리하면 RAG에 가장 적합한 형태가 됩니다.

---

📎 요약 및 핵심 정리

• 구조형 JSON은 그대로 벡터화하면 검색 성능이 떨어집니다.
• 자연어 문장으로 가공하면 임베딩 품질이 획기적으로 개선됩니다.
• Iceberg의 메타데이터도 의미 중심 텍스트 문서로 정리해야 합니다.