SnowPro Specialty: Gen AI Question 136
Single answerSPLIT_TEXT_RECURSIVE_CHARACTERA team is building a retrieval-augmented generation (RAG) pipeline in Snowflake using long policy documents stored in a table. They plan to chunk each document before generating embeddings, and they want chunks that stay close to a target size while avoiding unnecessary splits in the middle of paragraphs or sentences. The team is considering the SPLIT_TEXT_RECURSIVE_CHARACTER function for this step. Which approach best meets this requirement?
- A
Use SPLIT_TEXT_RECURSIVE_CHARACTER with an ordered list of separators from larger logical boundaries to smaller ones, so the function first tries to split on paragraph-like delimiters before falling back to finer-grained boundaries.
- B
Use SPLIT_TEXT_RECURSIVE_CHARACTER with only a single empty-string separator, because this guarantees semantically coherent chunks and prevents oversplitting.
- C
Avoid SPLIT_TEXT_RECURSIVE_CHARACTER and instead create one chunk per document, because embedding models generally perform better when given the full source text rather than smaller segments.
- D
Use SPLIT_TEXT_RECURSIVE_CHARACTER after generating embeddings, so the model can decide the best chunk boundaries based on the completed vectors.
Show answer and explanation
Correct answer: A
Explanation
SPLIT_TEXT_RECURSIVE_CHARACTER is intended for chunking text by attempting separators recursively in a defined order until the text is split into pieces near the target size. In practical GenAI workflows, this is useful when preparing long unstructured documents for embedding and retrieval. A recommended pattern is to prefer larger semantic boundaries first, such as paragraph separators, then move to smaller ones only when necessary. This preserves readability and semantic cohesion better than splitting purely by fixed character counts or single-character boundaries. In RAG systems, chunking should occur before embedding generation, because each resulting chunk is stored, embedded, and retrieved independently. This aligns with Snowflake Cortex Search and general RAG best practices for improving retrieval relevance and staying within model input constraints.
- A. Correct.
Correct. Recursive character-based splitting is designed to try separators in sequence, typically from coarse to fine boundaries such as paragraph breaks, line breaks, spaces, and then smaller fallbacks if needed. This helps produce chunks near the desired size while preserving natural text structure as much as possible, which is a common best practice for RAG chunking before embedding generation.
- B. Incorrect.
Incorrect. Using only an empty-string separator forces splitting at the character level, which does not preserve paragraph or sentence boundaries and can create unnatural chunks. This is the opposite of what the team wants. The misconception is that finer granularity automatically improves semantic quality, but in practice it often harms coherence.
- C. Incorrect.
Incorrect. Creating one chunk per full document is usually a poor fit for RAG when documents are long. Large chunks reduce retrieval precision, can exceed model or embedding input limits, and make it harder to return the most relevant section. Chunking is typically done specifically to improve retrieval quality and manage context size.
- D. Incorrect.
Incorrect. Chunking is normally performed before embeddings are created, because each chunk becomes the unit that is embedded and indexed for retrieval. Embeddings cannot retroactively define chunk boundaries for the source text in a standard Snowflake text-splitting workflow.