จัดการกรณีไม่มีคำตอบและเอกสารยาว

Real questions often have no answer in the passage. A robust QA system should admit that instead of forcing a wrong guess. 🤔

Models trained for this learn a null answer option. When no span fits, they point to an empty answer rather than inventing one.

In the pipeline, set handle_impossible_answer to true so it can return an empty string when nothing in the context matches.

The confidence score is your safety gate. If it falls below a threshold you trust, treat the reply as no answer.

Transformers have a fixed max length, often 512 tokens. A long document simply will not fit in one pass.

The fix is chunking: split a long document into overlapping windows, then run QA on each window separately.

Chunks should overlap a little. Otherwise an answer sitting on a chunk boundary could be split and lost between two windows.

The QA pipeline can do this for you. Set doc_stride to control how much each window overlaps the previous one.

Each chunk yields its own answer and score. You keep the candidate with the highest score across all chunks as the final reply.

For huge collections, first retrieve the few most relevant passages, then run QA only on those. This is the heart of larger QA systems.

Returning no answer when unsure is a feature, not a flaw. Honest QA earns user trust far more than a confident wrong guess. 🛡️

How do we feed a very long document to a QA model?

Allow null answers and gate on score for honesty; chunk long docs with overlap, then keep the best-scoring span. You can now ship robust QA. 🎉