HopeBot: Hope-Oriented Chatbot Design

• HopeBot is a design pattern for guided, supportive conversation that integrates affect recognition, structured prompts, and targeted feedback.
• The approach builds on EmpBot, using sentiment analysis and empathy or hope forcing to improve response fluency and user trust.
• HopeBot spans applications from mental health screening via PHQ-9 to educational nudging, emphasizing task fidelity, ethical safeguards, and actionable guidance.

Searching arXiv for the specified HopeBot and closely related papers to ground the article in current literature. HopeBot denotes a family of chatbot designs organized around supportive, hopeful interaction, with the most concrete published instantiation being a voice-interactive, retrieval-augmented large-language-model system for structured PHQ-9 depression screening, and with adjacent design proposals drawing on empathetic response generation and behavior-change recommendation architectures for hope-oriented support in other domains (Guo et al., 8 Jul 2025, Zaranis et al., 2021, Brown et al., 2021). Across these strands, the recurring technical theme is not unrestricted open-domain conversation, but guided interaction in which affect recognition, structured prompting, and targeted feedback are used to preserve task fidelity while maintaining a supportive tone. This suggests that HopeBot is best understood as an applied design pattern at the intersection of empathetic NLP, interactive assessment, and automated guidance rather than as a single canonical software artifact.

1. Conceptual scope and research lineage

In the literature provided here, HopeBot has three closely related but distinct meanings. First, it appears as a fully developed LLM-based chatbot that administers the Patient Health Questionnaire-9 (PHQ-9) through retrieval-augmented generation, real-time clarification, and voice interaction (Guo et al., 8 Jul 2025). Second, it appears as a proposed adaptation of EmpBot, a T5-based empathetic chatbot, in which sentiment understanding and empathy forcing are extended toward explicitly hopeful responses where appropriate (Zaranis et al., 2021). Third, it appears as a proposed educational bot grounded in developer recommendation choice architectures, where the intended function is to nudge students toward better software engineering behaviors through repository-local, actionable, and supportive recommendations (Brown et al., 2021).

The common denominator across these uses is the operationalization of hope as a conversational stance rather than as a purely lexical style. In the EmpBot-derived formulation, hopeful support means acknowledging negative feelings while “gently steering toward constructive, hopeful perspectives.” In the PHQ-9 system, it means preserving screening structure while providing interpretive guidance, supportive phrasing, and resource-linked recommendations. In the educational setting, it means using non-coercive nudges to reduce procrastination and improve process adherence. A plausible implication is that “hope” functions here as a control objective layered on top of domain-specific task constraints rather than as an independent end in itself.

2. Empathetic generation foundations

The most explicit generative foundation for HopeBot is the EmpBot framework, which is built on T5-base (HuggingFace), a Transformer encoder-decoder with 12 layers, $d_{\text{model}} = 768$, feed-forward hidden size $= 3072$, and 12 attention heads, using T5’s SentencePiece tokenizer (Zaranis et al., 2021). EmpBot is finetuned with three joint objectives: response language modeling, sentiment understanding, and empathy forcing. Response language modeling uses teacher-forced conditional generation over the gold response tokens. Sentiment understanding predicts binary speaker-context valence, where the 32 EmpatheticDialogues emotions are grouped into 15 positive and 17 negative categories. Empathy forcing then encourages similarity between the sentiment representation of the dialogue context and that of the response.

The sentiment component uses a 2-layer MLP on top of contextualized representations. Its first layer produces a 300-dimensional sentiment representation, denoted $c$ for the dialogue context and $r$ for the response, which is used both for sentiment classification and for the cosine-similarity-based empathy forcing loss. The core losses are:

$$L_{\mathrm{RLM}} = - \sum_{t=1}^{T} \log p_{\theta}(y_t \mid y_{<t}, x)$$

$$L_{\mathrm{sent}} = - \sum_{k \in \{\text{pos},\text{neg}\}} \mathbb{1}[k=s] \log p_{\theta}(k \mid x)$$

$$L_{\mathrm{emp}}(c,r) = 1 - \frac{c \cdot r}{\lVert c \rVert \, \lVert r \rVert}$$

$$L_{\mathrm{total}} = L_{\mathrm{RLM}} + \alpha L_{\mathrm{sent}} + \beta L_{\mathrm{emp}}$$

with $\alpha = 0.4$ and $\beta = 0.4$.

