💡 개발하며 마주한 문제들 & 해결 과정

---

🧩 1. 벡터 DB 최적화 - Chunk Size & Overlap 설정 실험

---

🛑 문제 상황

• 문서를 벡터화해서 FAISS에 저장할 때,
  → 청크 크기(Chunk Size)와 오버랩 크기(Overlap Size)를 어떻게 설정해야 하는지 고민
• 너무 크면 검색이 느려지고,
• 너무 작으면 문맥이 사라져 엉뚱한 문서가 검색됨.
• 이 문제를 해결하기 위해 다양한 청크 및 오버랩 크기로 테스트 진행!

---

✅ 해결 방법 - 실험을 통한 최적의 Chunk Size 찾기

📌 LangChain의 RecursiveCharacterTextSplitter를 사용하여 여러 조합 테스트

test_cases = [
    {"chunk_size": 200, "chunk_overlap": 50, "title": "Test Doc Case 1", "db_path": "test_faiss_db_case1"},
    {"chunk_size": 300, "chunk_overlap": 100, "title": "Test Doc Case 2", "db_path": "test_faiss_db_case2"},
    {"chunk_size": 500, "chunk_overlap": 200, "title": "Test Doc Case 3", "db_path": "test_faiss_db_case3"},
    {"chunk_size": 400, "chunk_overlap": 150, "title": "Test Doc Case 4", "db_path": "test_faiss_db_case4"},
]

💡 실험 과정
1. 각 케이스별로 문서를 임베딩하여 FAISS DB에 저장.
2. 동일한 질문을 입력하고, LangChain의 similarity_search_with_score를 사용해 검색된 문서의 유사도 점수 비교.
3. 검색된 문서가 원래 질문과 얼마나 관련이 있는지 정성적으로 분석.

💡 테스트 결과

Chuck Size	Overlap	검색 정확도	검색 속도	문맥 유지
200	50	❌ 낮음	✅ 빠름	❌ 문맥 끊김
300	100	✅ 높음	✅ 빠름	✅ 문맥 유지
400	150	⭕ 보통	⭕ 중간	✅ 문맥 유지
500	200	✅ 높음	❌ 느림	✅ 문맥 유지

📌 결과적으로, chunk_size=300, chunk_overlap=100이 가장 최적의 값임을 발견!

---

🔥 실험 후 느낀 점 & 검색 성능 개선 효과

✅ Chunk Size & Overlap이 검색 성능에 얼마나 중요한지 뼈저리게 깨달음.
✅ 처음에는 500, 200이 좋아 보였지만, 속도가 너무 느려 실사용에 부적합.
✅ 최적의 300, 100 설정 후, 검색 성능이 대폭 개선됨 → 정확도 상승 + 빠른 검색 속도 확보!

💡 이 실험을 통해 얻은 인사이트

• 너무 작은 청크는 문맥을 잃게 만들고, 너무 큰 청크는 검색 성능을 저하시킨다.
• Chunk Size와 Overlap은 도메인과 데이터 특성에 맞게 실험을 통해 최적값을 찾아야 한다.
• 단순히 top-k 검색이 아니라, 적절한 청크 사이즈 조정이 LLM 응답 품질에도 큰 영향을 준다.

---

📌 배운 점

✅ 임베딩을 할 때 적절한 Chunk Size를 선택하는 것이 검색 성능의 핵심이다!
✅ 검색 성능을 높이기 위해 무조건 큰 청크를 선택하는 것이 정답이 아니다.
✅ 실제 데이터셋에 맞는 최적의 설정을 찾기 위해서는 여러 테스트 케이스를 만들어 실험하는 과정이 필수다.
✅ LangChain의 similarity_search_with_score는 검색된 문서의 연관성을 확인하는 데 매우 유용하다.

---

🛠️ 2. Retriever 최적화 - 문서 적합도 필터링 & 최적 검색 전략

---

🛑 문제 상황

• 기존 Retriever 로직에서는 관련된 문서 10개를 검색하여 모두 참고.
• 하지만, 관련성이 낮은 문서도 포함되면서 LLM 응답의 품질이 저하됨.
• 🔍 문제점: 의미 없는 문서까지 포함되면서 불필요한 정보로 인해 부정확한 답변이 생성됨.

