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

Repeated sampling often repeats the error

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

Xia and Zhang criticize two consequences: the model repeatedly produces identical incorrect patches, and crucial information from test cases does not flow 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 rephrased version of the same idea.

Validation becomes part of the next context

The proposed approach alternates between patch generation and validation. Earlier proposals 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 interprets, guesses, or asks again afterward, it has acknowledged the feedback linguistically but has not functionally used it.

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

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

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

Not every correction applies forever

Conversation preferences have different scopes. A desired casual tone can apply across many sessions. The wish not to receive questions right now may only be meant 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 one 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: selected mode, current intention, explicitly rejected approaches, and open points.

Validation must be sufficiently independent

With code, a test provides a comparatively clear signal as to whether specific behavior is correct. Conversations rarely have such an unambiguous output. An answer may suit one person and be off-putting to another.

That is why multiple sources of verification are needed: direct feedback, fixed error types, expert assessment, and tests with complete multi-turn conversation trajectories. No single automated judgment should be the sole arbiter of quality.

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

The most important validator often remains the user themselves. Product logic should weigh their correction more heavily than an internal assumption about the appropriate conversational technique.

Expert information follows different verification rules

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

Here, validation consists primarily of comparison with expert knowledge and of 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 loops. 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 feeling.

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 in the sense of new model training within a single conversation. But it can update its active context and selection rules so that 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 incorporating corrections, limitations, 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, reassert a corrected statement, or actually change the direction of the conversation?

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