osFoundry / Platform
자동 청킹 파이프라인
섹션, 코드 블록, 목록을 존중하는 스마트 청킹. 폴더별로 조정 가능합니다.
개요
자동 청킹 파이프라인은 검색과 임베딩을 위한 osFoundry의 문서 분할기입니다. 텍스트를 의미 기반으로 검색하거나 모델에 컨텍스트로 넣기 전에, 먼저 조각으로 나눠야 합니다. 단순한 분할기는 고정된 글자 수에서 잘라내기 때문에, 함수를 중간에서 끊거나, 번호 목록을 두 청크로 쪼개거나, 제목을 그것이 소개하는 문단에서 떼어놓기 일쑤입니다. osFoundry의 파이프라인은 구조를 인식합니다. 먼저 문서 자체의 경계를 읽고 그 경계를 따라 자르므로, 섹션은 자기 섹션과 함께 남고, 코드 블록은 온전히 유지되며, 목록은 목록으로 남습니다.
osFoundry 안에서 청킹은 지식과 임베딩·검색 레이어 사이의 단계로 동작합니다. 폴더에 문서를 추가하면 파이프라인이 그 구조를 파싱하고, 이러한 자연스러운 경계를 보존한 청크를 만들어 임베딩 단계로 넘깁니다. 청킹과 검색은 로컬 우선으로 이뤄지므로, 원본 문서는 제3자 인덱싱 서비스로 보내지지 않고 사용자 기기에 그대로 둘 수 있습니다. 임베딩은 플랫폼이 비용을 부담하는 유일한 단계이며(osFoundry 프록시 경유), 채팅과 에이전트에 가져오는 모델은 사용자 본인의 키로 동작하고 리셀러 마진이 붙지 않습니다. 즉 동일한 코퍼스가 한곳에서 채팅, 에이전트, 앱, 검색에 공급되며, 누가 그 위에 무언가를 만들 수 있는지를 좌석당 요금으로 가로막지 않습니다.
청크 크기에 만능 정답은 없으므로 파이프라인은 폴더별로 조정할 수 있습니다. API 레퍼런스와 소스 코드가 담긴 폴더는 긴 산문이나 회의록이 담긴 폴더와는 다른 경계를 필요로 합니다. 동작을 폴더 단위로 설정하므로 각 지식 묶음은 그것이 실제로 읽히는 방식에 맞게 청킹되고, 폴더를 다시 인덱싱하면 변경된 부분만 다시 청킹됩니다. 더 나은 청크는 더 정확한 검색으로 이어집니다. 모델이 보는 구절이 일관되고 자기완결적이므로, 이후 단계에서 부실하거나 환각적인 답을 유발하는 노이즈가 줄어듭니다.
주요 기능
- 문서의 실제 구조를 기준으로 분할해, 맹목적인 글자 수로 자르는 대신 섹션, 코드 블록, 목록을 온전히 유지합니다
- 폴더별로 조정할 수 있어, 레퍼런스 문서, 소스 코드, 긴 산문이 각각 자신에게 맞는 청크 경계를 얻습니다
- osFoundry의 임베딩·검색 레이어에 공급해, RAG와 의미 검색을 위한 더 깔끔한 구절을 만들어 냅니다
- 로컬 우선으로 동작하므로, 원본 문서를 제3자 인덱서로 보내지 않고 사용자 기기에 둘 수 있습니다
- 검색된 컨텍스트를 사용하는 채팅과 에이전트 전반에서 BYOK를 지원하며, 좌석당 요금도 리셀러 마진도 없습니다
활용 사례
- 사내 RAG 어시스턴트를 만드는 엔지니어: 리포지토리의 문서와 코드를 함수 중간에서 끊지 않고 청킹해, 답변이 예제를 통째로 인용하도록 합니다
- 긴 보고서를 인덱싱하는 분석가: 각 섹션과 그 표를 함께 유지해, 검색이 일관되고 자기완결적인 구절을 반환하도록 합니다
- 혼합 지식을 관리하는 팀 리드: 산문 폴더와 코드 폴더를 서로 다르게 청킹하도록 설정해, 코퍼스별로 검색 품질을 조정합니다
자주 묻는 질문
고정 크기 청킹과 무엇이 다릅니까?
고정 크기 분할기는 내용과 무관하게 N글자마다 잘라내어 코드 블록, 목록, 제목을 쪼갭니다. osFoundry는 먼저 문서 구조를 읽고 섹션, 코드 블록, 목록 경계에서 자르므로 각 청크가 일관되고 자기완결적으로 유지됩니다.
콘텐츠 종류별로 청킹 동작을 제어할 수 있습니까?
네. 청킹은 폴더별로 조정할 수 있어, 소스 코드나 API 레퍼런스 폴더를 긴 산문이나 메모 폴더와 다르게 청킹할 수 있습니다. 각 지식 묶음이 실제로 읽히는 방식에 맞는 경계를 얻습니다.
청킹하는 동안 제 데이터는 어디로 갑니까?
청킹과 검색은 로컬 우선으로 동작하므로 원본 문서를 사용자 기기에 둘 수 있습니다. 임베딩은 osFoundry 프록시를 거치는 유일한 플랫폼 부담 단계이며, 채팅과 에이전트에 쓰는 모델은 본인의 키로 동작하고 리셀러 마진이 붙지 않습니다.