---

✅ 해결 방법 - 검색된 문서의 적합도 필터링

1) 문서 적합도 판단 로직 추가
💡 적용한 최적화 기법
1️⃣ 검색된 문서들의 score 값을 평균 내고, 최고점과 비교.
2️⃣ 최소 3개의 문서가 참고되도록 설정하고,

• 상위 30% 이상의 문서를 1순위로 참고.
• 나머지 문서 중, 평균보다 현저히 낮은 문서는 필터링.
  3️⃣ 평균 이상의 점수를 가진 문서를 우선적으로 참고하여 응답 생성.

def filter_documents(documents, min_docs=3, top_percentile=0.3):
    # 문서들의 점수를 정렬
    documents.sort(key=lambda x: x["score"], reverse=True)
    
    # 최고점과 평균 점수 계산
    max_score = documents[0]["score"]
    avg_score = sum([doc["score"] for doc in documents]) / len(documents)

    # 상위 30% 문서를 우선 선정
    top_n = max(int(len(documents) * top_percentile), min_docs)
    selected_docs = [doc for doc in documents[:top_n]]

    # 평균보다 낮은 점수를 가진 문서 필터링
    final_docs = [doc for doc in selected_docs if doc["score"] >= avg_score]

    return final_docs

📌 결과적으로, 의미 있는 문서만 필터링하여 LLM이 보다 정확한 답변을 생성하도록 개선!

---

🛠️ 실험 방법 & 최적화 과정

📌 벡터 DB는 직접 확인할 수 없어서 테스트 신뢰도를 확보하는 것이 중요했다.
💡 테스트 방법:
1️⃣ 웹 문서를 임베딩한 후, 세부적인 질문을 입력하여 관련 문서 검색 테스트.
2️⃣ 검색된 문서들이 어떻게 선택되는지 로그를 찍어 확인하며 최적화 진행.
3️⃣ 여러 Threshold 설정을 실험하여, 적합한 문서 필터링 기준을 찾음.

📌 실험 데이터 예시 (로그 분석 결과)

문서	Score	참고 여부
문서 A	0.92	✅ 사용
문서 B	0.88	✅ 사용
문서 C	0.85	✅ 사용
문서 D	0.72	❌ 필터링됨 (평균 이하)
문서 E	0.70	❌ 필터링됨 (평균 이하)

📌 결과:

• LLM이 보다 적절한 문서만 참고하도록 개선되면서 응답 품질 향상!
• 불필요한 문서를 제거하여 응답 속도도 최적화됨.

---

🔥 실험 후 느낀 점 & 최적화 과정에서의 고민

✅ 벡터 DB는 직접 보이지 않으므로, 로그를 찍어 확인하는 과정이 필수적이다.
✅ 수학적인 접근이 중요하다 – Score 기반 필터링 로직을 적용하면서 적절한 기준을 찾는 것이 핵심이었다.
✅ Threshold 설정은 단순한 정적 값이 아니라, 동적으로 조절될 필요가 있다.
✅ 최적화 과정은 지속적으로 이루어졌으며, 데모 때까지 고민이 이어졌다.
✅ 결과적으로 데모에는 반영되지 못했지만, AI 검색 최적화에 대한 깊은 고민을 경험할 수 있었다.

---

📌 최종 정리 (TL;DR)

• 기존 Retriever는 관련성이 낮은 문서까지 포함하는 문제가 있었음.
• Score를 기반으로 문서 필터링 로직을 추가하여 불필요한 문서를 제거.
• 상위 30% 문서를 우선적으로 참고하고, 평균 이하 점수를 가진 문서는 필터링.
• 실험을 통해 검색된 문서를 로그로 분석하며 최적화 진행.
• 🚀 LLM의 응답 품질 & 검색 성능이 크게 향상됨!

---

🎯 3. 프롬프트 엔지니어링 최적화 - AI 응답 품질 향상 실험

---

🛑 문제 상황