For HopeBot, the crucial detail is that “hopeful” already exists in the positive set of EmpatheticDialogues emotions. The design synthesis therefore proposes two possible extensions: adding a fine-grained emotion classifier, including explicit detection of “hopeful,” or introducing a ternary sentiment head in which “hope-positive” is separated from generic positivity. It also proposes a “hope forcing” variant in which negative contexts do not simply map to negative responses, but instead are acknowledged and then steered toward a hope-leaning target representation. This is formalized as:

$= 3072$0

where $= 3072$1 is set approximately to the identity for positive or hopeful contexts and maps negative contexts toward a hope target vector $= 3072$2, such as the mean 300-dimensional sentiment representation over training examples labeled “hopeful.” This suggests a shift from pure affect mirroring to conditional affect transformation.

3. Data, optimization, and empirical behavior in the empathetic-chatbot lineage

The empirical basis for the EmpBot-derived HopeBot design is the EmpatheticDialogues dataset, described as approximately 25k one-on-one open-domain conversations with an official 8:1:1 train/validation/test split and 32 dialogue-level emotion labels (Zaranis et al., 2021). Input formatting consists of concatenated dialogue context turns, with optional tags such as “Speaker:” and “Listener:”; the target is the listener’s response. The HopeBot-oriented guidance recommends additional prefixes such as “task: empathetic-generation” and style control tags such as “tone: hopeful.”

Training uses Adam with learning rate $= 3072$3, weight decay $= 3072$4, and batch size 4 on a single Tesla K80. Inference uses top-$= 3072$5 sampling with $= 3072$6, top-$= 3072$7, length penalty $= 3072$8, and maximum response length of 40 tokens. The baseline T5 has approximately 222M parameters, while EmpBot with the sentiment head has approximately 223M parameters.

Evaluation combines automated metrics and human judgments. On the test set, DD MT+FT reports perplexity $= 3072$9 and AVG BLEU $c$0; EmpBot reports perplexity $c$1 and AVG BLEU $c$2; baseline T5 reports perplexity $c$3 and AVG BLEU $c$4; and DD MT reports perplexity $c$5 and AVG BLEU $c$6. Human evaluation is more favorable to EmpBot. Against DD MT+FT, EmpBot wins 57.14% to 42.86% on Rel&Flu, 57.73% to 42.27% on Emp_sent, and 56.56% to 43.44% on Emp_emo. Against baseline T5, EmpBot wins 63.81% to 36.19% on Rel&Flu, 65.71% to 34.29% on Emp_sent, and 59.05% to 40.95% on Emp_emo. In 1–5 Likert ratings versus DD MT+FT, relevance is 3.48 versus 3.42, fluency is 4.21 versus 3.96, and empathy is 3.56 versus 3.33, with Mann-Whitney $c$7 significance reported for fluency and empathy at $c$8.

These results matter for HopeBot because they show that auxiliary affective objectives can improve perceived empathy and fluency even when automated generation metrics remain close to baseline. The reported failure case—baseline T5 responding “I’m sorry to hear that” to an “excited” context—illustrates a central design problem for hopeful systems: affective misalignment. At the same time, the HopeBot synthesis identifies a complementary risk: over-mirroring negative affect can produce bleak responses, whereas overly generic encouragement can become “performative empathy.” The proposed hope-specific forcing objective is therefore framed as a balance between validation and constructive uplift.

4. Developer recommendation choice architectures and the educational interpretation of HopeBot

A separate research lineage treats HopeBot not as an affective conversational model for mental-health screening, but as an automated agent that nudges students toward better software engineering behaviors by adapting the class-bot system and the developer recommendation choice architectures framework (Brown et al., 2021). The theoretical basis comes from nudging and choice architecture, operationalized for software development through three principles introduced by Brown and Parnin: Actionability, Feedback, and Locality.

Actionability means automatically analyzing repositories and surfacing concrete next steps without requiring students to fetch feedback manually. Feedback means presenting clear status signals, in this case simple binary indicators such as a red x for unmet rubric items and a green check for met items. Locality means placing recommendations where and when students work: spatially within GitHub issues and temporally through daily updates tied to repository activity. The decision logic centers on signals such as commit activity, time until first commit, code churn, build status, unit tests, functional tests, Checkstyle warnings, repository hygiene, and rubric-phase completion across Requirements, Design, Implementation, Unit Testing, System/Functional Testing, and Deployment.

