jpmschweitzerandClaude Opus 4.6
2a6a023196
Standardized YAML frontmatter on all 28 files. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
64 lines
3.3 KiB
Markdown
64 lines
3.3 KiB
Markdown
---
|
|
title: "Round 3 Inputs"
|
|
description: "Binding decisions from Jeroen after rounds 1-2 as inputs for round 3"
|
|
type: workshop
|
|
status: archived
|
|
workshop: llm-voice-pipeline
|
|
agent: ""
|
|
round: 3
|
|
created: 2026-03-07
|
|
---
|
|
|
|
# LLM Voice Pipeline Workshop — Round 3 Inputs
|
|
|
|
**Source:** Team lead interview with Jeroen after Rounds 1-2
|
|
**Date:** 2026-03-07
|
|
|
|
---
|
|
|
|
## Jeroen's Decisions
|
|
|
|
These are binding inputs for Round 3. The team produces the D-record and implementation plan around these.
|
|
|
|
### 1. Scope: Behaviors + Dialogue (full pipeline)
|
|
"We don't introduce a precision laser cutting tool and then use it only to open boxes." Both observable behaviors AND dialogue get re-voiced. This is the long-term architecture.
|
|
|
|
### 2. Tell Treatment: Passthrough with Context Influence
|
|
Tells are mechanical signals, not culture. They stay as base text — always. Swapping them confuses the player.
|
|
|
|
However, tells INFORM the LLM context for dialogue and behavior. When a player engages an NPC who has an avoidance tell, the NPC's dialogue should be phrased in an avoiding way. The tell itself is untouched; the tell's presence shapes the re-voicing prompt for surrounding content.
|
|
|
|
This is a critical distinction: tells are read-only inputs to the LLM, never LLM outputs.
|
|
|
|
### 3. Spike Strategy: Two Spikes
|
|
**Spike 1 — Plumbing + Quality (no integration):**
|
|
- Build the Rust llama-cpp-rs wrapper. Load Gemma 2B and Phi-3. Prove the plumbing works: accept prompt, return text.
|
|
- Then Jeroen, Mellanie, and Paula manually craft prompts — culture injectors, behavior seeds, dialogue seeds — and feed them through by hand.
|
|
- Test both models against the same prompts. Answer the question: "does this even play?"
|
|
- No game integration, no queue, no cache. Just the inference tool and manual prompt experimentation.
|
|
|
|
**Spike 2 — Integration:**
|
|
- Wire the validated runner into the pre-voicing pipeline.
|
|
- Queue, cache-as-determinism, thread pool isolation, baked content generation, fallback behavior.
|
|
- The full architecture as designed by the team.
|
|
- Uses whichever model won Spike 1.
|
|
|
|
### 4. D-123 Amendment
|
|
Amend D-123 to cover both baked (build-time, human-reviewed) and pre-voiced (runtime background) modes. Supersede D-124. Paula's distinction between the two modes must be explicit in the amended record.
|
|
|
|
### 5. Model Provenance
|
|
Strong preference against Chinese-origin models (Qwen/Alibaba). Gemma (Google) is the primary candidate. Phi (Microsoft) is the fallback. Reconsider the constraint only if benchmarks on both fail to meet the quality bar.
|
|
|
|
### 6. Distribution: Bundled
|
|
Model ships with the game install. No optional download step. ~1.5GB added to install size is acceptable.
|
|
|
|
### 7. Hardware Detection: Layered
|
|
- Layer 1: CPU/RAM check — can the model even load?
|
|
- Layer 2: Time-per-token benchmark on first enable — is inference fast enough to be useful?
|
|
- Layer 3: Recommendation to disable if below threshold, but player can always override
|
|
- No hard minimum spec floor. If they're patient, let them run it.
|
|
- Always an option to disable ("AI-Enhanced Dialogue" toggle).
|
|
|
|
### 8. No Minimum Spec Floor
|
|
The question isn't "what hardware do we refuse to run on" — it's "when do we recommend turning it off." The system runs on anything that passes the RAM check; the recommendation threshold handles the rest.
|