• 기존 프롬프트에서는 사용자의 대화 맥락을 유지하고, 지속적인 문맥을 제공하도록 설정했음.
• 하지만, 예상과 다르게 챗봇이 가끔 이상한 답을 하거나 맥락을 유지하지 못하는 문제 발생.
• 💡 문제의 원인:
  1. 프롬프트가 너무 일반적이어서 LLM이 정확한 답변을 생성하는 데 어려움을 겪음.
  2. 지나치게 자유로운 응답 스타일 → 가이드라인이 부족하여 AI의 응답 품질이 일정하지 않음.
  3. 대화 맥락 유지 실패 → 과거의 10개 대화를 기억해야 하지만, 효과적으로 활용되지 않음.

---

✅ 해결 방법 - 프롬프트 개선 및 실험 과정

💡 개선 방향
1️⃣ AI의 역할을 더 명확하게 정의

• 기존: "You are a company service chatbot."
• 개선 후: "You are a friendly and knowledgeable company service assistant chatbot."
• → AI의 목표와 성격을 구체적으로 정의하여 일관된 응답을 유도.

2️⃣ 대화 흐름을 제어할 수 있도록 지침 추가

• 단순히 문서 기반으로 답변을 생성하라고 요청하는 것만으로는 부족했음.
• 각 상황별로 AI가 어떻게 반응해야 하는지 세부적으로 지침을 추가!
• ✅ 사용자의 질문이 문서에 있는 정보와 일치하면 정확한 답변 제공.
• ✅ 정보가 없을 경우, 적절한 피드백 제공 ("I'm sorry, I couldn’t find that information…").
• ✅ 불필요한 인사말 방지 및 문장의 톤 조절 (친절하지만 간결하게).

3️⃣ 프롬프트 내부에 대화 기억 유지 로직 반영

• 기존 프롬프트: "Retain at least 10 message logs."
• 개선 후: "Directly answer user questions based on the content from the official documents and the last 10 interactions."
• → AI가 대화 기록을 어떻게 활용해야 하는지 명확하게 설명하여 문맥 유지 강화!

---

🛠️ 실험 과정 & 비교 테스트

📌 프롬프트 실험을 위한 평가 방법

• 동일한 질문을 여러 번 입력하고, 개선 전/후 응답을 비교.
• AI가 문맥을 유지하는 정도, 정확한 정보를 제공하는지, 답변 스타일이 일관적인지 테스트.

📌 테스트 결과 비교

테스트	기존 프롬프트 응답	개선된 프롬프트 응답	결과
사용자의 이름을 기억하는지	"Hello! How can I help?" (기억 안함)	"Sure, Gahee! What would you like to know?" (이름 기억)	✅ 개선됨
정보가 없을 때 반응	"I'm not sure." (짧고 불친절)	"I’m sorry, I couldn’t find that information in the documents I have. I recommend reaching out to the support team." (친절하고 안내 제공)	✅ 개선됨
연속된 질문에 대한 문맥 유지	"Can you clarify?" (문맥 이해 부족)	"Based on your last question about [topic], here’s more information…" (문맥 유지 O)	✅ 개선됨
응답의 전문성 & 간결함	"Sure! Here's a long explanation…" (장황함)	"Here's a concise summary: [정보]. Let me know if you need more details!" (간결 & 명확)	✅ 개선됨

📌 결과적으로 개선된 프롬프트를 적용했을 때:

• ✅ AI의 일관성 있는 응답 품질 확보!
• ✅ 사용자의 이름 & 맥락 유지 성공적으로 반영!
• ✅ 정보가 없을 때도 더 친절하고 유용한 안내 제공!

---

🔥 프롬프트 최적화 후 배운 점 & 느낀 점

✅ AI에게 역할과 목표를 명확하게 정의해줘야 한다.
✅ "어떤 상황에서 어떤 방식으로 답해야 하는지" 구체적으로 명시하면 AI의 응답 품질이 좋아진다.
✅ LLM이 단순히 대화 맥락을 기억한다고 해서 좋은 답변을 생성하는 것은 아니다! → 프롬프트에서 맥락을 어떻게 활용할지 구체적으로 설명해야 한다.
✅ 이론적으로 괜찮아 보이는 프롬프트도 실전 테스트가 필수다!

---

📌 최종 정리 (TL;DR)

