What the documents look like
For marketplace advertising and on-site traffic, product material and selection questions revolve around four working documents: the delivery plan, the keyword report, the audience package description, and the conversion attribution table. Delivery adjusts pricing in step with traffic and conversion, so these documents change on a daily or hourly cadence, and the underlying data comes from advertising consoles and shop transaction records. Citation tracing has one job here: every product material statement and every selection conclusion in an answer must be traceable to the wording of the corresponding document, together with that document's version and authorization state.
Two features of this category shape the tracing step. First, the documents carry review states and validity windows, so a plan can be pending review while a draft sentence treats it as settled. Second, the retrieval path that produces citations is not a single similarity lookup. A knowledge base search node can associate one or more knowledge bases that share the same vector model, and the citation content is output as an array whose length may be zero; when nothing is retrieved, that output path still completes. Retrieval may pass through question optimization, semantic retrieval, full-text retrieval, hybrid retrieval, RRF fusion, ReRank, and similarity filtering, so the final citations do not necessarily follow a single vector similarity order. The vector model identifier of each knowledge base must be checked first; knowledge bases with different vector models cannot be associated together. This step only checks identifiers and excludes mismatches. A similarity score is a relevance threshold and does not perform permission or entity isolation, and retrieval by itself does not constitute authorization.
Constraints at the citation tracing step
The citation array is the evidence carrier. Each product material conclusion in the answer is compared against the cited source text, and the source text is compared against the version and authorization state of the document it came from. When the array is empty, the downstream design is checked against a length of zero, and no claim is made that a particular rule must return an empty array. When a document field is not stated, the gap stays a gap.
A hypothetical paper exercise illustrates the boundary. Label it clearly as a hypothetical exercise, not a real record. On 10 March 2025, a brand marketing team submits a delivery plan awaiting review. The source material is three sentences: "This plan applies to A-series products, with a delivery period from 15 March to 31 March 2025." "The audience package description is marked as historical transacted audience, with no update date attached." "The conversion attribution table was compiled by an agency operator and its status is pending review." The draft sentence to be judged reads: "The delivery plan for A-series products from 15 March to 31 March 2025 has been approved, and the audience package has been updated." The authorization boundary of this request: submission and pending review coexist, no approval record appears, and no audience package update date is stated.
Judging the draft sentence requires same subject, same period, and same field. The plan's status field holds pending review, and the comparison object is an approval record; with no approval record present, the approval claim is unsupported. The audience package update field is not stated, and the comparison object is evidence of a completed update; the update claim is unsupported. The draft sentence exceeds what the source text supports.
Configuration and implementation checks
| Configuration or check item | Hypothetical starting point for this exercise | Reason and comparison method |
|---|---|---|
| Associated knowledge bases | Select libraries sharing one vector model identifier | Check the vector model identifier first, compare it against each library to be associated, and exclude mismatches |
| Search parameter source | Follow the documented knowledge base search parameters | Compare item by item against the documented search modes and filter settings |
| Citation upper limit | Assume a starting point of a number of tokens per search | This value is only a starting point for this exercise; compare it against the actual retrieved length and adjust |
| Minimum relevance | Takes effect only under semantic retrieval or result reordering | Compare against the active search mode; when that mode is not enabled, it is not a filtering basis |
| Citation array handoff | Pass the citation array to the answering step | Check each answer statement against the cited source text; treat an empty array as length zero |
| Material timeliness check | Test with current-version and historical-version documents separately | Compare the two sources; adoption still depends on review of the effective version |
Three common errors
- Treating a delivery plan pending review as approved. The input is the hypothetical sample's pending review status, the comparison object is an approval record, and the observable result is that with no approval record present the claim can only be recorded as unverified.
- Treating an audience package description without an update date as an update completed. The input is an unstated update date, the comparison object is evidence of a completed update, and the observable result is that this field is unsupported.
- Treating a similarity score as a permission filter. The input is the minimum relevance setting, the comparison object is an authorization record, and the observable result is that retrieval results do not exclude unauthorized records on the basis of similarity level.
How to verify the setup
- Compare the hypothetical source text against the draft sentence. The input is the three source sentences and the draft sentence, the comparison covers approval status and audience package update date, and the observable result is that a draft sentence exceeding the source text is judged unsupported, while an unstated field keeps its evidence gap.
- Check the citation array handoff. The input is the citation array output by the search node, the comparison is between answer content and cited source text, and the observable result is that each product material conclusion corresponds to cited source text; when the output is an empty array, the downstream design is checked against length zero, without asserting that a particular rule necessarily returns an empty array.
- Check material timeliness. The input is current-version and historical-version documents, the comparison covers the two sources and their applicable periods, and the observable result is that a version mismatch is marked unverified; whether a citation is adopted still depends on review of the effective version.