Clarify a BERT Keyphrase Span-Extraction Task

# Clarify a BERT Keyphrase Span-Extraction Task The preserved report links to a BERT keyphrase span-extraction coding exercise, but it does not retain the linked statement. The callable interface, supplied model outputs, tokenizer behavior, valid spans, scoring rule, and required result are therefore unknown. Explain how you would recover a deterministic contract before coding, choose an approach only after those details are confirmed, and validate the resulting extraction pipeline. ### Constraints & Assumptions - The linked BERT keyphrase span-extraction topic is the only preserved technical fact. - It is unknown whether the exercise supplies text, tokens, token labels, boundary scores, candidate spans, or a trained model. - BIO tagging, overlap rules, confidence aggregation, output ordering, and training requirements are not preserved facts. - Any proposed implementation must be conditional on an explicitly confirmed input, output, and evaluation contract. ### Clarifying Questions to Ask - What exactly is supplied to the function, and which part of the pipeline must the candidate implement? - Which tokenizer and offset mapping are authoritative, especially for subwords and normalized text? - What makes a span valid, and may keyphrases overlap, nest, repeat, or include punctuation? - What exact values and order must be returned, and how are invalid input and equal scores handled? ### Part 1 — Recover the contract List the minimum interface, model-output, span-validity, and result rules needed to make the exercise deterministic. #### What This Part Should Cover - Input types, ownership of tokenization, and character-offset convention - Supplied model outputs and the candidate's implementation boundary - Valid spans, score interpretation, and any overlap policy - Exact return representation, ordering, ties, and invalid-input behavior ### Part 2 — Select a conditional approach Compare suitable approaches for at least two plausible confirmed contracts, without claiming that either was the original exercise. #### What This Part Should Cover - A token-state scan when a complete label sequence is supplied - Candidate construction and constrained selection when boundary or span scores are supplied - The effect of overlap, maximum length, ordering, and score semantics on the algorithm - Complexity stated in terms of the confirmed input size ### Part 3 — Validate the pipeline Describe tests that isolate tokenization, model-output interpretation, span construction, and final offset reconstruction. #### What This Part Should Cover - Empty text, punctuation, Unicode, repeated phrases, and subword boundaries - Invalid or inconsistent label and offset inputs - Overlapping, nested, touching, and equal-score candidates when permitted by the contract - Exact span-level examples and evaluation tied to the confirmed output format ```hint Fix the implementation boundary first A model name and task label do not reveal whether you are implementing tokenization, decoding supplied outputs, ranking spans, or running a trained model. ``` ### What a Strong Answer Covers - A source-faithful statement of what is known and missing - A deterministic contract before any algorithm is selected - Conditional approaches that follow from confirmed representations and rules - Offset handling, edge cases, tests, and honest complexity analysis ### Follow-up Questions 1. How would the design change if the input were BIO labels rather than boundary scores? 2. Which tests reveal an offset error caused by subword tokenization or text normalization? 3. How would you evaluate exact spans separately from partial-overlap matches?