• 기존 프롬프트에서는 AI의 응답이 비일관적이고 맥락을 유지하지 못하는 문제가 있었음.
• 역할 정의 + 대화 가이드 + 문맥 활용 방식을 명확히 지시하여 프롬프트 개선.
• 테스트를 통해 응답 품질이 크게 향상됨 → 맥락 유지, 응답의 일관성, 친절한 피드백까지 모두 개선!
• 🚀 이제 프롬프트 엔지니어링이 얼마나 중요한지 직접 경험하게 됨.

---

🎯 4. 프롬프트 엔지니어링 최적화 - 문서 기반 응답 & 일상 대화 처리 개선

---

🛑 문제 상황

1️⃣ 기존 프롬프트에서는 회사 문서와 관련된 질문이 아니면 AI가 무조건 거절 응답을 함.

• "죄송합니다, 관련한 질문이 아닙니다." 같은 고정된 답변만 제공 → 대화의 유연성이 부족.
• 사용자가 일상적인 질문을 하면 AI가 너무 딱딱하게 반응함.

2️⃣ 정보 제공 시 출처(Reference)가 포함되지 않아 신뢰성 부족.

• AI가 회사 문서에서 정보를 기반으로 답변을 생성하지만, 어디서 가져온 정보인지 밝히지 않음.
• 사용자가 AI의 응답을 신뢰할 수 있도록 출처(참고 문헌)를 표시할 필요가 있음.

---

✅ 해결 방법 - 프롬프트 개선 및 실험 과정

1) 일상적인 대화도 가능하도록 프롬프트 개선

💡 기존:

• "You are a company service chatbot. If the user's question is not related to company documents, say you cannot answer."
• → 비관련 질문이면 무조건 거절.

💡 개선 후:

• "You are a friendly and knowledgeable company assistant chatbot. You can engage in casual conversations when the user's question is not related to company documents. If the question is related to official documents, provide an accurate response based on the given sources."
• → 이제 AI가 일상 대화도 자연스럽게 할 수 있도록 유연한 응답 생성 가능!

📌 추가된 프롬프트 규칙:
✅ 일상적인 질문 (Casual Conversation) → AI가 부드럽게 대화 가능.
✅ 문서 기반 정보 (Informational Response) → 공식 문서 참고하여 응답 생성.

2) AI가 응답 유형을 자동으로 판단하도록 엔지니어링

💡 새로운 프롬프트 규칙 추가:

• AI가 응답을 생성할 때, 스스로 답변이 casual인지 informational인지 분류하도록 설계.
• Informational 응답일 경우, 참고한 문헌(출처)을 응답에 포함.

📌 프롬프트 개선 내용:

You are a friendly and knowledgeable company service assistant chatbot designed to provide accurate information and support.

1. If the user asks about official company documents, provide a fact-based response and cite the reference documents used.
   - Example: "Based on [Document Name], here is the information: ..."
2. If the question is casual or unrelated to company documents, engage in a friendly and natural conversation.
3. You must classify your response as either "informational" or "casual":
   - If "informational", append the referenced documents at the end of your response.
   - If "casual", simply respond naturally without citing references.

📌 예제 응답 비교 (개선 전 vs 후)

질문	기존 응답	개선된 응답
"점심 뭐 먹었어?"	"죄송합니다, 관련한 질문이 아닙니다."	"오늘 점심 메뉴 추천해드릴까요? 😊"
"우리 회사의 연차 사용 규정이 뭐야?"	"우리 회사의 연차 규정은 다음과 같습니다..."	"📌 출처: Employee Handbook 2023 \n 연차 규정은 다음과 같습니다..."
"나의 근무 시간은 몇 시부터 몇 시까지야?"	"죄송합니다, 관련한 질문이 아닙니다."	"근무 시간은 9AM - 6PM입니다. (📌 출처: HR Policy 2024)"

📌 결과:
✅ AI가 문맥을 파악하여 유연하게 응답할 수 있게 됨!
✅ 회사 문서 기반 응답에서는 자동으로 참고 문헌을 추가하여 신뢰성 확보!

---

🛠️ 실험 과정 & 최적화 전략

