A job-search platform wants to match resumes to job postings based on overall meaning rather than exact keyword overlap, so that a resume mentioning 'led a team of developers' matches a posting asking for 'engineering management experience' even though the wording is different. Which Foundry capability should the team use to build this matching feature?
Select an answer to reveal the explanation.
Short Explanation
What this platform actually needs is a way to compare what two pieces of text mean, not just whether they share the same words, since a resume and a posting can describe the same skill in completely different phrasing. That's precisely the job embeddings are built for, they turn a piece of text into a set of numbers that represents its meaning, so two phrases that mean roughly the same thing end up landing close together numerically even if not a single word overlaps. Reading postings aloud has nothing to do with comparing meaning, it's about accessibility. Letting a model read a longer document in one go just changes how much text fits in a single request, it doesn't give you any way to measure how similar two separate texts are to each other. And filtering out biased wording is a safety step, not a matching mechanism. When the whole point is finding things that mean the same thing despite different words, converting text into comparable numeric representations is the tool that actually does that.
Full Explanation
The correct answer is B. An embeddings model converts each resume and posting into a numeric vector that captures its meaning, so texts with different wording but similar intent, such as 'led a team of developers' and 'engineering management experience,' end up close together in vector space and can be matched by similarity rather than by shared keywords. Option A is incorrect because text-to-speech converts written text into audio for accessibility purposes; it has no role in comparing the meaning of two pieces of text and would not help match resumes to postings at all. Option C is incorrect because a larger context window only changes how much text a chat model can process in a single request; it does not give the system a way to numerically compare meaning across two separate documents, which is what matching requires. Option D is incorrect because content filtering is a safety control for detecting harmful or biased content, not a mechanism for measuring semantic similarity, so applying it would not help the platform find resumes that mean the same thing as a posting even when the wording differs. Embeddings are purpose-built for exactly this kind of meaning-based comparison, which is why they fit the matching requirement described.