The class-bot study analyzed 35 students and 151 repositories in an introductory Java programming course over approximately six weeks. Projects 3–5 served as control assignments, and the bot was introduced on the final two assignments. Statistical comparisons used the Mann-Whitney-Wilcoxon test at $c$9. The reported outcomes were: mean grade 74.29 without nudges versus 76.89 with nudges, median grade 87.66 versus 95, with $r$0; deductions mean $r$1 versus $r$2, with $r$3; commits mean 9.84 versus 12.64, with $r$4; code churn mean 205.03 versus 1101.57, with $r$5; first commit time mean 8.32 days versus 1.99 days, with $r$6; and last commit time mean $r$7 hours versus $r$8 hours, with $r$9.

In this interpretation, HopeBot is a support bot whose “hopefulness” is embodied in non-coercive, action-oriented process guidance rather than in emotional dialogue. The synthesis recommends repository-local issue updates, daily or commit-triggered notifications, prioritization of blocking failures such as compile errors and missing tests, and escalation policies for prolonged inactivity. This suggests a broader conceptualization of hope in HCI: not only emotional reassurance, but also the presentation of tractable next actions that reduce paralysis and support agency.

5. HopeBot as an LLM-based PHQ-9 screening system

The most fully specified HopeBot in the literature is “Development and Evaluation of HopeBot: an LLM-based chatbot for structured and interactive PHQ-9 depression screening,” which positions the system as a response to the limitations of static self-administered questionnaires (Guo et al., 8 Jul 2025). HopeBot is designed to preserve the structure and scoring fidelity of PHQ-9 while adding real-time clarification, interpretive guidance, supportive tone, and bilingual voice interaction.

Its architecture centers on GPT-4o for dialogue, retrieval-augmented generation for evidence grounding, and an ASR/TTS voice pipeline. The retrieval stack uses LangChain and Chroma vector stores, with knowledge sources comprising 34 anonymized CBT session transcripts and structured CBT educational materials including A Therapist’s Guide to Brief CBT, emotion-support corpora (ESConv in English and PsyQA in Chinese), and bilingual helpline directories for the UK and China. Preprocessing uses recursive character chunking with 512-token segments and 20% overlap. Embeddings are generated with text-embedding-3-small. Retrieval runs in parallel across vector stores, and the top passages are concatenated into the GPT-4o prompt; item scoring, clarification logic, and phrasing are prompt-controlled. The knowledge base and prompts were refined through feedback from an NHS psychiatrist, two UCL doctoral researchers, and a licensed counselor in China.

The system prompt imposes role and scope constraints: screening support rather than diagnosis, explicit disclosure that the bot is not a clinician, crisis keyword triggers that interrupt the session and route the user to country-specific helplines, and a mandatory transition to PHQ-9 within 20 turns. Privacy provisions include GDPR-compliant anonymization, no personally identifiable data, OpenAI API data retention disabled, and access only to the most recent audio response per turn. The voice stack uses OpenAI Whisper for ASR and OpenAI TTS-1 with voice “sage” for synthesis. Mean latency is $$L_{\mathrm{RLM}} = - \sum_{t=1}^{T} \log p_{\theta}(y_t \mid y_{<t}, x)$$0 s for LLM responses, approximately $$L_{\mathrm{RLM}} = - \sum_{t=1}^{T} \log p_{\theta}(y_t \mid y_{<t}, x)$$1 tokens per turn, $$L_{\mathrm{RLM}} = - \sum_{t=1}^{T} \log p_{\theta}(y_t \mid y_{<t}, x)$$2 s for TTS, and approximately $$L_{\mathrm{RLM}} = - \sum_{t=1}^{T} \log p_{\theta}(y_t \mid y_{<t}, x)$$3 s total per turn. Incremental text rendering precedes audio playback, and users can pause or skip audio. The system supports native English and Mandarin generation without translation, though Mandarin TTS is described as using a general engine and participants noted prosodic limitations.

HopeBot’s administration flow has three phases: rapport building with a limit of 20 turns, sequential delivery of PHQ-9 items 1–9, and personalized feedback. When a response is vague, fuzzy, or inconsistent with earlier turns, the system asks clarifying follow-ups tied to the PHQ-9 response anchors. It does not advance to the next item until a categorical decision is reached for the current one. Scoring follows the standard PHQ-9 formulation:

$$L_{\mathrm{RLM}} = - \sum_{t=1}^{T} \log p_{\theta}(y_t \mid y_{<t}, x)$$4