📌 테스트 방법
1️⃣ 일상적인 질문을 입력하여 AI가 자연스럽게 응답하는지 확인.
2️⃣ 정보 기반 질문을 입력하고, 출처(Reference)가 포함되는지 테스트.
3️⃣ 잘못된 응답이 나오지 않도록 프롬프트를 조정하며 최적화.

📌 실제 실험 결과 분석 (로그 기반 테스트 진행)

질문 유형	AI 응답 (개선 전)	AI 응답 (개선 후)	개선 여부
일상 대화	"죄송합니다, 관련한 질문이 아닙니다."	"좋은 질문이네요! 어떤 점이 궁금하신가요?"	✅ 자연스러운 대화 가능
회사 규정 질문	"여기 문서를 참고하세요." (출처 없음)	"📌 출처: Company Handbook 2024 \n 여기 문서를 참고하세요."	✅ 신뢰성 향상
비즈니스 관련 질문	"이 정보는 없습니다."	"제가 찾을 수 있는 정보가 없지만, HR 팀에 문의해보는 것을 추천합니다."	✅ 친절한 가이드 추가

📌 결과:

• ✅ AI의 응답이 더 자연스럽고 친절하게 개선됨.
• ✅ LLM이 응답 유형을 분류하여 문서 기반 정보에는 출처를 추가하도록 최적화됨.
• ✅ 사용자가 AI 응답을 더 신뢰할 수 있도록 설계.

---

🔥 프롬프트 최적화 후 배운 점 & 느낀 점

✅ 프롬프트에서 AI의 "역할"을 더 구체적으로 정의하면 응답 품질이 향상된다!
✅ 응답 유형(Classification)을 명확하게 지시하면 AI가 상황에 맞게 더 자연스럽게 동작한다.
✅ 출처를 포함하는 것만으로도 사용자가 AI의 응답을 더 신뢰할 수 있게 된다.
✅ AI가 너무 딱딱하면 사용자 경험이 떨어지므로, "Casual"한 대화 기능도 중요하다!
✅ 프롬프트는 한 번 만들고 끝나는 게 아니라, 지속적으로 실험하고 개선해야 한다.

---

📌 최종 정리 (TL;DR)

• 기존 챗봇은 일상 대화가 불가능하고, 문서 기반 응답에 출처가 포함되지 않는 문제가 있었음.
• ✅ 프롬프트 개선:
  • 🎯 Casual 대화 가능하도록 유연성 추가.
  • 📌 Informational 응답 시 출처(Reference) 포함하도록 설정.
  • 🛠️ AI가 응답 유형을 스스로 분류하여 자연스러운 대화 흐름 유지.
• 🚀 결과:
  • 사용자 경험 개선 (더 자연스러운 응답 가능!)
  • 정보의 신뢰성 향상 (출처 포함!)
  • AI의 일관된 응답 품질 확보!

---

🛠️ 5. 문서 크롤링 & 벡터 DB 저장 - 데이터 구조 최적화

---

🛑 문제 상황

1️⃣ 기존에는 단순히 텍스트만 벡터 DB에 저장하는 방식

• 문서를 크롤링한 후, text만 벡터화하여 FAISS에 저장.
• 출처(title) 정보가 없어서, 어떤 문서에서 가져온 데이터인지 구분할 수 없었음.

2️⃣ 삭제 및 관리 기능이 어려움

• 벡터 DB는 일반적인 관계형 DB와 달리 ID 기반 삭제 기능이 제한적.
• 기존 방식에서는 특정 문서를 벡터 DB에서 삭제하려면 텍스트 데이터를 다시 처리해야 하는 문제가 있었음.

3️⃣ AI 응답 생성 시 참고 문헌 정보 제공 필요

• AI가 검색된 문서에서 응답을 생성할 때, 어떤 문서를 참고했는지 출처(title)를 포함해야 했음.
• 하지만 기존 방식에서는 벡터 DB에서 검색된 텍스트만 반환 → 출처(title)를 활용할 방법이 없었음.

---

✅ 해결 방법 - Document 기반 데이터 저장 구조 도입

💡 1) 벡터 DB에 저장하는 데이터 구조 개선
📌 텍스트뿐만 아니라, 문서의 출처(title) 및 메타데이터를 함께 저장!

