이전 글에서 우리는 청킹의 과제들을 살펴보고 Late Chunking의 개념을 소개했습니다. 이는 청크를 임베딩할 때 문맥 손실을 줄이는 데 도움이 됩니다. 이번 글에서는 또 다른 과제인 최적의 분할점 찾기에 초점을 맞추겠습니다. 우리의 Late Chunking 전략이 좋지 않은 경계에도 매우 견고한 것으로 입증되었지만, 이는 경계를 무시해도 된다는 의미는 아닙니다—여전히 사람과 LLM의 가독성 모두에 있어 중요합니다. 우리의 관점은 다음과 같습니다: 분할점을 결정할 때 이제 의미론적 또는 문맥 손실을 걱정하지 않고 가독성에만 완전히 집중할 수 있습니다. Late Chunking은 좋은 분할점과 나쁜 분할점 모두를 처리할 수 있으므로, 가독성이 주요 고려사항이 됩니다.
이를 염두에 두고, 우리는 의미론적 일관성을 유지하면서 복잡한 콘텐츠 구조를 처리할 수 있도록 특별히 설계된 세 가지 소형 언어 모델을 훈련시켰습니다. 그것들은 다음과 같습니다:
simple-qwen-0.5, 문서의 구조적 요소를 기반으로 텍스트를 분할합니다.
topic-qwen-0.5, 텍스트 내의 주제를 기반으로 텍스트를 분할합니다.
summary-qwen-0.5, 각 세그먼트에 대한 요약을 생성합니다.
이 글에서는 우리가 이 모델을 개발한 이유, 세 가지 변형을 어떻게 접근했는지, 그리고 Jina AI의 Segmenter API와 비교하여 어떻게 벤치마크되는지 논의할 것입니다. 마지막으로, 우리가 배운 것과 미래에 대한 생각을 공유하겠습니다.
tag세분화 문제
세분화는 RAG 시스템의 핵심 요소입니다. 긴 문서를 일관된, 관리 가능한 세그먼트로 나누는 방식은 답변 관련성에서 요약 품질에 이르기까지 검색과 생성 단계 모두의 품질에 직접적인 영향을 미칩니다. 전통적인 세분화 방법은 괜찮은 결과를 냈지만 한계가 없지는 않았습니다.
이전 글을 인용하면:
긴 문서를 세분화할 때 주요 과제는 세그먼트를 어디서 만들지 결정하는 것입니다. 이는 고정된 토큰 길이, 정해진 문장 수, 또는 정규식과 의미론적 세분화 모델과 같은 더 고급 방법을 사용하여 수행될 수 있습니다. 정확한 세그먼트 경계를 설정하는 것이 중요한데, 이는 검색 결과의 가독성을 향상시킬 뿐만 아니라 RAG 시스템의 LLM에 제공되는 세그먼트가 정확하고 충분한지 확인하는 데 중요합니다.
Late Chunking이 검색 성능을 향상시키지만, RAG 애플리케이션에서는 가능한 한 모든 세그먼트가 그 자체로 의미가 있고 단순한 무작위 텍스트 조각이 아니도록 하는 것이 중요합니다. LLM은 정확한 응답을 생성하기 위해 일관된, 잘 구조화된 데이터에 의존합니다. 세그먼트가 불완전하거나 의미가 부족하다면, LLM은 Late Chunking의 이점에도 불구하고 문맥과 정확성에 어려움을 겪을 수 있어 전반적인 성능에 영향을 미칠 수 있습니다. 요약하면, Late Chunking을 사용하든 않든, 효과적인 RAG 시스템을 구축하기 위해서는 견고한 세분화 전략이 필수적입니다(아래 벤치마크 섹션에서 보시게 될 것처럼).
새로운 줄이나 문장에서 단순히 콘텐츠를 나누거나 엄격한 토큰 기반 규칙을 사용하는 등의 전통적인 세분화 방법은 모두 동일한 한계에 직면합니다. 두 접근 방식 모두 의미론적 경계를 고려하지 못하고 모호한 주제를 다루는 데 어려움을 겪어 단편화된 세그먼트를 만들어냅니다. 이러한 과제들을 해결하기 위해, 우리는 주제 전환을 포착하고 일관성을 유지하면서도 다양한 작업에서 효율적이고 적응 가능하도록 설계된 세분화에 특화된 소형 언어 모델을 개발하고 훈련시켰습니다.
tag왜 소형 언어 모델인가?
우리는 전통적인 세분화 기술에서 마주친 특정 한계들, 특히 코드 스니펫과 표, 목록, 수식과 같은 복잡한 구조를 다룰 때의 한계를 해결하기 위해 소형 언어 모델(SLM)을 개발했습니다. 토큰 수나 엄격한 구조적 규칙에 의존하는 전통적인 접근 방식에서는 의미론적으로 일관된 콘텐츠의 무결성을 유지하기가 어려웠습니다. 예를 들어, 코드 스니펫이 자주 여러 부분으로 분할되어 문맥이 깨지고 다운스트림 시스템이 이를 정확하게 이해하거나 검색하기 어렵게 만들었습니다.
전문화된 SLM을 훈련시킴으로써, 우리는 이러한 의미 있는 경계를 지능적으로 인식하고 보존하여 관련된 요소들이 함께 유지되도록 하는 모델을 만들고자 했습니다. 이는 RAG 시스템에서의 검색 품질을 향상시킬 뿐만 아니라, 일관되고 문맥적으로 관련된 세그먼트를 유지하는 것이 중요한 요약과 질문-답변과 같은 다운스트림 작업도 향상시킵니다. SLM 접근 방식은 엄격한 경계를 가진 전통적인 세분화 방법이 단순히 제공할 수 없는 더 적응 가능하고 작업에 특화된 솔루션을 제공합니다.
tagSLM 훈련: 세 가지 접근 방식
우리는 SLM의 세 가지 버전을 훈련시켰습니다:
simple-qwen-0.5는 가장 직관적인 모델로, 문서의 구조적 요소를 기반으로 경계를 식별하도록 설계되었습니다. 그 단순성으로 인해 기본적인 세분화 요구에 효율적인 솔루션이 됩니다.topic-qwen-0.5는 Chain-of-Thought 추론에서 영감을 받아 "제2차 세계대전의 시작"과 같은 텍스트 내의 주제를 식별하고 이러한 주제를 사용하여 세그먼트 경계를 정의함으로써 세분화를 한 단계 더 발전시킵니다. 이 모델은 각 세그먼트가 주제적으로 일관되도록 보장하여 복잡한 다중 주제 문서에 적합합니다. 초기 테스트에서 이 모델은 인간의 직관과 매우 유사한 방식으로 콘텐츠를 세분화하는 데 탁월한 성능을 보였습니다.summary-qwen-0.5는 텍스트 경계를 식별할 뿐만 아니라 각 세그먼트에 대한 요약도 생성합니다. 세그먼트 요약은 특히 긴 문서 질문-답변과 같은 작업에서 RAG 애플리케이션에 매우 유용하지만, 훈련 시 더 많은 데이터가 필요하다는 트레이드오프가 있습니다.
모든 모델은 각 세그먼트의 잘린 버전인 '세그먼트 헤드'만을 반환합니다. 전체 세그먼트를 생성하는 대신, 모델은 단순히 입력 콘텐츠를 복사하는 것이 아니라 의미론적 전환에 초점을 맞춤으로써 경계 감지와 일관성을 향상시키는 주요 포인트나 하위 주제를 출력합니다. 세그먼트를 검색할 때, 문서 텍스트는 이러한 세그먼트 헤드를 기반으로 분할되고 그에 따라 전체 세그먼트가 재구성됩니다.
tag데이터셋
우리는 wiki727k 데이터셋을 사용했습니다. 이는 Wikipedia 기사에서 추출한 구조화된 텍스트 스니펫의 대규모 컬렉션입니다. 727,000개 이상의 섹션을 포함하며, 각각은 소개, 섹션, 또는 하위 섹션과 같은 Wikipedia 기사의 구별되는 부분을 나타냅니다.
koomritag데이터 증강
각 모델 변형에 대한 학습 쌍을 생성하기 위해 GPT-4를 사용하여 데이터를 증강했습니다. 학습 데이터셋의 각 기사에 대해 다음과 같은 프롬프트를 전송했습니다:
f"""
Generate a five to ten words topic and a one sentence summary for this chunk of text.
```
{text}
```
Make sure the topic is concise and the summary covers the main topic as much as possible.
Please respond in the following format:
```
Topic: ...
Summary: ...
```
Directly respond with the required topic and summary, do not include any other details, and do not surround your response with quotes, backticks or other separators.
""".strip()각 기사에서 섹션을 생성하기 위해 간단한 분할을 사용했습니다. \\n\\n\\n로 분할한 다음 \\n\\n로 하위 분할하여 다음과 같은 결과를 얻었습니다(이 경우는 Common Gateway Interface에 관한 기사):
[
[
"In computing, Common Gateway Interface (CGI) offers a standard protocol for web servers to execute programs that execute like Console applications (also called Command-line interface programs) running on a server that generates web pages dynamically.",
"Such programs are known as \\"CGI scripts\\" or simply as \\"CGIs\\".",
"The specifics of how the script is executed by the server are determined by the server.",
"In the common case, a CGI script executes at the time a request is made and generates HTML."
],
[
"In 1993 the National Center for Supercomputing Applications (NCSA) team wrote the specification for calling command line executables on the www-talk mailing list; however, NCSA no longer hosts the specification.",
"The other Web server developers adopted it, and it has been a standard for Web servers ever since.",
"A work group chaired by Ken Coar started in November 1997 to get the NCSA definition of CGI more formally defined.",
"This work resulted in RFC 3875, which specified CGI Version 1.1.",
"Specifically mentioned in the RFC are the following contributors: \\n1. Alice Johnson\\n2. Bob Smith\\n3. Carol White\\n4. David Nguyen\\n5. Eva Brown\\n6. Frank Lee\\n7. Grace Kim\\n8. Henry Carter\\n9. Ingrid Martinez\\n10. Jack Wilson",
"Historically CGI scripts were often written using the C language.",
"RFC 3875 \\"The Common Gateway Interface (CGI)\\" partially defines CGI using C, as in saying that environment variables \\"are accessed by the C library routine getenv() or variable environ\\"."
],
[
"CGI is often used to process inputs information from the user and produce the appropriate output.",
"An example of a CGI program is one implementing a Wiki.",
"The user agent requests the name of an entry; the Web server executes the CGI; the CGI program retrieves the source of that entry's page (if one exists), transforms it into HTML, and prints the result.",
"The web server receives the input from the CGI and transmits it to the user agent.",
"If the \\"Edit this page\\" link is clicked, the CGI populates an HTML textarea or other editing control with the page's contents, and saves it back to the server when the user submits the form in it.\\n",
"\\n# CGI script to handle editing a page\\ndef handle_edit_request(page_content):\\n html_form = f'''\\n <html>\\n <body>\\n <form action=\\"/save_page\\" method=\\"post\\">\\n <textarea name=\\"page_content\\" rows=\\"20\\" cols=\\"80\\">\\n {page_content}\\n </textarea>\\n <br>\\n <input type=\\"submit\\" value=\\"Save\\">\\n </form>\\n </body>\\n </html>\\n '''\\n return html_form\\n\\n# Example usage\\npage_content = \\"Existing content of the page.\\"\\nhtml_output = handle_edit_request(page_content)\\nprint(\\"Generated HTML form:\\")\\nprint(html_output)\\n\\ndef save_page(page_content):\\n with open(\\"page_content.txt\\", \\"w\\") as file:\\n file.write(page_content)\\n print(\\"Page content saved.\\")\\n\\n# Simulating form submission\\nsubmitted_content = \\"Updated content of the page.\\"\\nsave_page(submitted_content)"
],
[
"Calling a command generally means the invocation of a newly created process on the server.",
"Starting the process can consume much more time and memory than the actual work of generating the output, especially when the program still needs to be interpreted or compiled.",
"If the command is called often, the resulting workload can quickly overwhelm the server.",
"The overhead involved in process creation can be reduced by techniques such as FastCGI that \\"prefork\\" interpreter processes, or by running the application code entirely within the web server, using extension modules such as mod_perl or mod_php.",
"Another way to reduce the overhead is to use precompiled CGI programs, e.g.",
"by writing them in languages such as C or C++, rather than interpreted or compiled-on-the-fly languages such as Perl or PHP, or by implementing the page generating software as a custom webserver module.",
"Several approaches can be adopted for remedying this: \\n1. Implementing stricter regulations\\n2. Providing better education and training\\n3. Enhancing technology and infrastructure\\n4. Increasing funding and resources\\n5. Promoting collaboration and partnerships\\n6. Conducting regular audits and assessments",
"The optimal configuration for any Web application depends on application-specific details, amount of traffic, and complexity of the transaction; these tradeoffs need to be analyzed to determine the best implementation for a given task and time budget."
]
],
그런 다음 섹션, 주제 및 요약이 포함된 JSON 구조를 생성했습니다:
{
"sections": [
[
"In computing, Common Gateway Interface (CGI) offers a standard protocol for web servers to execute programs that execute like Console applications (also called Command-line interface programs) running on a server that generates web pages dynamically.",
"Such programs are known as \\"CGI scripts\\" or simply as \\"CGIs\\".",
"The specifics of how the script is executed by the server are determined by the server.",
"In the common case, a CGI script executes at the time a request is made and generates HTML."
],
[
"In 1993 the National Center for Supercomputing Applications (NCSA) team wrote the specification for calling command line executables on the www-talk mailing list; however, NCSA no longer hosts the specification.",
"The other Web server developers adopted it, and it has been a standard for Web servers ever since.",
"A work group chaired by Ken Coar started in November 1997 to get the NCSA definition of CGI more formally defined.",
"This work resulted in RFC 3875, which specified CGI Version 1.1.",
"Specifically mentioned in the RFC are the following contributors: \\n1. Alice Johnson\\n2. Bob Smith\\n3. Carol White\\n4. David Nguyen\\n5. Eva Brown\\n6. Frank Lee\\n7. Grace Kim\\n8. Henry Carter\\n9. Ingrid Martinez\\n10. Jack Wilson",
"Historically CGI scripts were often written using the C language.",
"RFC 3875 \\"The Common Gateway Interface (CGI)\\" partially defines CGI using C, as in saying that environment variables \\"are accessed by the C library routine getenv() or variable environ\\"."
],
[
"CGI is often used to process inputs information from the user and produce the appropriate output.",
"An example of a CGI program is one implementing a Wiki.",
"The user agent requests the name of an entry; the Web server executes the CGI; the CGI program retrieves the source of that entry's page (if one exists), transforms it into HTML, and prints the result.",
"The web server receives the input from the CGI and transmits it to the user agent.",
"If the \\"Edit this page\\" link is clicked, the CGI populates an HTML textarea or other editing control with the page's contents, and saves it back to the server when the user submits the form in it.\\n",
"\\n# CGI script to handle editing a page\\ndef handle_edit_request(page_content):\\n html_form = f'''\\n <html>\\n <body>\\n <form action=\\"/save_page\\" method=\\"post\\">\\n <textarea name=\\"page_content\\" rows=\\"20\\" cols=\\"80\\">\\n {page_content}\\n </textarea>\\n <br>\\n <input type=\\"submit\\" value=\\"Save\\">\\n </form>\\n </body>\\n </html>\\n '''\\n return html_form\\n\\n# Example usage\\npage_content = \\"Existing content of the page.\\"\\nhtml_output = handle_edit_request(page_content)\\nprint(\\"Generated HTML form:\\")\\nprint(html_output)\\n\\ndef save_page(page_content):\\n with open(\\"page_content.txt\\", \\"w\\") as file:\\n file.write(page_content)\\n print(\\"Page content saved.\\")\\n\\n# Simulating form submission\\nsubmitted_content = \\"Updated content of the page.\\"\\nsave_page(submitted_content)"
],
[
"Calling a command generally means the invocation of a newly created process on the server.",
"Starting the process can consume much more time and memory than the actual work of generating the output, especially when the program still needs to be interpreted or compiled.",
"If the command is called often, the resulting workload can quickly overwhelm the server.",
"The overhead involved in process creation can be reduced by techniques such as FastCGI that \\"prefork\\" interpreter processes, or by running the application code entirely within the web server, using extension modules such as mod_perl or mod_php.",
"Another way to reduce the overhead is to use precompiled CGI programs, e.g.",
"by writing them in languages such as C or C++, rather than interpreted or compiled-on-the-fly languages such as Perl or PHP, or by implementing the page generating software as a custom webserver module.",
"Several approaches can be adopted for remedying this: \\n1. Implementing stricter regulations\\n2. Providing better education and training\\n3. Enhancing technology and infrastructure\\n4. Increasing funding and resources\\n5. Promoting collaboration and partnerships\\n6. Conducting regular audits and assessments",
"The optimal configuration for any Web application depends on application-specific details, amount of traffic, and complexity of the transaction; these tradeoffs need to be analyzed to determine the best implementation for a given task and time budget."
]
],
"topics": [
"웹 서버에서의 Common Gateway Interface",
"CGI의 역사와 표준화",
"웹 페이지 편집을 위한 CGI 스크립트",
"명령어 호출에서의 웹 서버 오버헤드 감소"
],
"summaries": [
"CGI는 웹 서버가 동적 웹 페이지를 생성하는 프로그램을 실행하기 위한 프로토콜을 제공합니다.",
"NCSA가 1993년에 CGI를 처음 정의했으며, 이는 웹 서버의 표준이 되었고 나중에 Ken Coar가 주도한 RFC 3875에서 공식화되었습니다.",
"이 텍스트는 CGI 스크립트가 HTML 폼을 통해 웹 페이지 내용을 편집하고 저장하는 방법을 설명합니다.",
"텍스트는 프로세스 사전 포크, 미리 컴파일된 CGI 프로그램 사용, 커스텀 웹 서버 모듈 구현 등 빈번한 명령어 호출로 인한 서버 오버헤드를 최소화하는 기술들을 논의합니다."
]
}
우리는 또한 데이터를 섞고, 임의의 문자/단어/문자를 추가하고, 무작위로 구두점을 제거하고, 항상 줄바꿈 문자를 제거하는 방식으로 노이즈를 추가했습니다.
이 모든 것이 좋은 모델을 개발하는 데 일부 도움이 될 수 있지만 - 거기까지만입니다. 정말로 모든 가능성을 끌어내기 위해서는 코드 스니펫을 망가뜨리지 않으면서 일관된 청크를 만들어내는 모델이 필요했습니다. 이를 위해 GPT-4o로 생성된 코드, 수식, 목록으로 데이터셋을 보강했습니다.
tag학습 설정
모델 학습을 위해 다음과 같은 설정을 구현했습니다:
- 프레임워크: Hugging Face의
transformers라이브러리를Unsloth와 통합하여 모델 최적화에 사용했습니다. 이는 메모리 사용을 최적화하고 학습 속도를 높여 작은 모델로도 큰 데이터셋을 효과적으로 학습할 수 있게 해주었습니다. - 옵티마이저와 스케줄러: 선형 학습률 스케줄과 웜업 스텝이 있는 AdamW 옵티마이저를 사용하여 초기 에포크 동안 학습 과정을 안정화할 수 있었습니다.
- 실험 추적: Weights & Biases를 사용하여 모든 학습 실험을 추적하고, 학습 및 검증 손실, 학습률 변화, 전반적인 모델 성능과 같은 주요 지표를 기록했습니다. 이러한 실시간 추적은 모델의 진행 상황에 대한 통찰을 제공하여 학습 결과를 최적화하기 위해 필요할 때 신속한 조정이 가능했습니다.
tag학습 과정
qwen2-0.5b-instruct를 기본 모델로 사용하여 Unsloth로 서로 다른 세분화 전략을 가진 세 가지 버전의 SLM을 학습했습니다. 샘플로는 wiki727k의 기사 텍스트와 학습 중인 모델에 따라 결과로 나온 sections, topics, 또는 summaries("데이터 증강" 섹션에서 언급)로 구성된 학습 쌍을 사용했습니다.
simple-qwen-0.5:simple-qwen-0.5는 10,000개의 샘플로 5,000 스텝 동안 학습했으며, 빠른 수렴과 텍스트의 응집력 있는 섹션 간의 경계를 효과적으로 감지했습니다. 학습 손실은 0.16이었습니다.topic-qwen-0.5:simple-qwen-0.5와 마찬가지로,topic-qwen-0.5는 10,000개의 샘플로 5,000 스텝 동안 학습했으며, 0.45의 학습 손실을 달성했습니다.summary-qwen-0.5:summary-qwen-0.5는 30,000개의 샘플로 15,000 스텝 동안 학습했습니다. 이 모델은 잠재력을 보여주었지만 학습 중 더 높은 손실(0.81)을 보여, 잠재력을 완전히 발휘하기 위해서는 더 많은 데이터(원래 샘플 수의 약 2배)가 필요함을 시사했습니다.
tag세그먼트 결과
각 세분화 전략과 Jina의 Segmenter API에서 나온 연속된 세 개의 세그먼트 예시입니다. 이러한 세그먼트를 생성하기 위해 먼저 Jina Reader를 사용하여 Jina AI 블로그의 게시물을 일반 텍스트로 스크랩한 후(헤더, 푸터 등의 모든 페이지 데이터 포함), 각 세분화 방법에 전달했습니다.
tagJina Segmenter API
Jina Segmenter API는 게시물을 세분화하는 데 매우 세밀한 접근 방식을 취했으며, \n, \t 등의 문자를 기준으로 텍스트를 종종 매우 작은 세그먼트로 나누었습니다. 처음 세 개만 보더라도, 웹사이트의 네비게이션 바에서 search\\n, notifications\\n, NEWS\\n를 추출했지만 게시물 내용과는 관련이 없었습니다:
나아가서, 마침내 실제 블로그 게시물 내용에서 일부 세그먼트를 얻었지만, 각각에 포함된 맥락은 거의 없었습니다:
(공정성을 위해, Segmenter API의 경우 다른 모델들보다 더 많은 청크를 보여주었습니다. 그렇지 않으면 의미 있는 세그먼트가 거의 없었을 것이기 때문입니다)
tagsimple-qwen-0.5
simple-qwen-0.5는 의미론적 구조를 기반으로 블로그 게시물을 분해하여 일관된 의미를 가진 더 긴 세그먼트를 추출했습니다:
tagtopic-qwen-0.5
topic-qwen-0.5는 먼저 문서의 내용을 바탕으로 주제를 식별한 다음, 해당 주제를 기반으로 문서를 세분화했습니다:
tagsummary-qwen-0.5
summary-qwen-0.5는 세그먼트 경계를 식별하고 각 세그먼트 내의 내용을 요약했습니다:
tag모델 벤치마킹
우리의 모델 성능을 벤치마킹하기 위해, Jina AI 블로그에서 8개의 블로그 게시물을 스크랩하고 GPT-4o를 사용하여 6개의 질문과 정답을 생성했습니다.
Jina Segmenter API를 포함한 각 세분화 방법을 이 블로그 게시물들에 적용한 다음, 후기 청킹이나 리랭킹 없이 jina-embeddings-v3를 사용하여 결과 세그먼트의 임베딩을 생성했습니다.
각 세그먼트 세트는 별도로 인덱싱되었으며, 우리는 이전에 생성된 질문들로 각 인덱스를 쿼리하는 RAG 시스템을 사용했습니다.
topic-qwen-0.5와 summary-qwen-0.5를 테스트할 때는 세그먼트 자체만 인덱싱했으며, 생성된 요약이나 토픽은 포함하지 않았습니다. 이 추가 데이터를 인덱싱하면 성능이 더욱 향상될 것입니다.성능을 측정하기 위해, 각 세그멘테이션 방법의 인덱스에서 생성된 답변을 ROUGE-L 평가의 F1 점수를 사용하여 실제 답변과 비교했습니다. 점수가 높을수록 더 나은 성능을 나타냅니다.
예를 들어, "jina-embeddings-v2-base-en 모델의 수치 비교 능력에 영향을 미치는 요인은 무엇인가요?"라는 질문에 대해 다음과 같은 답변을 받았습니다:
tag실제 답변 (전체 포스트 텍스트에서 GPT-4로 생성):
"The two key factors are tokenization and training data. Tokenization determines how numbers are segmented into tokens, and training data influences numerical reasoning abilities."
tagJina Segmenter API (점수: 0.166667)
"The context does not provide specific factors that impact the numerical comparison abilities of the jina-embeddings-v2-base-en model."
tagsimple-qwen-0.5 (점수: 0.279070)
"The numerical comparison abilities of the jina-embeddings-v2-base-en model are impacted by tokenization and training data."
tagtopic-qwen-0.5 (점수: 0.190476)
"The numerical comparison abilities of the jina-embeddings-v2-base-en model are impacted by factors such as tokenization and its ability to handle different numerical formats, including small integers, large numbers, floats, negative numbers, currency, dates, and times."
tagsummary-qwen-0.5 (0.318182)
"The factors impacting the numerical comparison abilities of the jina-embeddings-v2-base-en model are tokenization and training data."
topic-qwen-0.5의 점수가 이렇게 낮을까요?이는 주로 우리가 모델에 던진 특정 질문 때문입니다. 아래 표에서 볼 수 있듯이,
topic-qwen-0.5의 평균 ROUGE 점수는 모든 세그멘테이션 방법론 중 가장 높습니다.우리는 또한 각 방법의 속도(세그먼트 생성과 임베딩에 걸린 시간을 측정)와 예상 디스크 공간(jina-embeddings-v3의 1024차원 임베딩 하나의 크기에 임베딩 수를 곱함)을 평가했습니다. 이를 통해 다양한 세그멘테이션 전략의 정확도와 효율성을 모두 평가할 수 있었습니다.
tag주요 발견사항
모델 변형들을 서로 비교하고 Jina의 Segmenter API와 테스트한 결과, 새로운 모델들은 특히 토픽 세그멘테이션에서 세 가지 방법 모두에서 향상된 점수를 보여주었습니다:
| Segmentation Method | Average ROUGE Score |
|---|---|
| Jina Segmenter | 0.352126 |
simple-qwen-0.5 |
0.386096 |
topic-qwen-0.5 |
0.398340 |
summary-qwen-0.5 |
0.328143 |
summary-qwen-0.5가 topic-qwen-0.5보다 낮은 ROUGE 점수를 보이나요? 간단히 말해서, summary-qwen-0.5는 훈련 중 더 높은 손실을 보였으며, 이는 더 나은 결과를 얻기 위해 더 많은 훈련이 필요하다는 것을 보여줍니다. 이는 향후 실험의 주제가 될 수 있습니다.하지만 jina-embeddings-v3의 후기 청킹 기능을 사용한 결과를 검토하면 재미있을 것 같습니다. 이 기능은 세그먼트 임베딩의 컨텍스트 관련성을 높여 더 관련성 있는 결과를 제공합니다. 이는 향후 블로그 포스트의 주제가 될 수 있습니다.
속도 면에서는 후자가 API인 반면 우리는 세 모델을 Nvidia 3090 GPU에서 실행했기 때문에 새로운 모델들을 Jina Segmenter와 비교하기가 어려울 수 있습니다. Segmenter API의 빠른 세그멘테이션 단계에서 얻은 성능 이점은 많은 세그먼트에 대한 임베딩 생성 필요성으로 인해 빠르게 상쇄됩니다:
• 두 그래프에서 서로 다른 Y축을 사용한 이유는 이렇게 다른 시간대를 하나의 그래프나 일관된 Y축으로 표현하는 것이 불가능했기 때문입니다.
• 이는 순수하게 실험으로 수행되었기 때문에 임베딩 생성 시 배치 처리를 사용하지 않았습니다. 배치 처리를 사용하면 모든 방법에서 작업 속도가 상당히 빨라질 것입니다.
당연히 더 많은 세그먼트는 더 많은 임베딩을 의미합니다. 그리고 이러한 임베딩은 많은 공간을 차지합니다: 우리가 테스트한 8개의 블로그 포스트에 대한 임베딩은 Segmenter API에서 21 MB 이상을 차지했지만, Summary Segmentation은 468 KB로 훨씬 적었습니다. 이것과 우리 모델들의 더 높은 ROUGE 점수는 더 적지만 더 나은 세그먼트를 의미하며, 비용을 절약하고 성능을 향상시킵니다:
| Segmentation Method | Segment Count | Average Length (characters) | Segmentation Time (minutes/seconds) | Embedding Time (hours/minutes) | Total Embedding Size |
|---|---|---|---|---|---|
| Jina Segmenter | 1,755 | 82 | 3.8s | 1h 46m | 21.06 MB |
simple-qwen-0.5 |
48 | 1,692 | 49s | 1h 2m | 576 KB |
topic-qwen-0.5 |
69 | 1,273 | 2m 3s | 1h 6m | 828 KB |
summary-qwen-0.5 |
39 | 1,799 | 2m 40s | 53m | 468 KB |
tag우리가 배운 것
tag문제 정의가 중요하다
한 가지 핵심적인 통찰은 우리가 작업을 어떻게 구성했는지에 대한 영향이었습니다. 모델이 세그먼트 헤더를 출력하도록 함으로써, 입력 내용을 단순히 복사하여 별도의 세그먼트로 나누는 대신 의미론적 전환에 초점을 맞춰 경계 감지와 일관성을 개선했습니다. 이는 또한 더 적은 텍스트를 생성함으로써 모델이 작업을 더 빨리 완료할 수 있게 하여 더 빠른 세그멘테이션 모델을 만들었습니다.
tagLLM 생성 데이터가 효과적이다
특히 목록, 수식, 코드 스니펫과 같은 복잡한 콘텐츠에 대해 LLM 생성 데이터를 사용하면 모델의 훈련 세트를 확장하고 다양한 문서 구조를 처리하는 능력이 향상되었습니다. 이는 기술적이거나 구조화된 문서를 다룰 때 중요한 이점인 다양한 콘텐츠 유형에 대해 모델을 더 적응력 있게 만들었습니다.
tag출력 전용 데이터 조합
출력 전용 데이터 콜레이터를 사용함으로써, 모델이 입력을 단순히 복사하는 대신 훈련 중에 목표 토큰을 예측하는 데 집중하도록 했습니다. 출력 전용 콜레이터는 모델이 실제 목표 시퀀스에서 학습하도록 보장하여 올바른 완성이나 경계를 강조했습니다. 이러한 구분은 입력에 대한 과적합을 피하고 다양한 데이터셋에서 더 잘 일반화할 수 있도록 도왔습니다.
tagUnsloth를 통한 효율적인 훈련
Unsloth를 사용하여 작은 언어 모델의 훈련을 간소화하여 Nvidia 4090 GPU에서 실행할 수 있었습니다. 이 최적화된 파이프라인을 통해 대규모 컴퓨팅 리소스 없이도 효율적이고 성능이 좋은 모델을 훈련할 수 있었습니다.
tag복잡한 텍스트 처리
세그멘테이션 모델은 일반적으로 전통적인 방법으로는 어려운 코드, 테이블, 목록이 포함된 복잡한 문서를 처리하는 데 탁월했습니다. 기술적인 콘텐츠의 경우, topic-qwen-0.5와 summary-qwen-0.5와 같은 정교한 전략이 더 효과적이었으며, 다운스트림 RAG 작업을 향상시킬 잠재력이 있습니다.
tag간단한 콘텐츠에는 간단한 방법
서술 중심의 단순한 콘텐츠의 경우, Segmenter API와 같은 더 간단한 방법으로도 충분합니다. 고급 세그멘테이션 전략은 더 복잡하고 구조화된 콘텐츠에만 필요할 수 있어, 사용 사례에 따라 유연성을 제공합니다.
tag다음 단계
이 실험이 주로 개념 증명용으로 설계되었지만, 더 발전시키고자 한다면 몇 가지 개선사항이 있습니다. 첫째, 이 특정 실험의 지속은 가능성이 낮지만, summary-qwen-0.5를 30,000개가 아닌 60,000개의 샘플로 더 큰 데이터셋에서 훈련하면 더 최적의 성능을 얻을 수 있을 것입니다. 또한, 벤치마킹 프로세스를 개선하는 것이 유익할 것입니다. RAG 시스템에서 LLM이 생성한 답변을 평가하는 대신, 검색된 세그먼트를 직접 정답과 비교하는 데 집중할 것입니다. 마지막으로, ROUGE 점수를 넘어서 검색 및 세그멘테이션 품질의 뉘앙스를 더 잘 포착할 수 있는 더 고급 메트릭(ROUGE와 LLM 스코어링의 조합일 수 있음)을 채택할 것입니다.
tag결론
이 실험에서 우리는 특정 작업을 위해 설계된 맞춤형 세그멘테이션 모델이 어떻게 RAG의 성능을 향상시킬 수 있는지 탐구했습니다. simple-qwen-0.5, topic-qwen-0.5, summary-qwen-0.5와 같은 모델을 개발하고 훈련함으로써, 특히 의미론적 일관성을 유지하고 코드 스니펫과 같은 복잡한 콘텐츠를 효과적으로 처리하는 데 있어 전통적인 세그멘테이션 방법에서 발견되는 주요 과제들을 해결했습니다. 테스트된 모델 중에서 topic-qwen-0.5는 특히 다중 주제 문서에 대해 가장 의미 있고 문맥적으로 관련성 있는 세그멘테이션을 일관되게 제공했습니다.
세그멘테이션 모델이 RAG 시스템에 필요한 구조적 기반을 제공하는 반면, 세그먼트 전반에 걸쳐 문맥적 관련성을 유지하여 검색 성능을 최적화하는 후기 청킹과는 다른 기능을 합니다. 이 두 접근 방식은 상호 보완적일 수 있지만, 세그멘테이션은 특히 일관성 있는 작업별 생성 워크플로우를 위해 문서를 분할하는 방법이 필요할 때 중요합니다.