with response anchors A $$L_{\mathrm{RLM}} = - \sum_{t=1}^{T} \log p_{\theta}(y_t \mid y_{<t}, x)$$5 (“not at all”), B $$L_{\mathrm{RLM}} = - \sum_{t=1}^{T} \log p_{\theta}(y_t \mid y_{<t}, x)$$6 (“several days”), C $$L_{\mathrm{RLM}} = - \sum_{t=1}^{T} \log p_{\theta}(y_t \mid y_{<t}, x)$$7 (“more than half the days”), and D $$L_{\mathrm{RLM}} = - \sum_{t=1}^{T} \log p_{\theta}(y_t \mid y_{<t}, x)$$8 (“nearly every day”). The severity bands used in the study are 0–4 minimal, 5–9 mild, 10–14 moderate, 15–19 moderately severe, and 20–27 severe.

6. Study results, interpretation, and limits of the screening system

The HopeBot screening study used a within-subject design in which 132 adults from the United Kingdom and China completed a self-administered PHQ-9 first, then a HopeBot-assisted PHQ-9 session, followed by a 25-item survey (Guo et al., 8 Jul 2025). Recruitment age was 18–70; 51.5% were from the UK and 48.5% from China; 54.5% were female; 88.7% were degree-educated; 64.4% were regular LLM users; 42.4% had tried mental-health chatbots; and 19.7% had prior professional mental-health support. The HopeBot interaction took approximately 25 minutes, and the post-session survey approximately 35 minutes.

Agreement between the self-administered and chatbot versions was strong. Identical total scores were observed for 59 of 132 participants, or 44.7% (approximately 45%). The median absolute difference was 1, with IQR $$L_{\mathrm{RLM}} = - \sum_{t=1}^{T} \log p_{\theta}(y_t \mid y_{<t}, x)$$9 and mean absolute difference $$L_{\mathrm{sent}} = - \sum_{k \in \{\text{pos},\text{neg}\}} \mathbb{1}[k=s] \log p_{\theta}(k \mid x)$$0. Signed differences had median $$L_{\mathrm{sent}} = - \sum_{k \in \{\text{pos},\text{neg}\}} \mathbb{1}[k=s] \log p_{\theta}(k \mid x)$$1 and mean $$L_{\mathrm{sent}} = - \sum_{k \in \{\text{pos},\text{neg}\}} \mathbb{1}[k=s] \log p_{\theta}(k \mid x)$$2. The Wilcoxon signed-rank test yielded $$L_{\mathrm{sent}} = - \sum_{k \in \{\text{pos},\text{neg}\}} \mathbb{1}[k=s] \log p_{\theta}(k \mid x)$$3, $$L_{\mathrm{sent}} = - \sum_{k \in \{\text{pos},\text{neg}\}} \mathbb{1}[k=s] \log p_{\theta}(k \mid x)$$4, indicating no systematic over- or under-scoring. Spearman’s correlation was $$L_{\mathrm{sent}} = - \sum_{k \in \{\text{pos},\text{neg}\}} \mathbb{1}[k=s] \log p_{\theta}(k \mid x)$$5, $$L_{\mathrm{sent}} = - \sum_{k \in \{\text{pos},\text{neg}\}} \mathbb{1}[k=s] \log p_{\theta}(k \mid x)$$6. The reported ICC(3,1), defined in general form as

$$L_{\mathrm{sent}} = - \sum_{k \in \{\text{pos},\text{neg}\}} \mathbb{1}[k=s] \log p_{\theta}(k \mid x)$$7

was 0.91 with 95% CI 0.88–0.93. Severity-category changes across formats occurred for 28.0% of participants due to boundary shifts.

Acceptability findings were similarly strong. Among the 75 participants who provided comparative trust feedback, 70.7% trusted the chatbot result more, 18.7% trusted self-report more, and 10.7% rated both equally. Mean ratings on 0–10 scales were 7.60 for handling sensitive topics, 8.44 for comfort expressing feelings, 7.36 for helpfulness of recommendations, and 7.73 for voice clarity/tone. Overall, 87.1% expressed willingness to reuse or recommend HopeBot. On interaction quality, 79.5% reported that the PHQ-9 introduction felt natural, 97.7% found the instructions easy to understand, 77.3% said the overall conversation felt natural, and 33.3% requested clarification, of whom 93.2% found the explanations helpful.