from langchain.schema import Document

# 기존 방식 (단순 텍스트 저장)
text = "This is a sample document about AI."
faiss.add_texts([text])

# 개선된 방식 (문서 정보 + 메타데이터 포함)
document = Document(
    page_content="This is a sample document about AI.",
    metadata={
        "title": "AI Research Paper 2023",
        "source": "https://example.com/ai-research",
    }
)
faiss.add_documents([document])

📌 결과:
✅ 벡터 DB에서 검색된 문서의 출처(title)까지 함께 반환 가능!
✅ 문서의 출처를 기준으로 데이터 관리(삭제, 업데이트)가 가능해짐.

💡 2) 문서 ID 기반 삭제 기능 추가
📌 벡터 DB에서 특정 문서를 삭제할 수 있도록 title을 ID처럼 활용

# 벡터 DB에서 특정 문서 삭제
def delete_document_by_title(faiss, title):
    docs = faiss.similarity_search_with_score(title, k=10)  
    for doc, score in docs:
        if doc.metadata.get("title") == title:
            faiss.delete(doc)  # 특정 문서만 삭제

📌 결과:
✅ 불필요한 문서를 손쉽게 삭제할 수 있는 기능 추가!
✅ 벡터 DB에서 데이터 관리를 효율적으로 할 수 있게 됨.

💡 3) AI가 참고 문헌을 자동으로 포함할 수 있도록 데이터 구조 정리

• AI가 응답을 생성할 때, 프롬프트 엔지니어링을 통해 informational 응답일 경우 출처(title)를 포함하도록 설정.
• 나는 벡터 DB에서 검색된 문서의 메타데이터(title, source)를 LLM에 넘겨주는 역할을 수행.
• AI가 이를 활용하여 응답을 생성할 수 있도록 데이터 구조를 개선함.

📌 결과:
✅ 내가 직접 응답에 출처를 추가하지 않아도, 프롬프트를 통해 AI가 자동으로 처리하도록 설계!
✅ 정보 제공이 필요한 경우 참고 문헌이 포함되면서 신뢰도 향상.

---

🛠️ 벡터 DB 데이터 구조 개선 후 얻은 이점

📌 데이터 관리가 쉬워짐!

• ✅ 문서 삭제 기능 추가 → 필요 없는 데이터를 손쉽게 제거 가능.
• ✅ 벡터 DB에서 특정 문서를 ID 기반으로 검색 가능.

📌 AI 응답의 신뢰성 향상!

• ✅ AI가 문서 기반 정보를 보다 신뢰성 있게 제공할 수 있도록 설계.
• ✅ 데이터 구조를 개선하면서 프롬프트 엔지니어링과의 연계를 고려할 수 있었음.

📌 데이터 구조를 개선하면서 시스템 설계에 대한 깊은 고민을 할 수 있었음!

---

🔥 데이터 구조 최적화 후 배운 점 & 느낀 점

✅ 텍스트만 저장하는 것이 아니라, 메타데이터까지 고려해야 데이터 관리가 쉬워진다.
✅ 벡터 DB는 관계형 DB와 다르게 ID 기반 삭제가 어렵기 때문에, ID처럼 사용할 필드를 포함하는 것이 중요하다.
✅ AI의 응답 신뢰성을 높이기 위해서는 참고 문헌(title)을 함께 제공할 수 있도록 데이터 구조를 정리해야 한다.
✅ 데이터 구조를 고민하는 과정이 결국 전체적인 검색 & 응답 품질 개선으로 이어진다!

---

📌 최종 정리 (TL;DR)

• 기존에는 텍스트만 벡터 DB에 저장했기 때문에 문서 관리 및 출처 제공이 어려움.
• ✅ 벡터 DB에 문서 title, 출처 정보를 함께 저장하여 데이터 구조 개선.
• ✅ title을 기준으로 문서를 삭제할 수 있도록 기능 추가.
• ✅ AI 응답 생성 시 참고 문헌을 포함할 수 있도록 메타데이터 정리.
• 🚀 결과적으로 문서 검색 시스템의 관리 & 응답 품질이 크게 향상됨!

---