You are the librarian behind a help center's search box. People type a question, and your job is to hand back the few passages most likely to contain the answer. You are given the whole knowledge base as an array of documents, each with an id and a block of text, the visitor's query as a string, and k, the number of passages to return. You return at most k passages, the most relevant first, where a passage is any snippet of text drawn from the documents.
Implement retrieve(documents, query, k). The runtime is bare: no network, no model, no packages, just plain JavaScript over the text you are handed. The obvious approach, scoring each document by how many of the query's words it contains and returning the top k, clears the easy questions where the answer page is short and uses the same words as the question.
The catch is the knowledge base this librarian works. Some answers are written in completely different words than the visitor would ever type, while other pages loudly share the visitor's exact words without holding the answer at all, so a search that only matches the literal words of the question fills its top k with the loud wrong pages and walks right past the page that holds the answer. Specify how retrieve decides which passages are relevant and what it hands back, completely enough that it surfaces the true answer even when the question and the answer share no words. You are graded on whether the answer lands in your top k, on questions you do not get to see while you write the spec.
Example
retrieve(documents, 'how is data encrypted at rest', 3) should put the passage that names the encryption back in the top three. The harder question is the one where the visitor asks to 'get my money back' but the only page that helps says 'refund' and never says 'money' or 'back', so a literal-word search surfaces the pages that do say those words and never reaches the answer.