Understand first
New to this knowledge point
Complete the prerequisite concepts, read the principles and counterexamples, and then explain why in your own words.
Start with core principles →Understand → Implement → Debug → Design
Examining multiple rounds of reference, entity linking, clarification, and original constraint preservation.
Knowledge content check2026-10-03 · Check the source of the original question2026-10-02
It is recommended to understand first:
From document ingestion to cited RAG answers →RAG evidence flow and failure diagnosis →Select the starting point based on the current basis, or you can go deeper one by one. When you encounter an unfamiliar concept, go back to the core principles first; use the knowledge exercises to check your understanding when you are finished.
New to this knowledge point
Complete the prerequisite concepts, read the principles and counterexamples, and then explain why in your own words.
Start with core principles →Prepare to write the principles into code
Understand implementation steps and boundaries, complete small tasks, and check results against acceptance requirements.
Reading implementation and trade-offs →Need to handle failures and changes in conditions
Follow the continuous questioning to locate the failure premise, and then compare the migration cases to explain how the plan should be adjusted.
Continue to delve deeper into the problem →Need to design or review plans
Combine engineering deductions and senior self-evaluation standards to explain the applicable conditions, costs and alternatives of the plan.
Analyze engineering scenarios →LEARN · PRACTICE · REFLECT
First read along the principles, Q&A and migration cases. When you need to check your understanding, switch to reinforcement exercises or start personal recording.
Can be practiced directly. After logging in, answers, favorites, and notes will be saved to your account.
Log in and saveEach modified commit will be kept as an independent history. Your level of mastery is up to you to evaluate yourself against the standards.
Core concept · Entity disambiguation and constraint preservation in query rewriting
Preparatory concepts:Conversation state and deference, Structured query slot, Clarification and search planning
The purpose of rewriting is to express the known intention more retrievably and not to create missing facts. Entity, negation, time, and scope must have a source, and ambiguities affecting the answer need to be preserved or clarified.
“What is its balance in Chongqing?” depends on earlier context without naming a complete entity. Record candidate entities, the source turn, and actual user confirmations. Keep confirmed entities separate from guesses. Similarity is neither authorization nor confirmation.
Structured intent distinguishes entity, region, metric, time, and exclusions; unknowns remain unknown. Original and expanded search branches share one trusted access scope. Compare identifiers, negations, and dates before and after rewriting. Reintroducing a frequent historical entity after “not China Merchants Bank, ICBC” corrupts intent rather than merely degrading retrieval.
Ask the most discriminating concrete question when candidates imply different answers. Low-risk searches can retrieve alternatives and show differences, but cannot silently merge them. Financial, authorization, and action requests need clearer definitions. Clarification depends on consequence, not a mechanical similarity-gap threshold.
Change only negation, region, date, or account scope and verify only that field changes. Evaluate original question, structured intent, and final answer separately with traceable evidence. Retain current confirmations and exclusions as history grows. A new statement can correct prior context, but saying something yesterday does not establish that the fact only becomes effective today.
Resolve references from current context, preserving the original question and evidence for each entity. Clarify competing entities or missing conditions that change the answer. Rewriting cannot invent banks, dates, account scope, or authorization. Evaluate original and rewritten intent for preserved negation, scope, and time constraints.
The context selects the most recently explicitly confirmed subject, user modifier, and current task target without flooding the rewriter with full chat. Output entity ID candidates, regions, indicators, time ranges, evidence locations, and fields to be clarified. Trusted identities and visible data scopes are appended by the server. The rewriter can only select authorized candidates and cannot generate new authorization scopes.
"It" may be China Merchants Bank from the previous round, or it may be a specific account. The referent is resolved first and then mapped to the bank, branch or account in the data dictionary. Similar names do not represent the same entity. Candidates should contain distinguishable regional and organizational attributes. Automatically select only when the current context is clear enough, otherwise use short questions to confirm instead of always selecting the candidate with the highest similarity.
Restrictions such as "excluding frozen funds", "yesterday's closing" and "this department only" are retained. Synonyms can be expanded for retrieval, but balance inquiries cannot be turned into expenditure inquiries, nor can "Chongqing Branch" be expanded to include all accounts in Chongqing. Multiple query variants need to share the budget and return to the original definition in the final answer to avoid finding different objects separately and then splicing them together.
Construct multiple rounds of dialogue and deliberately add entity switching, negative corrections, branches with the same name, and historical expiration information. Measure entity accuracy, constraint retention rate, incorrect automatic selection rate, and completion rate after clarification respectively. Only by retaining the original question, rewriting, and entity candidates when retrieving the final wrong answer can we determine that the question comes from rewriting rather than incorrectly adjusting the Embedding parameters.
Continue reading along with the premises and constraints of the problem. Understand the reference answers first, then try to put away the answers and explain the cause and effect and trade-offs in your own words.
Level 1What should I do if the two candidates are very similar?
Moving from referential completion toward ambiguity boundaries that change answers.
Similar scores indicate insufficient evidence for automatic selection. Check whether the candidates will produce substantially different answers; if so, provide minimal clarification, such as "referring to the branch where the account is opened or all accounts in Chongqing?" Low-risk searches can be divided into candidate searches and clearly displayed. You cannot randomly pick one item and give a unique conclusion. Similarity does not replace user confirmation.
Follow this answer further
Level 2Data can be retrieved for both candidates. Can the two balances be added together as the answer?
After the similar candidates asked by the father enter the query, the temptation arises to synthesize the search results into answers.
No, successful retrieval does not eliminate entity ambiguity. Summing can only be performed if the user intent explicitly requires a total and the range is legal; otherwise, the candidate ranges are stated separately and confirmation is requested. In particular, the two candidates may overlap, and the sum will be counted repeatedly. Complete the definition confirmation first, and then submit it to the deterministic calculation.
Follow this answer further
Level 3What still needs checking when the user says 'include them all'?
After clarification, the natural-language selection still needs to map to a verifiable business set without duplicates.
Confirm that "both" refers to the two collections just shown, and check whether the accounts overlap, whether the currency at the time is consistent, and whether the permissions are met. The total is deduplicated and fixed with a unique business entity; the user's approval of two tags cannot be interpreted as unlimited expansion of unknown accounts. Answers list the total range to facilitate users to find deviations in understanding.
Level 1How can a user retain an entity that he just rejected in the last round?
Multiple rounds of status require processing corrections rather than accumulating related words.
Save negations as constraints with turn, object, and scope, and mark old candidates as invalid instead of just adding a sentence of text. The rewrite check prohibits the reintroduction of excluded entities; if the user explicitly corrects it later, the constrained version will be updated. The summary should also preserve this negation, not just extract frequently occurring entity names.
Level 1How to deal with different definitions brought by query expansion?
When extending coverage to improve, it is still necessary to prevent multiple definitions from being fused.
Query expansion only adds expression methods and does not change entity, time and indicator definitions. Label the extensions each as a synonymous expression or as a different interpretation; different interpretations cannot directly mix evidence for a number. If an extended hit exposes ambiguity, clarify first or answer separately, with the final answer stating the actual range.
First find out the conditions for change, and then determine which premises in the original plan still hold true. The following cases are teaching deductions to facilitate the transfer of principles to new problems.
Changing conditions:Results are used for browsing rather than financial judgment
Extended question:"How to write its cancellation" exists in two libraries. Can I ask one less question?
You can return a short description and source of two candidate libraries for the user to select, or give priority to the library if there is a confirmed context. The retrieval plan still separates versions and entities, and you cannot match A's cancellation API with B's sample code. Update session state based on user selections, retaining current hypothesis labels.
The principles that remain unchanged:Allowing exploration does not mean allowing secret confirmation. The evidence must correspond to each candidate explanation.
Changing conditions:The same technology name has been mentioned in history, but the current project is different
Extended question:Is it advisable to override the most recent project configuration?
The currently explicitly selected project scope is used first before its confirmed configuration is read; another project mentioned in the most recent round may just be the comparison object. Clarification when scope is missing and version affects answer. Permission boundaries are obtained from the server. Just because a project is mentioned in history, it cannot be considered that it is still readable.
The principles that remain unchanged:Session dependencies are not equal to the current object and access grants, intents must be resolved within an explicit scope.
It is designed based on public technical information; the reference materials support the technical mechanism, and the scenarios and scoring standards are designed by this website and do not represent the original interview questions of a certain company. New Q&A and migration cases are added for principle explanation, and source verification and case operation verification are recorded separately.
After reading, you can explain the principles, boundaries, and trade-offs against these standards. It is up to you to evaluate your mastery; if further verification is needed, complete the small tasks below.
Rewrite the three rounds of dialogue with subject switching into structured intentions, and mark the fields that cannot be automatically determined.