• exec/chat_llm.js

    From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Friday, May 29, 2026 23:59:56
    https://gitlab.synchro.net/main/sbbs/-/commit/1f72bd03d5d4bb38b1ea543a
    Modified Files:
    exec/chat_llm.js
    Log Message:
    chat_llm: skip RAG for identity/social queries

    inject_retrieval() fired on any query whose top BM25 hit cleared the
    score floor -- including self-referential questions like "what's your
    name?" (the token "name" scores well), injecting board/wiki chunks that
    the model then conflated with its own identity ("I'm Vertrauen BBS").
    Add _is_conversational_query() and gate inject_retrieval() on it:
    identity ("who/what are you", "your name", "are you a bot/sysop"),
    capability, and social-pleasantry queries now retrieve nothing and are
    answered from the system prompt's identity rules alone. Kept narrow so
    genuine knowledge questions (incl. "who is the sysop?") still retrieve.

    Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Friday, May 29, 2026 23:59:57
    https://gitlab.synchro.net/main/sbbs/-/commit/12a8cf565d4f4f2433698081
    Modified Files:
    exec/chat_llm.js
    Log Message:
    chat_llm: mechanical-phrasing rewrite tolerates an adjective

    "No relevant hits found for X" slipped past the empty-result rewrite
    because an adjective ("relevant"/"matching"/"specific"/...) sat between
    "no" and the noun. Allow an optional adjective in both the "no <noun>"
    and "couldn't find any <noun>" branches.

    Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Sunday, May 31, 2026 19:06:06
    https://gitlab.synchro.net/main/sbbs/-/commit/833cf8fc7bd53a679d83dd04
    Modified Files:
    exec/chat_llm.js
    Log Message:
    chat_llm: route issue priority/recommendation queries to git_issues

    classify_intent had no rule for issue queries phrased by importance, so the model free-formed and fabricated issue numbers + titles (observed in #synchronet: #12345 "Enhance Security Flags", then #98765 after being told it was hallucinating). Add routes so these reach the tool and the model picks from REAL issues:
    - "highest priority / most critical / most important (etc.) issue" and
    "which issue would you recommend" -> git_issues kind=recent (opened)
    - "most recent / latest / last (open|closed) issue" (singular / embedded,
    e.g. "poem about the most recently closed gitlab issue") -> git_issues
    recent, state from the open/closed word (fixes the model inventing a
    lookup iid:12345 for "most recently closed issue")
    Guarded against false positives -- "I have a critical issue with X" stays unrouted.

    Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Monday, August 10, 2026 03:17:45
    https://gitlab.synchro.net/main/sbbs/-/commit/a7718428415a389396c1ec21
    Modified Files:
    exec/chat_llm.js
    Log Message:
    chat_llm: treat a repeated question as a failed answer

    Reply-text similarity cannot detect a stuck conversation. A user asked
    the same question three times running and got three answers that meant
    the same thing but scored only 0.33-0.58 against each other, because
    the model rewords itself at this temperature. Genuinely new answers on
    a single topic score 0.42-0.62, so the ranges overlap and no threshold separates them.

    The question itself is the reliable signal: someone retyping what they
    just asked is telling you the previous answer did not land, whatever
    its wording. When the incoming question matches one of that speaker's
    own recent questions, the previous answer is treated as a repeat
    outright, bypassing the similarity test, and the existing regenerate- then-deflect path runs.

    Only the speaker's own turns are compared -- the bot restating a
    question back is not the user asking twice. Similarity still governs
    whether the REGENERATED answer counts as another repeat, at a looser
    threshold, since the strict one would essentially never fire there.
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)