Qwen3.8-27B Humanlike Chat 2.0: Natural Conversations Plus Tool Calling

A fine-tuning project aimed at making LLMs "talk like a real person" just got a major upgrade. Developer LessThanThreeAI has released Qwen3.8-27B-Humanlike-Chat 2.0, preserving the well-loved "human feel" of the original while addressing key shortcomings around tool calling and instruction following.

Starting with a Version That Was Both Praised and Criticized

A month ago, this developer posted a LoRA fine-tuned model based on Qwen3.8-27B on Reddit, with a single core goal: make the model talk like a real person, not an assistant. The idea struck a nerve — the post received 700+ upvotes, 248 comments, and the model was downloaded 44,000 times.

The developer admits to reading every single comment. Users were genuinely tired of "assistant speak," so the model's tone resonated. But everything else got ruthlessly criticized — and fairly so:

• It could only squeeze out a few words at a time and couldn't produce complete content
• It had a single default personality that no amount of prompting could override
• It had zero tool calling capability

Worse, when you asked it to do something, it would sometimes just say "I'm busy" or "I'm going to sleep." The "human feel" had gone a bit too far — like a real person, but the bad kind. The developer spent three weeks refining version 2.0 with a clear goal: keep what people liked about the tone, and ditch the drawbacks.

What's Actually Improved in 2.0

The new version makes several key adjustments to the interaction experience, finding a middle ground between "feeling human" and "being usable."

Defaults to a normal person texting. Without a system prompt, it behaves like a regular person sending text messages — not an assistant, not a fictional character. Give it a character card and it becomes that character, still typing in a human way.

Can switch gears when needed. Ask it to write a formal email, list numbered steps, or provide a complete explanation, and it executes precisely, then switches back to casual chat mode. If you don't like the all-lowercase texting style, just tell it "use complete sentences from now on" (or put it in the system prompt) and it'll stick to that until you say otherwise. The original version completely ignored these kinds of instructions.

Tool calling actually works. This is the part the developer is most proud of. It calls tools and proactively asks for missing information instead of making things up. For example: ask the base model to book a flight without mentioning your departure city, and it'll invent JFK; 2.0 will ask where you're departing from. Coding and math capabilities are roughly maintained at the base model level.

One-line positioning: it's a colleague, a humanized companion — not an assistant. Suitable for casual chat, roleplay, agent workflows, or actual work tasks.

Training Approach: From SFT to On-Policy Distillation

The difference in training philosophy between the two versions is key to understanding this upgrade.

The original used standard supervised fine-tuning (SFT) with data from 139,845 real and synthetic messages across 1,396 conversations. This approach directly copies conversational habits — including the bad ones. The model learned the tone, but also learned to refuse work with things like "I'm going to sleep."

2.0 switched to on-policy distillation: the model generates its own responses, and teacher models score every token. Two teachers were used:

• The original model with a hidden "type like a real human" instruction, handling chat and roleplay
• The pure base model, handling instruction following, tool calling, and code

The key design choice: the student model never sees that hidden instruction from start to finish, so it learns the behavior itself rather than relying on a prompt to trigger it. The backbone is still the same 27B model, with a second LoRA added on top and merged.

Background: SFT vs. On-Policy Distillation

Supervised fine-tuning (SFT) is currently the most common alignment approach: prepare a batch of input→expected output example pairs and have the model directly imitate the distribution of those outputs. It's simple and stable, but the fatal flaw is that models just "copy answers" — whatever bad habits are in the data get learned too, with no self-correction mechanism.

On-policy distillation is a reinforcement learning variant. "On-policy" means using the current version of the student model to sample outputs in real time, then having teacher models score them to generate training signals — rather than using a fixed offline dataset. This mechanism ensures the student model always trains on its own actual output distribution, avoiding the common SFT problem of distribution shift (the gap between training data distribution and what the model actually generates). Unlike standard knowledge distillation — which typically involves offline, fixed soft-label matching — on-policy distillation continuously updates sampling as training progresses, giving the student model broader exploration and faster error correction. This explains how 2.0 could simultaneously learn both "human-like tone" and "knowing when not to call a tool" — two very different capabilities.