Subgroup analyses found that recommendation helpfulness varied by employment status, with ANOVA $$L_{\mathrm{sent}} = - \sum_{k \in \{\text{pos},\text{neg}\}} \mathbb{1}[k=s] \log p_{\theta}(k \mid x)$$8, $$L_{\mathrm{sent}} = - \sum_{k \in \{\text{pos},\text{neg}\}} \mathbb{1}[k=s] \log p_{\theta}(k \mid x)$$9. Participants with prior mental-health service use gave lower Q19 recommendation-helpfulness ratings than those without such prior use, with $$L_{\mathrm{emp}}(c,r) = 1 - \frac{c \cdot r}{\lVert c \rVert \, \lVert r \rVert}$$0, $$L_{\mathrm{emp}}(c,r) = 1 - \frac{c \cdot r}{\lVert c \rVert \, \lVert r \rVert}$$1, while no differences were found for Q17, Q18, or Q20 at $$L_{\mathrm{emp}}(c,r) = 1 - \frac{c \cdot r}{\lVert c \rVert \, \lVert r \rVert}$$2. Trust versus severity was significant under $$L_{\mathrm{emp}}(c,r) = 1 - \frac{c \cdot r}{\lVert c \rVert \, \lVert r \rVert}$$3, $$L_{\mathrm{emp}}(c,r) = 1 - \frac{c \cdot r}{\lVert c \rVert \, \lVert r \rVert}$$4, $$L_{\mathrm{emp}}(c,r) = 1 - \frac{c \cdot r}{\lVert c \rVert \, \lVert r \rVert}$$5, but this was not supported by a linear-trend logistic model with OR $$L_{\mathrm{emp}}(c,r) = 1 - \frac{c \cdot r}{\lVert c \rVert \, \lVert r \rVert}$$6, 95% CI 0.79–2.20, $$L_{\mathrm{emp}}(c,r) = 1 - \frac{c \cdot r}{\lVert c \rVert \, \lVert r \rVert}$$7.

The paper’s interpretation is that HopeBot functions as a scalable, low-burden adjunct rather than as a diagnostic replacement. That conclusion is bounded by several limitations: the reference standard was self-administered PHQ-9 rather than clinician interview; order effects are possible because self-report always preceded the chatbot; the sample was relatively young and digitally literate; some users reported ASR slowness or inaccuracy, with 32 mentions accounting for 9.3% of comments; Mandarin TTS was seen as weaker than English; and some content was perceived as generic. The system is also explicitly model-dependent, with findings tied to GPT-4o.

7. Safety, ethics, and prospective development

Safety and ethics are central to all HopeBot variants, but they are especially explicit in the PHQ-9 implementation (Guo et al., 8 Jul 2025). The system is non-diagnostic and non-emergency by design, repeatedly discloses that it is not a clinician, and routes crisis-language cases to country-specific helplines such as Samaritans 116 123 in the UK and major psychiatric institutions in China. It uses GDPR-compliant anonymization, disabled model data retention, restricted audio replay, and authorized-researcher access; the study reports UCL ethics approval (ID: 26133.001) and ClinicalTrials.gov registration (NCT06801925).

The HopeBot-oriented synthesis built on EmpBot raises a related but distinct ethical problem: “false hope” or toxic positivity can emerge if a system steers too aggressively toward optimistic affect in contexts such as grief or crisis (Zaranis et al., 2021). The recommended mitigation is gentle, non-dismissive hope, with acknowledgment preceding encouragement, explicit crisis detection, and escalation to human resources when needed. The educational HopeBot synthesis adds concerns about transparency, consent, data minimization, and the possibility of anxiety or over-reliance if feedback becomes overly frequent or punitive (Brown et al., 2021). Its recommended design response is supportive, non-coercive phrasing, opt-in notification preferences, and clear explanation of what data are collected and how recommendations are generated.

Future directions differ by domain but converge on stronger control, validation, and governance. For empathetic generation, proposed next steps include using raw emotion values rather than coarse polarity, learning a hope vector with disentangled attributes such as acknowledgment and future orientation, and reinforcement learning from human feedback with constraints against dismissiveness (Zaranis et al., 2021). For the screening system, future work includes multisite validation against clinician-administered interviews, referral-accuracy studies, workflow integration such as EHR routing, multilingual expansion, and clinician-in-the-loop review for high-risk disclosures (Guo et al., 8 Jul 2025). For educational nudging, prospective extensions include commit-triggered updates, CI or IDE integrations, assignment-specific weighting, and stronger experimental designs with effect sizes and confidence intervals (Brown et al., 2021).

Taken together, these strands indicate that HopeBot is not reducible to a single application domain. It is a research object defined by the attempt to join structured task performance with supportive interaction: in mental-health screening, by preserving PHQ-9 fidelity while clarifying ambiguous answers; in empathetic dialogue generation, by combining sentiment understanding with empathy or hope forcing; and in educational process support, by transforming repository telemetry into actionable nudges. The unifying technical problem is how to encode hope as a controlled, context-sensitive behavior without sacrificing validity, safety, or task specificity.