Why a model must learn from failed attempts over the course of a conversation

Repeated sampling often repeats the error

Automated program repair aims to generate a working patch from faulty code. With large language models, this was often done by querying the same constructed prompt multiple times.

Xia and Zhang criticize two consequences: the model repeatedly produces identical incorrect patches, and crucial information from test cases does not feed into the next attempt.

Under these conditions, more attempts do not automatically mean more learning. Without feedback, each run remains largely a new sample from the same starting point.

The problem resembles a conversation in which a user says a suggestion does not fit, but the chat only offers a slightly reworded version of the same idea.

Validation becomes part of the next context

The proposed approach alternates between patch generation and checking. Earlier suggestions are incorporated into the next input along with the feedback from validation.

This allows the model to avoid generating patches that have already been identified as incorrect. At the same time, it receives information about how the program actually behaves under the test cases.

The long context input is thus not merely used as storage. It contains targeted feedback from action and outcome. It is precisely this structure that makes the trajectory useful.

The researchers compared ten different language models, including ChatGPT, and report improvements over the previous LLM approach to program repair.

Conversation feedback requires the same consistency

In a chat, validation comes directly from the user. Sentences such as “I didn’t say that,” “I don’t want a tip right now,” or “Don’t ask me after every message” are precise feedback about a failed response attempt.

A polite apology is only the first step. If the system immediately afterward again interprets, guesses, or asks, it has linguistically acknowledged the feedback but has not functionally used it.

The next context should therefore include the correction as an active conversational condition. Here, the meaning is more important than repeating the sentence verbatim.

For example, from “I want to collect first” can arise the temporary rule of giving brief listening responses and not proposing any actions until the person themselves asks for them or changes direction.

In doing so, a later single question does not have to immediately count as a complete mode switch. The system can briefly clarify whether an assessment is now desired, instead of restarting the entire counseling process from a small signal.

Why people do not simply correct errors

Sharma and colleagues investigated in two studies why people often do not give useful feedback to a conversational system despite recognizable problems. The work, published at CHI in 2026, describes four barriers: lack of common ground, difficulty of verification, effort in formulating, and uncertainty about which feedback is informative at all.

Silence or a brief abandonment should therefore not be read as agreement. A person may notice an error and still not know which part of the answer to correct, what the system relies on, or whether their correction will have any effect later.

The researchers derived three design goals and tested aids intended to make feedback more targeted. These scaffolds improved the quality of user feedback. However, it does not follow that every chat should demand a rating or justification after every response. A permanent feedback prompt could disrupt the conversation itself.

For trajectory systems, the narrower consequence is more helpful: the correctable claim or action must be recognizable, a change should be easy to make, and it should be visibly taken into account in the further course. If the feedback is ambiguous, a brief clarification can be useful. If it is unambiguous, the system should act rather than ask again for an explanation.

The CHI studies assessed feedback quality in controlled tasks, not long-term model learning or the impact of personal conversations. They do, however, show why the absence of a correction is not a reliable quality judgment and why repair options must be part of conversation design.

• No feedback is not automatically positive feedback.
• Corrections should be easy to provide and should change the subsequent course of the conversation.
• For verifiable statements, it should be visible what an answer is based on.
• Only later conversational turns show whether feedback was actually incorporated.

Not every correction applies forever

Conversational preferences have different scopes. A desired casual tone can apply across many sessions. The wish not to receive questions right now may be meant only for a few turns.

Good trajectory management must therefore distinguish between global settings, session goals, and momentary boundaries. Storing everything permanently would be just as wrong as forgetting everything after a single message.

In the repair context, feedback also refers to concrete patches and test cases. It is used in a targeted manner, not appended as unstructured text to every future task.

For chats, a compact state representation can be more helpful than the full history: the selected mode, the current intention, explicitly rejected approaches, and open points.

Validation must be sufficiently independent

For code, a test provides a relatively clear signal as to whether specific behavior is correct. Conversations rarely have such an unambiguous output. An answer can suit one person and be annoying to another.

This is why multiple sources of review are needed: direct feedback, fixed error types, expert assessment, and tests with complete multi-turn conversation trajectories. No single automatic judgment should decide quality on its own.

Downstream classifiers can, for instance, flag that advice occurred in listening mode. They should not blindly block the response, because a sentence classified as advice may be explicitly desired in the specific context.

The most important validator often remains the person themselves. Product logic should weight their correction more heavily than an internal assumption about the appropriate conversation technique.

Expert information has different review rules

The rhinoplasty study by Xie and colleagues evaluated nine responses for accessibility, informativeness, and accuracy. Specialists found the responses coherent and understandable, but limited in personalization.

Here, validation primarily involves comparison with expert knowledge and whether individual limitations are correctly identified. A user’s request cannot make factually incorrect information true.

Conversation quality and factual quality therefore require separate feedback. The user decides what kind of conversation they want; verifiable sources and expert assessments help determine whether a medical statement is sound.

A shared system architecture should not mix these signals. Otherwise, a pleasant course of the conversation could mask factual errors or force correct information unnecessarily into an inappropriate advisory mode.

Social quality can also be reported back

Liu and Sundar found that empathetic expressions were preferred over purely emotionless responses in sensitive health counseling. This shows that social design also has measurable effects on perception.

However, empathetic language is not a fixed solution. When a user provides a correction, incorporating that correction is likely more important than another expression of emotion.

Conversation trajectory tests should therefore specifically examine which information is given priority. Direct feedback must be able to override a previous style rule or model expectation.

The system does not learn within a single conversation in the sense of new model training. However, it can update its active context and its selection rules in such a way that the observable behavior is consistently adjusted.

A long context is not yet a good memory

Conversational Program Repair demonstrates the value of a structured loop of proposal, verification, and retry. The improvement arises not merely from more tokens, but from selected validation feedback.

For conversational systems, this means deliberately carrying forward corrections, boundaries, and outcomes of earlier proposals into the subsequent course of the conversation. A raw chat history can lose relevant signals among many messages.

Good state management should also be visibly tested: does the system repeat a rejected piece of advice, does it reassert a corrected statement, or does it actually change the direction of the conversation?

A model learns from a failed attempt only in practical terms when the next attempt turns out different and better. This simple requirement turns conversation history into an instrument of quality rather than merely an archive.