Benchmark Results: Where It Got Better, Where It Didn't

The developer used huihui-ai's abliterated version of Qwen3.8-27B as the baseline, running comparisons with identical prompts, identical run conditions, and thinking mode disabled.

Benchmark	Base Model	2.0
IFBench (instruction types not seen during training)	37.3	43.7
When2Call (correctly calling/asking/refusing)	48	58
BFCL irrelevance (not calling tools when none are appropriate)	60	78
IFEval / GSM8K / BFCL simple	81.9 / 89.1 / 97	83.5 / 89.1 / 98

The improvements in instruction following and tool judgment are substantial — especially BFCL irrelevance jumping from 60 to 78, showing the model has a much better sense of when not to call a tool.

The tradeoffs are also honestly listed: knowledge-heavy capabilities declined (MMLU-Pro 72.5 vs. base model's 78.5), and competition-level coding dropped (LiveCodeBench 51 vs. 56). This is a typical tradeoff for a humanization-oriented model — trading some hard knowledge density for more natural conversation.

A note on these benchmarks: IFBench specifically tests a model's ability to generalize to instruction formats not seen during training — a high score means "genuinely understanding instructions" rather than memorizing them. When2Call evaluates tool-calling judgment across three scenarios: calling the right tool when appropriate, asking for clarification when information is missing, and refusing when the situation doesn't call for it. BFCL irrelevance (Berkeley Function Calling Leaderboard's irrelevant tools subset) specifically checks whether models incorrectly force tool calls when no suitable option exists in the available tool list — the 60→78 jump shows a major improvement in "tool restraint." MMLU-Pro, covering knowledge-intensive QA across medicine, law, math, and other professional domains, confirms the dilution effect that humanization fine-tuning has on knowledge retention density. LiveCodeBench continuously adds competition-level programming problems and reflects the coding style drift from SFT training.

Does It Actually Feel More Human?

To validate the subjective goal of "human feel," the developer built a benchmark called "ishuman": take 150 unseen chat fragments, have each model generate the next message, then present the model's response alongside an actual human's real reply to a judge (without labels) and ask which one was written by a person.

Model	% judged as human (50% = indistinguishable)
Qwen3.8-27B abliterated (training base)	0.3%
Same model + "type like a human" system prompt	6.8%
Qwen3.8-27B official release (OpenRouter)	15.1%
Qwen3.8-27B-Humanlike-Chat 2.0	23.5%

This data makes a compelling point: stacking prompts can't achieve genuine humanization — the same base model with a prompt only reaches 6.8%, while fine-tuning gets to 23.5%. In a separate real-world test of 16 multi-turn human conversations, 2.0 beat the base model 16-0.

On the ishuman benchmark design: This evaluation is essentially a simplified Turing test. Rather than requiring judges to interact with models over extended periods, it gives all parties the same conversational context and compares single-response "human feel." The threshold is set at 50% — if a judge guesses randomly, the expected accuracy is exactly 50%, so the closer a model's score is to 50%, the harder it is to identify as non-human. 23.5% may seem low, but in a landscape where models are almost instantly identified (the base model scores just 0.3%), it represents a significant relative improvement. This also reveals a deeper issue: the "assistant speak" baked into current LLMs is so deeply ingrained that prompt engineering alone is nearly powerless to fundamentally change output style — the behavior must be internalized into the model's weights through training.

Where to Get It

The model is available on Hugging Face with multiple GGUF quantization options (IQ4_XS, Q4_K_M, Q5_K_M, Q6_K, Q8_0, BF16) along with a standalone LoRA and an online demo space for direct testing.

What makes this project most worth watching isn't just "making a model sound human" as an end in itself — it's the clear engineering path it demonstrates: using dual-teacher on-policy distillation to let different teachers shape "tone" and "capability" separately, achieving both natural conversation and reliable tool calling simultaneously. This has direct practical value for locally-deployed roleplay and companion agent scenarios. The developer continues to gather community feedback, and is especially interested in hearing where it still sounds like an assistant.