LLM에게 일 시키기: HTML 테이블 파싱에서 시작된 삽질과 해답

🧩 배경

내가 맡은 일 요약 ver:

방대한 양의 HTML 웹 문서를 파싱 -> LLM을 통해 자연어 문장 만들기 -> 벡터화 -> 기타 작업 -> ai search에 적재하기

 

자세한 ver:

외부 데이터 HTML 웹 문서를 파싱하고 LLM을 활용해 자연어 문장으로 변환하는 로직을 담당하고 있다.

이 데이터는 Azure AI SEARCH에 적재된다.

적재된 데이터를 가지고 다양한 후속 RAG 및 연산(하이브리드 검색 등)을 거치게 될 것이다.

 

문제는 수많은 클라이언트가 작성한 문서들이라 눈으로 볼 땐 비슷해 보여도 실제 태그를 까보면 그 구조는 천차만별이라는 점이다.

이런 태그 난장판(?) 속에서 LLM이 이해할 수 있도록 데이터를 깔끔하게 정리하여 던저주는 선봉장 역할을 맡고 있다

 

LLM에 던지는 데이터는:

문서의 제목, 그리고 소제목(목차), 본문 text 내용, 본문 table(표) 내용 등

 

💭 고민의 내용

나를 고민의 늪에 빠뜨린 것은 바로 <table>

표는 가로/세로 헤더, 단일/다중 헤더, 병합 셀, 등등..

변수가 너무 많아서 초반에 문서 파싱 로직을 짤 때 테스트할 때마다 새로운 벽에 부딪혔었는데..

그 부딪힘은 아직 끝나지 않았나 보다. 

 

나에겐 복잡한 골칫덩어리지만 그만큼 입맛에 맞게 적절히 활용하기 좋으니 문서 작성자들은 표를 활용한 문서 작성 방법을 애용하는 것 같다.

그래서 표 처리를 아주아주 잘해주어야 한다!!(사용자들이 많이 쓰니까)

 

그동안 난 다음과 같은 고민의 늪을 지났다:

1. 고민: 테이블을 어떻게 하면 적절히 파싱 하여, LLM에 던질 수 있을까

2. 해결: CSV 형태로 변환하자

3. 고민 2: 쉼표 구분자 -> 데이터 완전엉망 

4. 해결 2: 파이프 구분자 사용('|')하면 괜찮지 않을까?

5. 고민 3: 다중 헤더일 경우, LLM 이 하위 헤더를 누락하여 자연어를 생성하는 문제 발생

6. 해결 3: '각 셀을 독립적인 문장으로 구성해 달라'라고 지시

 

현재 나의 고민

1. 딱딱하고 부자연스러운 답변

• 문장들이 뚝뚝 끊어지고 로봇처럼 딱딱하게 느껴짐

 

2. 데이터 유실 및 오류

• 다중 헤더가 있는 테이블, 헤더가 불분명한 테이블일 경우, LLM이 헤더를 제대로 인식하지 못하고 중요한 정보를 누락하는 문제 발생
• 특히 다음과 같은 테이블이 있을 경우: 

  구분	세부 내용
  	유효성분	효능/효과
  알약A	A-1	두통에 좋음
  	A-2	치통에 좋음
  알약B	B-1	효과별로없음

• 요약: "다음 셀은 구분, 세부내용, 세부내용이 있습니다. \n구분 세부 내용에 대해 유효성분과 효능/효과가 있습니다. \n 구분은 알약A 입니다. \n세부 내용에 대해 유효성분은 A-1 입니다. \n  세부 내용은 A-1은 두통에 좋음, A-2는 치통에 좋음 입니다. \n구분은 알약B입니다. .." 와 같이 의미 없는 답변으로 이어지기도 함

3. 컨텍스트 윈도우 한계

• 긴 문서의 경우, 모든 정보를 컨텍스트 윈도우에 담을 수 없어 중요한 맥락이 잘려나가 답변의 질이 떨어지는 문제 발생

 

이런 문제들로 인해, 단순히 전에 쓰던 것보다 최신 기술인 LLM을 도입하는 것만으로는 우리가 원하는 효과를 제대로 볼 수 없었고

원하는 결과물을 얻기 위해 계속해서 수작업으로 프롬프트를 수정해야 하는 제약과 답답함을 느꼈다.

 

 

🛠️ 해결을 위한 시도들

문제 해결을 위해 다음과 같은 방법들을 시도해 봤다:

 

1. 프롬프트 최적화

• 프롬프트 수정
  • '각 셀을 독립적인 문장으로' 대신 '자연스러운 자연어 문장을 작성해 달라'라고 지시
  • 역할 부여("당신은 HTML 파싱 된 문서를 자연어 문장으로 구성하는 문서 전문가입니다.")
  • LLM이 더 자연스러운 문체를 사용하도록 유도하고자 함
• key-value 쌍 변환
  • 테이블을 CSV 대신 k:v 형식으로 변환해서 전달해 봤으나 이는 기존 대비 성능이 떨어졌음.. 게다가 문서엔 변수가 많아서 k:v 방법을 도입하는 것은 다소 무리가 있다고 판단

2. 전처리 단계 개선

