The port-operations copilot serves terminal planners at several ports, and a planner in Rotterdam keeps receiving answers drawn from Singapore circulars because the wording is nearly identical. The circular chunks carry a port_code column that was included in the index. What is the correct fix inside the retrieval step?
Select an answer to reveal the explanation.
Short Explanation
Semantic search finds text that means the same thing, and two ports' circulars genuinely do mean the same thing. Meaning cannot tell them apart — a column can. Filter on the metadata you already indexed instead of hoping the model sorts it out downstream.
Full Explanation
This is a retrieval-precision failure with a structural cause: the discriminating attribute is the port, and port identity is not encoded in the semantics of the text, so vector similarity alone will never separate the two corpora reliably. Databricks Vector Search supports filters over metadata columns that were synced into the index, so scoping the query to port_code = 'Rotterdam' removes the wrong-port chunks from consideration before ranking rather than after. Raising the number of results is the closest trap and it makes things worse: it enlarges the context and the wrong-port chunks are still in it, competing for the model's attention. Instructing the model in the system prompt is a post-hoc patch — the model can only work with what retrieval handed it, and if all top chunks are Singapore's, the instruction produces a refusal or a hallucination rather than a Rotterdam answer. Lowering a similarity threshold loosens the filter in the wrong dimension entirely and admits more noise. The exam point to carry forward: metadata filtering only works on columns that were included in the index at creation, so decide your filter dimensions — port, jurisdiction, document type, effective date — before you build it.