비정형 문서 조건 매칭 — 데이터 정제 먼저 vs 매칭 프로토타입 먼저

Question

안녕하세요, 개발 중 의문점이 생겨서 글 올립니다. 저는 정부지원사업 공고를 창업자 조건에 맞춰 추천하는 시스템을 만들고 있습니다.배경창업자들이 자기한테 맞는 지원사업을 못 찾고 놓치는 문제를 풀어보려고 시작했습니다. 전문 개발자는 아니지만 파이썬으로 파이프라인은 직접 구축했습니다. 실행은 하는데 구조적인 실수를 하고 있는지 판단이 안 서서 조언 구합니다.현재 구조정부 오픈API 5곳에서 수집 (2만여 건, 매일 배치)제목 정규화로 반복 공고 통합 → 15,500개 사업6개 축으로 분류 (분야/창업단계/니즈/대상/산업/지역)공고 본문에서 지원자격 추출 ← 지금 여기창업자 프로필 입력축 대조해서 매칭·추천데이터를 제대로 정제·구조화한 다음 매칭하자는 접근입니다.막힌 지점제목만 파싱하다 보니 축 채움률이 고르지 않습니다.분야 81% / 니즈 71% / 지역 51%산업 24% / 대상 16% / 창업단계 11%"업력 3년 이내", "제조업 영위 기업" 같은 핵심 조건이 제목에 없고 본문에 있습니다. 그래서 본문 크롤링 후 LLM으로 추출하려는데:공고 URL이 기관마다 다른 사이트로 흩어져 있음일부는 SPA라 정적 크롤링 불가사이트 개편 시 파서 유지보수 부담그러다 근본적인 의문이 들었습니다. 데이터를 다 갖춘 뒤 매칭하는 게 맞는 순서인지, 아니면 매칭 프로토타입을 먼저 만들고 거기서 실제로 필요한 만큼만 역으로 정제하는 게 나았을지요.질문비정형 문서를 조건 매칭하는 서비스를 만들어보셨다면 어떤 순서로 접근하시겠어요?위 단계 중 뒤로 미뤄도 되는 것 / 빠뜨린 것이 있을까요?이질적인 사이트 다수를 크롤링해야 할 때 실무에서 유지보수가 감당되는 수준인가요? 아니면 임베딩 기반 유사도 검색 같은 다른 접근이 현실적일까요?아직 사용자 검증은 못 했습니다. 축 구조도 공고 데이터를 보고 역으로 설계한 것이라 그 부분 지적도 환영합니다.유사 도메인(채용공고 매칭, 논문 검색, 부동산 매물 등) 경험 있으시면 조언 부탁드립니다.

나눈궤똥붤레 · Accepted Answer

청약 및 임대 주택 관련 사이트 플젝하고 있습니다. 1. 모든 데이터를 완성한 뒤 시작하기보다는 일정량의 공고를 표본으로 수집해 프로토타입부터 만들겠습니다.분야,니즈 같은 항목은 신청 가능 여부보다는 관심도에 가까워 보입니다. 우선 업력, 지역, 사업자 유형, 대상, 포함/제외 업종 등 신청 자격에 직접 영향을 주는 조건부터 구조화하고 가상 사용자 프로필과 매칭해 보면서 필요한 항목을 확장하는 방식이 좋을 것 같습니다.2. 현재 빠진 부분은 신청 자격에 직접 영향을 주는 조건 데이터이고 뒤로 미뤄도 되는 부분은 전체 데이터의 완벽한 분류와 높은 축 채움률이라고 생각합니다.3. 사이트의 HTML 구조를 직접 따라가는 방식은 유지보수 부담이 큽니다. 최대한 Open API, 공고 첨부파일인 PDF/XLSX 또는 페이지 내부 JSON이나 XHR 응답을 우선 활용하는 편이 좋습니다.문서 데이터는 먼저 일반 파서와 규칙 기반 추출을 적용하고 처리하기 어려운 불규칙 문장만 LLM을 사용하는 것을 추천합니다. 문장과 서식이 일정한 공고라면 대부분 처음부터 LLM까지 사용할 필요는 없습니다.임베딩도 크롤링이나 조건 구조화를 대체하지는 못합니다. 유사 공고 검색, 관심 분야 추천, 중복 공고 탐지에는 유용하지만 업력 3년 이내, 제조업 제외, 서울 소재 본사만 가능 처럼 정확한 조건 판정에는 적합하지 않습니다.임베딩을 적용한다면 신청 자격은 구조화된 조건과 규칙으로 판정하고 관심도와 유사도 추천에는 임베딩을 사용하는 형태로 적용하시면 될 것 같습니다.전체 데이터를 완성하려 하지 말고 핵심 자격조건만 추출한 소규모 매칭 프로토타입으로 먼저 검증 후 확장 하시는걸 추천드립니다.아직 경험이 부족한 주니어라 도움이 되었을지 모르겠네요. 파이팅 입니다.

비정형 문서 조건 매칭 — 데이터 정제 먼저 vs 매칭 프로토타입 먼저

1개의 답변

Q&A 목록