• 헤더 추출
  • 기존에 이미 병합셀 등을 파싱 하여 열의 개수를 맞춰주는 작업을 진행했지만 이만으로는 부족하다고 판단
  • 테이블의 헤더 행 개수를 파악하는 메서드 구현
  • 그리고 테이블을 표시하는 테이블마커(테이블을 표시하는 구분자를 우리 팀에선 마커라고 칭함)와 Header Cnt를 같이 LLM에 던짐
• *통합 헤더 사용(고려중)
  • 만일 앞 단계 만으로 효과를 보지 못할 경우, 다중 헤더를 나름의 규칙을 적용하여 조합해, 하나의 헤더로 만들어서 던지는 방법을 시도해보려고 함
  • 예를 들어 아래 테이블 1이 있을때(굵은글씨가 헤더), 테이블 2와 같은 형식으로 파싱한 CSV 데이터를 제공:

테이블1

구분	세부 내용
	유효성분	효능/효과
알약A	A-1	두통에 좋음
	A-2	치통에 좋음
알약B	B-1	효과별로없음

 

 

 

테이블2

구분	세부 내용 (유효성분)	세부 내용 (효능/효과)
알약A	A-1	두통에 좋음
	A-2	치통에 좋음
알약B	B-1	효과별로없음

 

 

3. LLM 활용 방식을 바꿔보자: CoT

• CoT 적용
  • LLM에게 다음을 요청:
    • 1. 테이블 헤더 분석 
    • 2. 분석 결과를 바탕으로 내용을 요약
  • 이중 프롬프트 전략 시도

Chain of Thought(CoT)

• 구글링 하다가 프롬프트 엔지니어링 기법 중 하나인 CoT를 발견했다
• CoT는 문제 해결의 중단 단계를 프롬프트로 제공하여 최종 응답 도출을 돕는 프롬프팅 기법
• 추론의 reasoning path를 제공하는 것이 CoT의 핵심이다

자세한 내용은 새로 포스팅하는 게 낫겠다..

 

 

📈 변화

이런 노력들 덕분에 LLM 응답이 눈에 띄게 개선되었다:

1. 더 이상 딱딱한 문장이 아닌 사람의 글처럼 자연스러운 서술형 답변을 얻을 수 있게 되었다!

해결의 개념이 아니라, 장기적으로 다양한 시도를 통해 더 나은 응답을 얻을 수 있도록 노력해야 하는 부분이라고 생각한다.

하지만 전에 비해 훨씬 자연스러워져서 1차적으로 만족하고 있다.

"다음 셀은 구분, 세부내용, 세부내용이 있습니다. \n구분 세부 내용에 대해 유효성분과 효능/효과가 있습니다. \n 구분은 알약A 입니다. \n세부 내용에 대해 유효성분은 A-1 입니다. \n  세부 내용은 A-1은 두통에 좋음, A-2는 치통에 좋음 입니다. \n구분은 알약B입니다. .."  에서,

 

"구분은 알약A 이고, 유효성분은 A-1, 효능과 효과에 대해 두통에 효과가 있다고 알려져 있습니다. \n.."식으로 보다 매끄럽게 연결된 것을 확인할 수 있었다!

2. 헤더의 누락, 데이터 오류가 현저히 줄어들어, LLM이 테이블 내용을 훨씬 더 정확하게 요약하고 설명할 수 있도록 했다!

후속 RAG 담당자들로부터 요약 내용이 누락됐다는 요청 메일을 클릭하는 행위로부터 벗어날 수 있게 되었다!

3. 다양한 구조의 HTML 문서를 범용적으로 처리할 수 있는 프롬프트를 만들 수 있어 기뻤고, 수작업의 지옥으로부터 조금이나마 벗어날 수 있게 되었다!!(가장중요)

 

 

📌 회고 & 다음 목표

이번 경험을 통해 LLM은 지능형 검색 엔진이 아니라, 지시사항에 충실한 업무 파트너라는 것을 피부로 느꼈다.

나는 그동안 LLM을 대충 입력해도 알아서 척척 결과를 내놓는 검색 엔진처럼 대해왔던 것 같다. 그럼.. 잘 안 될 수밖에.

 

LLM으로부터 좋은 결과물을 얻기 위해서는 모델이 가장 이해하기 좋은 형태로 데이터를 가공해서 던져주는 것, 명확한 지시를 내리는 것이 중요하다는 것을 다시금 배웠다.

 

1. 마크다운 형식 변환

혹시나 나중에라도 다시 똑같은 문제에서 막힌다면

테이블을 CSV가 아닌 마크다운 형식으로 변환하여 전달하는 방법을 시도해 보고자 한다.

물론 말이 쉽지 실행이...

말만 쉽다.

구글링 하다가 LLM이 마크다운을 잘 이해할 수 있다는 사실을 줍줍했는데 이 방법을 통해 성능을 더욱 끌어올릴 수 있는지 테스트해 보는 것도 괜찮을 것 같다

 

 2. RAG 성능 개선

담당자로서 끊임없이 안고 가야 할 과제.

특히 컨텍스트 윈도우를 최대한 효율적으로 활용하는 방법을 더 연구해야 한다.

추가로 크기가 있는 문서들을 대상으로  요약, 임베딩 등 작업을 수행하다 보니 적재 속도가 느려져서 이 부분도 해결할 수 있으면 최대한 해결하는 것이 좋을 것 같다.

그래서 LLM에 들어가는 입력값의 양을 조절하는 것이 필요하다는 결론을 내렸다.