{ "slug": "reflection", "category": "reliability", "updated": "2026-06-21", "version": "1.0", "url": "https://santismm.com/en/patterns/reflection", "canonical_url": "https://santismm.com/en/patterns/reflection", "api_url": "https://santismm.com/api/patterns/reflection", "urls": { "en": "https://santismm.com/en/patterns/reflection", "es": "https://santismm.com/es/patterns/reflection", "pt": "https://santismm.com/pt/patterns/reflection", "fr": "https://santismm.com/fr/patterns/reflection", "de": "https://santismm.com/de/patterns/reflection", "ja": "https://santismm.com/ja/patterns/reflection", "zh": "https://santismm.com/zh/patterns/reflection" }, "evidence": { "evidenceLevel": "industry_observation", "confidenceLevel": "high", "sourceType": [ "industry_observation", "paper" ] }, "technologies": [ "LangGraph", "Agent frameworks", "LLM-as-judge" ], "references": [ { "title": "Shinn et al. — Reflexion: Language Agents with Verbal Reinforcement Learning (2023)", "url": "https://arxiv.org/abs/2303.11366" } ], "related": [ "evaluator-optimizer", "prompt-chaining" ], "locales": { "en": { "name": "Reflection", "summary": "Reflection has a model critique its own output and then revise it, using the critique as feedback. It is a lightweight, single-model way to catch mistakes and improve quality on reasoning, coding and writing tasks — at the cost of extra calls.", "definition": "Reflection is a pattern in which a model reviews and critiques its own output against explicit criteria and then revises it, trading extra inference for higher quality.", "problem": "Models often produce a flawed first answer they could improve if prompted to review their own work, but a single pass gives them no chance to.", "context": "Use reflection when a self-review step measurably improves output and you want a simpler alternative to a two-model evaluator loop — common in reasoning and coding tasks.", "solution": [ "After generating an answer, prompt the same model to critique it against the goal (and any tool feedback such as test results or errors), then to produce a revised answer informed by that critique. Repeat for a bounded number of iterations.", "Reflection works best when grounded in real signals — execution errors, test output, retrieved facts — rather than pure self-assessment, which can be overconfident." ], "components": [ "Initial generation", "Self-critique step", "Grounding signal (errors / tests / facts)", "Revision", "Iteration budget" ], "benefits": [ "Improves quality with a single model — no second system.", "Effective when grounded in tool or test feedback.", "Simple to add to an existing call." ], "risks": [ "Self-critique can be overconfident or miss its own errors.", "Extra calls add latency and cost.", "Without grounding, gains are limited." ], "whenNot": [ "When you have an objective external check — use evaluator-optimizer.", "When a single pass already meets the bar.", "When latency budgets are very tight." ], "examples": [ "A coding agent reading test failures and fixing its own patch.", "A reasoning task where the model rechecks its steps before answering.", "A draft the model reviews for gaps before finalizing." ], "productionEvidence": { "context": "Tasks where output quality matters more than latency or cost — drafting, code generation, analysis — and where errors are detectable on review.", "scenario": "After producing a first answer, the model (or a separate critic) evaluates it against concrete criteria and produces a revised version; the loop is capped at one or two passes.", "technology": "A critique-then-revise prompt chain, ideally backed by external signals (tests, tools, a separate evaluator) for high-stakes work.", "load": "Each reflection pass at least doubles calls, so it is applied selectively to the outputs that justify the overhead.", "results": "Observed pattern: reflection lifts quality where the model can actually detect its own errors, but it can over-revise correct answers and at least doubles cost. Measure the quality lift against an eval set before trusting it, and prefer external signals when stakes are high." }, "kpis": [ { "metric": "Quality lift from reflection", "note": "Measured improvement in output quality with the reflection step versus without; if it's not measurable, the step isn't earning its cost." }, { "metric": "Self-correction rate", "note": "Share of genuine errors the model catches and fixes on review — distinct from cosmetic edits." }, { "metric": "Added latency & cost", "note": "Reflection at least doubles calls; track the overhead against the quality it buys." }, { "metric": "Over-revision rate", "note": "How often reflection degrades an already-good answer by second-guessing it." } ], "failureModes": [ "Self-evaluation blind spots: a model often can't see its own errors, so reflection misses them.", "Over-revision: the model 'fixes' a correct answer into a worse one.", "Cost and latency double (or more) for marginal or no quality gain.", "False confidence: the model asserts the output is now correct when it isn't." ], "lessons": [ "Measure the lift; reflection is worth it only where it demonstrably improves quality.", "Prefer external signals (tests, tools, a separate evaluator) over pure self-critique when stakes are high.", "Cap reflection to one or two passes — returns diminish fast and cost compounds.", "Give the reflection step concrete criteria, not a vague 'improve this'." ], "faqs": [ { "q": "Reflection or evaluator-optimizer?", "a": "Reflection uses one model to self-critique (simpler); evaluator-optimizer uses a separate evaluator (sharper, less biased). Choose by how reliable self-assessment is for your task." }, { "q": "Does reflection always help?", "a": "It helps most when grounded in real feedback like test results or errors. Pure self-assessment can be overconfident and add little." }, { "q": "How many reflection rounds?", "a": "Keep it bounded — often one or two. Diminishing returns and rising cost make long loops rarely worth it." } ] }, "es": { "name": "Reflexión (Reflection)", "summary": "La reflexión hace que un modelo critique su propia salida y luego la revise, usando la crítica como feedback. Es una forma ligera, de un solo modelo, de atrapar errores y mejorar la calidad en tareas de razonamiento, código y escritura, a costa de llamadas extra.", "definition": "La reflexión es un patrón en el que un modelo revisa y critica su propia salida frente a criterios explícitos y luego la corrige, cambiando inferencia adicional por mayor calidad.", "problem": "Los modelos a menudo producen una primera respuesta defectuosa que podrían mejorar si se les pide revisar su propio trabajo, pero una sola pasada no les da la oportunidad.", "context": "Usa la reflexión cuando un paso de autorrevisión mejore la salida de forma medible y quieras una alternativa más simple al bucle evaluador de dos modelos —común en tareas de razonamiento y código.", "solution": [ "Tras generar una respuesta, pide al mismo modelo que la critique frente al objetivo (y cualquier feedback de herramientas como resultados de tests o errores), y luego que produzca una respuesta revisada informada por esa crítica. Repite un número acotado de iteraciones.", "La reflexión funciona mejor anclada en señales reales —errores de ejecución, salida de tests, hechos recuperados— que en la pura autoevaluación, que puede ser demasiado confiada." ], "components": [ "Generación inicial", "Paso de autocrítica", "Señal de anclaje (errores / tests / hechos)", "Revisión", "Presupuesto de iteración" ], "benefits": [ "Mejora la calidad con un solo modelo, sin segundo sistema.", "Eficaz cuando se ancla en feedback de herramientas o tests.", "Simple de añadir a una llamada existente." ], "risks": [ "La autocrítica puede ser demasiado confiada o no ver sus errores.", "Las llamadas extra añaden latencia y coste.", "Sin anclaje, las ganancias son limitadas." ], "whenNot": [ "Cuando tienes una comprobación externa objetiva: usa evaluador-optimizador.", "Cuando una sola pasada ya alcanza el nivel.", "Cuando los presupuestos de latencia son muy ajustados." ], "examples": [ "Un agente de código que lee fallos de tests y corrige su propio parche.", "Una tarea de razonamiento donde el modelo revisa sus pasos antes de responder.", "Un borrador que el modelo revisa en busca de lagunas antes de finalizar." ], "productionEvidence": { "context": "Tareas donde la calidad importa más que la latencia o el coste —redacción, generación de código, análisis— y donde los errores son detectables al revisar.", "scenario": "Tras producir una primera respuesta, el modelo (o un crítico aparte) la evalúa frente a criterios concretos y produce una versión revisada; el bucle se limita a una o dos pasadas.", "technology": "Una cadena de prompts criticar-luego-revisar, idealmente respaldada por señales externas (tests, herramientas, un evaluador aparte) para el trabajo de alto riesgo.", "load": "Cada pasada de reflexión al menos duplica las llamadas, así que se aplica de forma selectiva a las salidas que justifican el sobrecoste.", "results": "Patrón observado: la reflexión mejora la calidad donde el modelo puede de verdad detectar sus propios errores, pero puede sobrerrevisar respuestas correctas y al menos duplica el coste. Mide la mejora frente a un conjunto de evaluación antes de confiar en ella, y prefiere señales externas cuando hay mucho en juego." }, "kpis": [ { "metric": "Mejora de calidad por reflexión", "note": "Mejora medida en la calidad con el paso de reflexión frente a sin él; si no es medible, el paso no justifica su coste." }, { "metric": "Tasa de autocorrección", "note": "Proporción de errores reales que el modelo detecta y corrige al revisar, distinta de ediciones cosméticas." }, { "metric": "Latencia y coste añadidos", "note": "La reflexión al menos duplica las llamadas; vigila el sobrecoste frente a la calidad que aporta." }, { "metric": "Tasa de sobrerrevisión", "note": "Con qué frecuencia la reflexión degrada una respuesta ya buena al cuestionarla en exceso." } ], "failureModes": [ "Puntos ciegos de autoevaluación: un modelo suele no ver sus propios errores, así que la reflexión los pasa por alto.", "Sobrerrevisión: el modelo 'corrige' una respuesta correcta y la empeora.", "Coste y latencia se duplican (o más) para una ganancia de calidad marginal o nula.", "Falsa confianza: el modelo afirma que la salida ya es correcta cuando no lo es." ], "lessons": [ "Mide la mejora; la reflexión vale la pena solo donde mejora la calidad de forma demostrable.", "Prefiere señales externas (tests, herramientas, un evaluador aparte) sobre la pura autocrítica cuando hay mucho en juego.", "Limita la reflexión a una o dos pasadas: los rendimientos caen rápido y el coste se acumula.", "Da al paso de reflexión criterios concretos, no un vago 'mejora esto'." ], "faqs": [ { "q": "¿Reflexión o evaluador-optimizador?", "a": "La reflexión usa un modelo para autocriticarse (más simple); el evaluador-optimizador usa un evaluador separado (más afilado, menos sesgado). Elige según cuán fiable sea la autoevaluación en tu tarea." }, { "q": "¿La reflexión siempre ayuda?", "a": "Ayuda más cuando se ancla en feedback real como resultados de tests o errores. La pura autoevaluación puede ser demasiado confiada y aportar poco." }, { "q": "¿Cuántas rondas de reflexión?", "a": "Mantenlo acotado, a menudo una o dos. Los rendimientos decrecientes y el coste creciente hacen que los bucles largos rara vez compensen." } ] }, "pt": { "name": "Reflexão (Reflection)", "summary": "A reflexão faz um modelo criticar sua própria saída e depois revisá-la, usando a crítica como feedback. É uma forma leve, de um único modelo, de capturar erros e melhorar a qualidade em tarefas de raciocínio, código e escrita, ao custo de chamadas extras.", "definition": "A reflexão é um padrão em que um modelo revisa e critica a própria saída frente a critérios explícitos e depois a corrige, trocando inferência adicional por mais qualidade.", "problem": "Os modelos muitas vezes produzem uma primeira resposta defeituosa que poderiam melhorar se solicitados a revisar o próprio trabalho, mas uma única passagem não lhes dá a chance.", "context": "Use a reflexão quando um passo de autorrevisão melhore a saída de forma mensurável e você queira uma alternativa mais simples ao laço avaliador de dois modelos — comum em tarefas de raciocínio e código.", "solution": [ "Após gerar uma resposta, peça ao mesmo modelo que a critique frente ao objetivo (e qualquer feedback de ferramentas como resultados de testes ou erros), e depois que produza uma resposta revisada informada por essa crítica. Repita um número limitado de iterações.", "A reflexão funciona melhor ancorada em sinais reais — erros de execução, saída de testes, fatos recuperados — que na pura autoavaliação, que pode ser confiante demais." ], "components": [ "Geração inicial", "Passo de autocrítica", "Sinal de ancoragem (erros / testes / fatos)", "Revisão", "Orçamento de iteração" ], "benefits": [ "Melhora a qualidade com um único modelo, sem segundo sistema.", "Eficaz quando ancorada em feedback de ferramentas ou testes.", "Simples de adicionar a uma chamada existente." ], "risks": [ "A autocrítica pode ser confiante demais ou não ver seus erros.", "As chamadas extras adicionam latência e custo.", "Sem ancoragem, os ganhos são limitados." ], "whenNot": [ "Quando você tem uma verificação externa objetiva: use avaliador-otimizador.", "Quando uma única passagem já alcança o nível.", "Quando os orçamentos de latência são muito apertados." ], "examples": [ "Um agente de código que lê falhas de testes e corrige seu próprio patch.", "Uma tarefa de raciocínio em que o modelo revisa seus passos antes de responder.", "Um rascunho que o modelo revisa em busca de lacunas antes de finalizar." ], "productionEvidence": { "context": "Tarefas onde a qualidade importa mais que latência ou custo —redação, geração de código, análise— e onde os erros são detectáveis na revisão.", "scenario": "Após produzir uma primeira resposta, o modelo (ou um crítico à parte) a avalia frente a critérios concretos e produz uma versão revisada; o laço é limitado a uma ou duas passagens.", "technology": "Uma cadeia de prompts criticar-depois-revisar, idealmente apoiada por sinais externos (testes, ferramentas, um avaliador à parte) para o trabalho de alto risco.", "load": "Cada passagem de reflexão ao menos duplica as chamadas, então é aplicada de forma seletiva às saídas que justificam o sobrecusto.", "results": "Padrão observado: a reflexão melhora a qualidade onde o modelo consegue de fato detectar os próprios erros, mas pode sobrerrevisar respostas corretas e ao menos duplica o custo. Meça o ganho frente a um conjunto de avaliação antes de confiar nela, e prefira sinais externos quando há muito em jogo." }, "kpis": [ { "metric": "Ganho de qualidade pela reflexão", "note": "Melhoria medida na qualidade com o passo de reflexão versus sem ele; se não for mensurável, o passo não justifica seu custo." }, { "metric": "Taxa de autocorreção", "note": "Proporção de erros reais que o modelo detecta e corrige ao revisar, distinta de edições cosméticas." }, { "metric": "Latência e custo adicionados", "note": "A reflexão ao menos duplica as chamadas; vigie o sobrecusto frente à qualidade que traz." }, { "metric": "Taxa de sobrerrevisão", "note": "Com que frequência a reflexão degrada uma resposta já boa ao questioná-la em excesso." } ], "failureModes": [ "Pontos cegos de autoavaliação: um modelo costuma não ver os próprios erros, então a reflexão os ignora.", "Sobrerrevisão: o modelo 'corrige' uma resposta correta e a piora.", "Custo e latência dobram (ou mais) para um ganho de qualidade marginal ou nulo.", "Falsa confiança: o modelo afirma que a saída já está correta quando não está." ], "lessons": [ "Meça o ganho; a reflexão vale a pena só onde melhora a qualidade de forma demonstrável.", "Prefira sinais externos (testes, ferramentas, um avaliador à parte) à pura autocrítica quando há muito em jogo.", "Limite a reflexão a uma ou duas passagens: os retornos caem rápido e o custo se acumula.", "Dê ao passo de reflexão critérios concretos, não um vago 'melhore isto'." ], "faqs": [ { "q": "Reflexão ou avaliador-otimizador?", "a": "A reflexão usa um modelo para se autocriticar (mais simples); o avaliador-otimizador usa um avaliador separado (mais afiado, menos enviesado). Escolha conforme quão confiável é a autoavaliação na sua tarefa." }, { "q": "A reflexão sempre ajuda?", "a": "Ajuda mais quando ancorada em feedback real como resultados de testes ou erros. A pura autoavaliação pode ser confiante demais e agregar pouco." }, { "q": "Quantas rodadas de reflexão?", "a": "Mantenha limitado, muitas vezes uma ou duas. Os retornos decrescentes e o custo crescente fazem laços longos raramente valerem a pena." } ] }, "fr": { "name": "Réflexion", "summary": "La réflexion consiste à faire critiquer par un modèle sa propre sortie, puis à la réviser en utilisant cette critique comme retour d'expérience. C'est un moyen léger, basé sur un seul modèle, de détecter les erreurs et d'améliorer la qualité des tâches de raisonnement, de codage et de rédaction — au coût d'appels supplémentaires.", "definition": "La réflexion est un modèle dans lequel un modèle examine et critique sa propre sortie par rapport à des critères explicites, puis la révise, échangeant une inférence supplémentaire contre une qualité supérieure.", "problem": "Les modèles produisent souvent une première réponse imparfaite qu'ils pourraient améliorer si on les invitait à revoir leur propre travail, mais une seule passe ne leur en donne pas l'occasion.", "context": "Utilisez la réflexion lorsqu'une étape d'auto-examen améliore de manière mesurable la sortie et que vous souhaitez une alternative plus simple à une boucle d'évaluation à deux modèles — ce qui est courant dans les tâches de raisonnement et de codage.", "solution": [ "Après avoir généré une réponse, demandez au même modèle de la critiquer par rapport à l'objectif (et à tout retour d'outil tel que des résultats de tests ou des erreurs), puis de produire une réponse révisée tenant compte de cette critique. Répétez l'opération pour un nombre limité d'itérations.", "La réflexion fonctionne mieux lorsqu'elle s'appuie sur des signaux réels — erreurs d'exécution, résultats de tests, faits récupérés — plutôt que sur une simple auto-évaluation, qui peut être trop confiante." ], "components": [ "Génération initiale", "Étape d'auto-critique", "Signal d'ancrage (erreurs / tests / faits)", "Révision", "Budget d'itérations" ], "benefits": [ "Améliore la qualité avec un seul modèle — pas de second système.", "Efficace lorsqu'elle s'appuie sur les retours d'outils ou de tests.", "Simple à ajouter à un appel existant." ], "risks": [ "L'auto-critique peut être trop confiante ou passer à côté de ses propres erreurs.", "Les appels supplémentaires ajoutent de la latence et des coûts.", "Sans ancrage, les gains sont limités." ], "whenNot": [ "Lorsque vous disposez d'un contrôle externe objectif — utilisez l'évaluateur-optimiseur.", "Lorsqu'un seul passage atteint déjà le niveau requis.", "Lorsque les budgets de latence sont très serrés." ], "examples": [ "Un agent de codage lisant les échecs de tests et corrigeant son propre correctif.", "Une tâche de raisonnement où le modèle vérifie à nouveau ses étapes avant de répondre.", "Un brouillon que le modèle examine pour y déceler des lacunes avant de le finaliser." ], "productionEvidence": { "context": "Tâches où la qualité des résultats importe plus que la latence ou le coût — rédaction, génération de code, analyse — et où les erreurs sont détectables lors de la révision.", "scenario": "Après avoir produit une première réponse, le modèle (ou un critique distinct) l'évalue par rapport à des critères concrets et produit une version révisée ; la boucle est limitée à un ou deux passages.", "technology": "Une chaîne de prompts critique-puis-révision, idéalement soutenue par des signaux externes (tests, outils, évaluateur distinct) pour les tâches à enjeux élevés.", "load": "Chaque passage de réflexion double au moins les appels, il est donc appliqué de manière sélective aux résultats qui justifient ce surcoût.", "results": "Modèle observé : la réflexion améliore la qualité lorsque le modèle peut réellement détecter ses propres erreurs, mais elle peut sur-réviser des réponses correctes et double au moins le coût. Mesurez l'amélioration de la qualité par rapport à un ensemble d'évaluation avant de lui faire confiance, et privilégiez les signaux externes lorsque les enjeux sont élevés." }, "kpis": [ { "metric": "Amélioration de la qualité grâce à la réflexion", "note": "Amélioration mesurée de la qualité des résultats avec l'étape de réflexion par rapport à une exécution sans ; si elle n'est pas mesurable, l'étape ne justifie pas son coût." }, { "metric": "Taux d'auto-correction", "note": "Part des erreurs réelles que le modèle détecte et corrige lors de la révision — distincte des modifications cosmétiques." }, { "metric": "Latence et coût supplémentaires", "note": "La réflexion double au moins les appels ; suivez le surcoût par rapport à la qualité qu'elle apporte." }, { "metric": "Taux de sur-révision", "note": "Fréquence à laquelle la réflexion dégrade une réponse déjà satisfaisante en la remettant en question." } ], "failureModes": [ "Angles morts de l'auto-évaluation : un modèle ne voit souvent pas ses propres erreurs, de sorte que la réflexion passe à côté.", "Sur-révision : le modèle « corrige » une réponse correcte pour en faire une moins bonne.", "Le coût et la latence doublent (ou plus) pour un gain de qualité marginal ou nul.", "Fausse confiance : le modèle affirme que le résultat est désormais correct alors qu'il ne l'est pas." ], "lessons": [ "Mesurez l'amélioration ; la réflexion n'en vaut la peine que lorsqu'elle améliore manifestement la qualité.", "Privilégiez les signaux externes (tests, outils, évaluateur distinct) à la simple auto-critique lorsque les enjeux sont élevés.", "Limitez la réflexion à un ou deux passages — les rendements diminuent rapidement et les coûts s'accumulent.", "Donnez à l'étape de réflexion des critères concrets, et non une consigne vague comme « améliore ceci »." ], "faqs": [ { "q": "Réflexion ou évaluateur-optimiseur ?", "a": "La réflexion utilise un seul modèle pour s'auto-critiquer (plus simple) ; l'évaluateur-optimiseur utilise un évaluateur distinct (plus précis, moins biaisé). Choisissez en fonction de la fiabilité de l'auto-évaluation pour votre tâche." }, { "q": "La réflexion est-elle toujours utile ?", "a": "Elle est surtout utile lorsqu'elle s'appuie sur des retours réels tels que des résultats de tests ou des erreurs. Une simple auto-évaluation peut être trop confiante et apporter peu." }, { "q": "Combien de cycles de réflexion ?", "a": "Limitez-les — souvent un ou deux. Les rendements décroissants et l'augmentation des coûts font que les boucles longues en valent rarement la peine." } ] }, "de": { "name": "Reflection", "summary": "Bei Reflection kritisiert ein Modell seine eigene Ausgabe und überarbeitet sie anschließend, wobei es die Kritik als Feedback nutzt. Es ist eine leichtgewichtige Methode für ein einzelnes Modell, um Fehler zu finden und die Qualität bei Denk-, Codierungs- und Schreibaufgaben zu verbessern – auf Kosten zusätzlicher Aufrufe.", "definition": "Reflection ist ein Pattern, bei dem ein Modell seine eigene Ausgabe anhand expliziter Kriterien überprüft, kritisiert und anschließend überarbeitet, wobei zusätzliche Inferenz für eine höhere Qualität in Kauf genommen wird.", "problem": "Modelle liefern oft eine fehlerhafte erste Antwort, die sie verbessern könnten, wenn sie aufgefordert würden, ihre eigene Arbeit zu überprüfen. Ein einziger Durchlauf gibt ihnen jedoch keine Gelegenheit dazu.", "context": "Verwenden Sie Reflection, wenn ein Selbstüberprüfungsschritt die Ausgabe messbar verbessert und Sie eine einfachere Alternative zu einer Evaluator-Schleife mit zwei Modellen suchen – was bei Denk- und Codierungsaufgaben häufig der Fall ist.", "solution": [ "Fordern Sie dasselbe Modell nach der Generierung einer Antwort auf, diese im Hinblick auf das Ziel (und jegliches Tool-Feedback wie Testergebnisse oder Fehler) zu kritisieren und anschließend eine überarbeitete Antwort auf Basis dieser Kritik zu erstellen. Wiederholen Sie dies für eine begrenzte Anzahl von Iterationen.", "Reflection funktioniert am besten, wenn sie auf realen Signalen basiert – Ausführungsfehlern, Testausgaben, abgerufenen Fakten – und nicht auf reiner Selbsteinschätzung, die zu übermäßigem Vertrauen (Overconfidence) neigen kann." ], "components": [ "Initiale Generierung", "Schritt der Selbstkritik", "Grounding-Signal (Fehler / Tests / Fakten)", "Überarbeitung", "Iterationsbudget" ], "benefits": [ "Verbessert die Qualität mit einem einzigen Modell – kein zweites System erforderlich.", "Effektiv, wenn auf Tool- oder Test-Feedback gestützt.", "Einfach in einen bestehenden Aufruf zu integrieren." ], "risks": [ "Selbstkritik kann zu optimistisch sein oder eigene Fehler übersehen.", "Zusätzliche Aufrufe erhöhen Latenz und Kosten.", "Ohne Grounding sind die Qualitätsgewinne begrenzt." ], "whenNot": [ "Wenn Sie eine objektive externe Prüfung haben – nutzen Sie Evaluator-Optimizer.", "Wenn ein einziger Durchlauf die Anforderungen bereits erfüllt.", "Wenn das Latenzbudget sehr knapp bemessen ist." ], "examples": [ "Ein Coding-Agent, der Testfehler liest und seinen eigenen Patch korrigiert.", "Eine Denkaufgabe (Reasoning), bei der das Modell seine Schritte vor der Antwort nochmals überprüft.", "Ein Entwurf, den das Modell vor der Fertigstellung auf Lücken überprüft." ], "productionEvidence": { "context": "Aufgaben, bei denen die Ausgabequalität wichtiger ist als Latenz oder Kosten – wie Entwurfserstellung, Codegenerierung, Analyse – und bei denen Fehler bei der Überprüfung erkennbar sind.", "scenario": "Nach der Erstellung einer ersten Antwort bewertet das Modell (oder ein separater Kritiker) diese anhand konkreter Kriterien und erstellt eine überarbeitete Version; die Schleife ist auf ein oder zwei Durchläufe begrenzt.", "technology": "Eine Prompt-Kette nach dem Prinzip „Kritik, dann Überarbeitung“, idealerweise gestützt durch externe Signale (Tests, Tools, ein separater Evaluator) für kritische Aufgaben.", "load": "Jeder Reflection-Durchlauf verdoppelt mindestens die Anzahl der Aufrufe, weshalb er gezielt nur auf Ausgaben angewendet wird, die diesen Mehraufwand rechtfertigen.", "results": "Beobachtetes Muster: Reflection steigert die Qualität dort, wo das Modell seine eigenen Fehler tatsächlich erkennen kann, kann jedoch korrekte Antworten übermäßig überarbeiten (Over-Revision) und verdoppelt mindestens die Kosten. Messen Sie die Qualitätssteigerung anhand eines Evaluierungs-Sets, bevor Sie darauf vertrauen, und bevorzugen Sie bei kritischen Aufgaben externe Signale." }, "kpis": [ { "metric": "Qualitätssteigerung durch Reflection", "note": "Gemessene Verbesserung der Ausgabequalität mit dem Reflection-Schritt im Vergleich zu ohne; wenn sie nicht messbar ist, rechtfertigt der Schritt seine Kosten nicht." }, { "metric": "Selbstkorrekturrate", "note": "Anteil echter Fehler, die das Modell bei der Überprüfung erkennt und behebt – im Unterschied zu rein kosmetischen Bearbeitungen." }, { "metric": "Zusätzliche Latenz & Kosten", "note": "Reflection verdoppelt mindestens die Anzahl der Aufrufe; stellen Sie den Mehraufwand der gewonnenen Qualität gegenüber." }, { "metric": "Over-Revision-Rate", "note": "Wie oft Reflection eine bereits gute Antwort durch nachträgliches Zweifeln verschlechtert." } ], "failureModes": [ "Blinde Flecken bei der Selbsteinschätzung: Ein Modell kann seine eigenen Fehler oft nicht erkennen, sodass Reflection diese übersieht.", "Over-Revision: Das Modell „korrigiert“ eine richtige Antwort und verschlechtert sie dadurch.", "Kosten und Latenz verdoppeln sich (oder mehr) bei nur geringem oder gar keinem Qualitätsgewinn.", "Falsches Vertrauen: Das Modell behauptet, die Ausgabe sei nun korrekt, obwohl sie es nicht ist." ], "lessons": [ "Messen Sie die Steigerung; Reflection lohnt sich nur dort, wo sie die Qualität nachweislich verbessert.", "Bevorzugen Sie bei kritischen Aufgaben externe Signale (Tests, Tools, einen separaten Evaluator) gegenüber reiner Selbstkritik.", "Begrenzen Sie Reflection auf ein oder zwei Durchläufe – der Nutzen nimmt schnell ab und die Kosten summieren sich.", "Geben Sie dem Reflection-Schritt konkrete Kriterien an die Hand, statt eines vagen „Verbessere dies“." ], "faqs": [ { "q": "Reflection oder Evaluator-Optimizer?", "a": "Reflection nutzt ein einziges Modell zur Selbstkritik (einfacher); Evaluator-Optimizer nutzt einen separaten Evaluator (präziser, weniger voreingenommen). Wählen Sie danach aus, wie zuverlässig die Selbsteinschätzung für Ihre Aufgabe ist." }, { "q": "Hilft Reflection immer?", "a": "Sie hilft am meisten, wenn sie auf realem Feedback wie Testergebnissen oder Fehlern basiert. Reine Selbsteinschätzung kann zu optimistisch sein und bringt oft wenig Mehrwert." }, { "q": "Wie viele Reflection-Runden sind sinnvoll?", "a": "Halten Sie es in Grenzen – oft ein oder zwei. Aufgrund abnehmender Erträge und steigender Kosten lohnen sich lange Schleifen selten." } ] }, "ja": { "name": "リフレクション", "summary": "リフレクションは、モデルに自身の出力を批判（レビュー）させ、その批判をフィードバックとして使用して修正させる手法です。これは、追加の呼び出しコストと引き換えに、推論、コーディング、執筆タスクにおける誤りを検出し、品質を向上させるための、単一モデルによる軽量なアプローチです。", "definition": "リフレクションは、モデルが明示的な基準に照らして自身の出力をレビューおよび批判し、それを修正するパターンであり、追加の推論コストと引き換えに、より高い品質を得る手法です。", "problem": "モデルは、自身の成果物をレビューするように促されれば改善できるような、欠陥のある初期回答を出力しがちですが、1回のパス（シングルパス）だけではその機会がありません。", "context": "自己レビューのステップによって出力が測定可能なほど改善され、2つのモデルを使用するエバリュエーター（評価者）ループに代わるよりシンプルな方法を求めるときに、リフレクションを使用します。これは推論やコーディングのタスクで一般的です。", "solution": [ "回答を生成した後、同じモデルに対して、目標（およびテスト結果やエラーなどのツールからのフィードバック）に照らし合わせてそれを批判し、その批判を踏まえて修正された回答を生成するようにプロンプトを提示します。これを制限された回数だけ繰り返します。", "リフレクション（自己省察）は、過信につながるおそれのある純粋な自己評価よりも、実行エラー、テスト出力、取得された事実などの実際のシグナルに基づいている場合に最も効果的に機能します。" ], "components": [ "初期生成", "自己批判ステップ", "グラウンディングシグナル（エラー / テスト / 事実）", "修正", "イテレーションバジェット" ], "benefits": [ "単一のモデルで品質を向上させることができます。第2のシステムは不要です。", "ツールやテストのフィードバックに基づいている場合に効果的です。", "既存の呼び出しに簡単に追加できます。" ], "risks": [ "自己批判は過信に陥ったり、自身の誤りを見落としたりすることがあります。", "追加の呼び出しにより、レイテンシーとコストが増加します。", "グラウンディングがない場合、得られる効果は限定的です。" ], "whenNot": [ "客観的な外部チェックがある場合：evaluator-optimizer（評価者-最適化者）パターンを使用してください。", "1回のパスで既に基準を満たしている場合。", "レイテンシーバジェットが非常に厳しい場合。" ], "examples": [ "テストの失敗を読み取り、自身のパッチを修正するコーディングエージェント。", "回答する前にモデルが自身のステップを再確認する推論タスク。", "最終化する前に、モデルがギャップがないかレビューする下書き。" ], "productionEvidence": { "context": "レイテンシーやコストよりも出力品質が重視され（下書き作成、コード生成、分析など）、レビュー時にエラーを検出できるタスク。", "scenario": "最初の回答を生成した後、モデル（または別の批判者）が具体的な基準に照らし合わせてそれを評価し、修正版を生成します。このループは1回または2回のパスに制限されます。", "technology": "批判した後に修正するプロンプトチェーン。重要な業務においては、外部シグナル（テスト、ツール、別の評価者）に裏付けられていることが理想的です。", "load": "リフレクションのパスを実行するたびに呼び出し回数が少なくとも2倍になるため、オーバーヘッドに見合う出力に対してのみ選択的に適用されます。", "results": "観察されたパターン：リフレクションは、モデルが実際に自身の誤りを検出できる場合に品質を向上させますが、正しい回答を過剰に修正してしまう可能性があり、コストは少なくとも2倍になります。信頼する前に評価セットに対して品質の向上を測定し、リスクが高い場合は外部シグナルを優先してください。" }, "kpis": [ { "metric": "リフレクションによる品質向上", "note": "リフレクションステップがある場合とない場合での出力品質の測定された改善度。測定できない場合、そのステップはコストに見合っていません。" }, { "metric": "自己修正率", "note": "モデルがレビュー時に検出し、修正した本質的なエラーの割合（表面的な編集とは区別されます）。" }, { "metric": "追加のレイテンシーとコスト", "note": "リフレクションは呼び出し回数を少なくとも2倍にします。得られる品質に対してオーバーヘッドを追跡してください。" }, { "metric": "過剰修正率", "note": "リフレクションが、すでに優れた回答を疑うことによって、かえって品質を低下させてしまう頻度。" } ], "failureModes": [ "自己評価の盲点：モデルは自身の誤りに気づかないことが多く、リフレクションでそれらを見落とします。", "過剰修正：モデルが正しい回答を「修正」して、より悪いものにしてしまいます。", "品質の向上がわずかであるか、まったくないにもかかわらず、コストとレイテンシーが2倍（またはそれ以上）になります。", "誤った自信：出力が正しくないにもかかわらず、モデルが「正しくなった」と主張します。" ], "lessons": [ "向上度を測定すること。リフレクションは、品質が明らかに向上する場合にのみ価値があります。", "リスクが高い場合は、純粋な自己批判よりも外部シグナル（テスト、ツール、別の評価者）を優先してください。", "リフレクションは1回または2回のパスに制限すること。収益は急速に減少し、コストは累積します。", "リフレクションステップには、曖昧な「これを改善して」ではなく、具体的な基準を与えてください。" ], "faqs": [ { "q": "リフレクションとevaluator-optimizerのどちらを選ぶべきですか？", "a": "リフレクションは1つのモデルを使用して自己批判を行います（よりシンプル）。evaluator-optimizerは別の評価者を使用します（より鋭く、偏りが少ない）。タスクにおける自己評価の信頼性に基づいて選択してください。" }, { "q": "リフレクションは常に役立ちますか？", "a": "テスト結果やエラーなどの実際のフィードバックに基づいている場合に最も役立ちます。純粋な自己評価は過信につながりやすく、ほとんど効果がありません。" }, { "q": "リフレクションは何回行うべきですか？", "a": "回数を制限してください。通常は1回または2回です。収穫逓減とコストの増加により、長いループが価値に見合うことはほとんどありません。" } ] }, "zh": { "name": "反思", "summary": "反思让模型批判自己的输出，然后以该批判作为反馈进行修改。这是一种轻量级的、单模型的方法，用于在推理、编码和写作任务中发现错误并提高质量，代价是需要额外的调用。", "definition": "反思是一种模式，其中模型根据明确的标准审查和批判自己的输出，然后对其进行修改，以额外的推理换取更高的质量。", "problem": "模型往往会产生有缺陷的初步答案，如果提示它们审查自己的工作，它们本可以改进这些答案，但单次生成让它们没有机会这样做。", "context": "当自我审查步骤能够显著改善输出，且您希望使用一种比双模型评估器循环更简单的替代方案时，可以使用反思——这在推理和编码任务中很常见。", "solution": [ "在生成答案后，提示同一个模型根据目标（以及任何工具反馈，如测试结果或错误）对其进行批判，然后根据该批判生成修改后的答案。重复此过程，限制迭代次数。", "当反思基于真实信号（执行错误、测试输出、检索到的事实）而非纯粹的自我评估时，效果最好，因为纯粹的自我评估可能会过度自信。" ], "components": [ "初始生成", "自我批判步骤", "依据信号（错误/测试/事实）", "修改", "迭代预算" ], "benefits": [ "使用单个模型即可提高质量——无需第二个系统。", "当基于工具或测试反馈时非常有效。", "易于添加到现有的调用中。" ], "risks": [ "自我批判可能会过度自信，或者遗漏自身的错误。", "额外的调用会增加延迟和成本。", "如果没有依据，收益会很有限。" ], "whenNot": [ "当您有客观的外部检查时——使用评估器-优化器。", "当单次运行已达到标准时。", "当延迟预算非常紧张时。" ], "examples": [ "一个编码智能体读取测试失败信息并修复自己的补丁。", "一个推理任务，模型在回答前重新检查其步骤。", "模型在定稿前审查草稿是否存在漏洞。" ], "productionEvidence": { "context": "输出质量比延迟或成本更重要的任务（如起草、代码生成、分析），且在审查时可以检测到错误。", "scenario": "在生成第一个答案后，模型（或单独的批判器）根据具体标准对其进行评估，并生成修改后的版本；该循环限制在一次或两次运行内。", "technology": "一个“先批判后修改”的提示词链，对于高风险工作，最好有外部信号（测试、工具、单独的评估器）的支持。", "load": "每次反思运行至少会使调用次数翻倍，因此它被选择性地应用于那些值得付出此开销的输出。", "results": "观察到的模式：在模型确实能够检测到自身错误的情况下，反思可以提升质量，但它可能会对正确的答案进行过度修改，并且至少会使成本翻倍。在信任它之前，先根据评估集衡量质量提升，并在高风险情况下优先选择外部信号。" }, "kpis": [ { "metric": "反思带来的质量提升", "note": "衡量有反思步骤与没有反思步骤时输出质量的改进；如果无法衡量，则该步骤不值得其成本。" }, { "metric": "自我纠正率", "note": "模型在审查中捕获并修复的真实错误的比例——这与表面上的修改不同。" }, { "metric": "增加的延迟与成本", "note": "反思至少会使调用次数翻倍；跟踪该开销与它所换取的质量之间的关系。" }, { "metric": "过度修改率", "note": "反思因自我怀疑而降低原本优秀的答案质量的频率。" } ], "failureModes": [ "自我评估盲区：模型通常无法发现自己的错误，因此反思会遗漏这些错误。", "过度修改：模型将正确的答案“修复”成更差的答案。", "成本和延迟翻倍（或更多），而质量提升微乎其微或根本没有。", "盲目自信：模型在输出并不正确时，却断言其现在是正确的。" ], "lessons": [ "衡量提升幅度；只有在反思能明显提高质量的情况下，它才值得使用。", "在高风险情况下，优先选择外部信号（测试、工具、单独的评估器），而非纯粹的自我批判。", "将反思限制在一次或两次运行内——收益递减很快，且成本会成倍增加。", "为反思步骤提供具体的标准，而不是模糊的“改进这个”。" ], "faqs": [ { "q": "反思还是评估器-优化器？", "a": "反思使用一个模型进行自我批判（更简单）；评估器-优化器使用单独的评估器（更敏锐、偏见更少）。根据自我评估对您的任务有多可靠来做出选择。" }, { "q": "反思总是有效吗？", "a": "当基于测试结果或错误等真实反馈时，它的帮助最大。纯粹的自我评估可能会过度自信，且收效甚微。" }, { "q": "需要多少轮反思？", "a": "保持次数受限——通常是一到两轮。收益递减和成本上升使得长循环很少值得。" } ] } } }