In the Code of 'Japan's Strongest AI' Lies the Cruel Truth About Global AI

目录

“The ‘light of Japanese AI’ we thought we had, when peeled open, turns out to be a DeepSeek ‘suit.’ Japanese netizens were devastated, but as someone in tech, what I see is the whole industry’s ‘emperor’s new clothes.’”

Introduction: The Disillusionment of “Techno-Nationalism”

Recently there was a rather interesting incident in AI circles — the model from Rinna, billed as “Japan’s strongest AI,” was exposed as using a large amount of DeepSeek code directly, without even cleaning up the comments. Japanese netizens collectively broke down, feeling as if the flag of their own “techno-nationalism” had suddenly fallen.

But honestly, as a tech veteran who has slogged through the internet industry for over a decade, my first reaction to this news was: “Isn’t that pretty normal?” Anyone who has built enterprise systems knows that in today’s fast-iterating technology landscape, building wheels completely from scratch means you’re either a genius or a fool.

Background: Why Did This Cause “Breakdown”?

This incident caused such a big stir for several deep-seated reasons:

1. The emotional projection of techno-nationalism
Japan fell behind in the internet era, and AI was seen by many as a chance to “overtake on the curve.” Rinna was packaged as the “light of Japan,” carrying too much national emotion. When that flag was found to be a “rebrand,” the emotional backlash was naturally strong.

2. The AI industry’s “black-box” nature
Training a large model typically needs thousands of GPUs, months of training time, and tens of millions of dollars in cost. To the outside world this process is a black box. If you say you trained an “original model,” then unless you open-source all the code and training data, it’s hard to falsify.

3. Media over-packaging
“Strongest,” “disruptive,” “revolutionary”… these words are worn threadbare in AI reporting. The media needs stories, capital needs concepts, users need “miracles,” and the three forces together package tech products into “myths.”

Technical Breakdown: Peeling Off the “Original” Coating to See the Essence

Let’s skip the fluff and go straight to the code. From a technical-architecture standpoint, this is actually quite transparent.

1. “Reuse” of model architecture is the industry norm

First, a simple comparison:

# DeepSeek-V2's attention mechanism implementation (simplified)
class DeepSeekAttention(nn.Module):
    def __init__(self, config):
        super().__init__()
        self.num_heads = config.num_heads
        self.head_dim = config.hidden_size // config.num_heads
        self.qkv_proj = nn.Linear(config.hidden_size, 3 * config.hidden_size)
        self.out_proj = nn.Linear(config.hidden_size, config.hidden_size)
    
    def forward(self, hidden_states):
        # QKV projection
        qkv = self.qkv_proj(hidden_states)
        # split heads
        q, k, v = qkv.chunk(3, dim=-1)
        # attention computation
        attn_weights = torch.matmul(q, k.transpose(-2, -1))
        attn_weights = attn_weights / math.sqrt(self.head_dim)
        attn_probs = F.softmax(attn_weights, dim=-1)
        # output
        attn_output = torch.matmul(attn_probs, v)
        return self.out_proj(attn_output)

# Rinna's exposed code (suspected)
class RinnaAttention(nn.Module):
    def __init__(self, config):
        super().__init__()
        self.num_heads = config.num_attention_heads  # variable name tweaked
        self.head_dim = config.hidden_size // config.num_attention_heads
        self.query_key_value = nn.Linear(config.hidden_size, 3 * config.hidden_size)  # variable name tweaked
        self.dense = nn.Linear(config.hidden_size, config.hidden_size)  # variable name tweaked
    
    def forward(self, hidden_states):
        # exactly the same logic, only the variable names differ
        mixed_qkv = self.query_key_value(hidden_states)
        query, key, value = mixed_qkv.chunk(3, dim=-1)
        # ... the rest of the code is almost identical

Key findings:

• The architectural design is highly similar (a Transformer variant)
• The attention mechanism implementation is almost identical
• Even the naming habits of some non-critical variables are the same
• But the training data, parameter initialization, and optimization strategy may differ

2. The large-model tech stack is already highly standardized

From an engineering standpoint, today’s large-model tech stack has formed a de facto standard:

┌─────────────────────────────────────────────┐
│               Application layer             │
│  - chat interfaces, API services, business integration │
├─────────────────────────────────────────────┤
│             Model fine-tuning layer         │
│  - LoRA/QLoRA adapters                      │
│  - P-Tuning prompt tuning                   │
│  - instruction fine-tuning (IFT)            │
├─────────────────────────────────────────────┤
│       Pre-trained model layer (core)        │
│  - Transformer architecture variants        │
│  - attention mechanism optimization         │
│  - positional encoding schemes              │
├─────────────────────────────────────────────┤
│             Infrastructure layer            │
│  - PyTorch/TensorFlow frameworks            │
│  - CUDA acceleration                        │
│  - distributed training frameworks          │
└─────────────────────────────────────────────┘

The reality is: 90% of teams use the same tech stack; the differences are only in:

1. Data quality and quantity
2. Scale of compute resources
3. Engineering optimization details
4. Fine-tuning strategy and domain adaptation

3. The real meaning of “original” has changed in the AI era

In the traditional software era, “original” meant the algorithm design and code implementation were all your own. But in the large-model era:

• Architectural innovation is getting harder: after the Transformer, there’s been no revolutionary new architecture
• Engineering optimization has become the core competitiveness: how to train a better model with fewer resources
• Data barriers are the real moat: high-quality, large-scale, domain-specific data
• Application innovation may be more valuable than underlying innovation: how to put large models into real scenarios

My Cool-Headed Thinking: A Few Overlooked Truths

As a veteran who has lived through several technology waves, I have a few somewhat different views:

1. “Borrowing” is the norm in technological evolution, not an original sin

Looking back at history:

• The Linux kernel borrowed design ideas from Minix
• Android is based on the Linux kernel
• Chrome is based on WebKit (only later developing Blink in-house)
• Even Python’s and JavaScript’s standard libraries borrowed heavily from predecessors

The key difference is: whether you honestly credit the source, whether you comply with the open-source license, and whether you make valuable improvements on the basis.

Rinna’s problem isn’t “using someone else’s code” but “packaging it as fully original.” That’s an honesty problem, not a technical one.

2. The essence of the global AI race is a “resource race,” not an “intelligence race”

Many people still look at the AI race with the thinking of “a genius scientist taking on all comers,” but the reality is:

# The "resource formula" for training a large model
def can_train_competitive_model():
    requirements = {
        'gpu_cluster': '>= 1000 H100/A100 cards',
        'training_data': '>= 10TB high-quality text',
        'engineering_team': '>= 50 people (algorithm + engineering + data)',
        'training_time': '>= 3 months',
        'budget': '>= 10 million USD'
    }
    
    # fewer than 20 organizations worldwide can meet these conditions
    return check_resources(requirements)

Once technology paths converge, what’s being compared is:

• Who has more GPUs
• Who has better data
• Who has more efficient engineering capability
• Who has stronger financial backing

From this angle, for a small or mid-sized country to independently develop a “homegrown large model” is no easier than independently developing a lithography machine.

3. The open-source community’s “contributor’s dilemma”

DeepSeek’s choice to open-source is admirable. But the open-source model faces new challenges in the large-model era:

• Extremely high training cost: open-sourcing the code is easy, open-sourcing the trained model weights is okay too, but open-sourcing the full training data pipeline and training process is nearly impossible
• Commercialization pressure: how does an open-source company profit? Cloud services? Enterprise support? Or “open source to drive traffic, closed source to earn money”?
• Geopolitical influence: AI technology is increasingly sensitive, and open-source licenses are starting to be affected by export controls

Implications for Product Builders: Survival Strategy in the AI Era

Based on this case, here are a few solid suggestions for friends building tech products:

1. Honesty is the best strategy

If you build a product on top of an open-source project:

• Clearly label the source of the technology
• Comply with the open-source license
• Honestly state where your own contribution lies
• Users can actually accept “standing on the shoulders of giants,” but not “claiming the giant’s achievements as your own”

2. Find your “asymmetric advantage”

Big companies have compute advantages, but you have:

• Vertical-domain data: specialized data in fields like healthcare, law, finance
• Domain knowledge: deep understanding of a specific industry
• Localization advantage: grasp of local language, culture, and user habits
• Lightweight deployment: how to make good use of large models in resource-constrained environments

3. Focus on “application innovation,” not just “underlying innovation”

From an engineering standpoint, the biggest opportunity now isn’t in “building a general model better than GPT-4” but in:

Application-innovation opportunity matrix:
┌──────────────┬────────────────────┬────────────────────┐
│              │  to C (consumers)  │  to B (enterprises) │
├──────────────┼────────────────────┼────────────────────┤
│ Efficiency   │ - personal AI assistant │ - intelligent customer service │
│ gains        │ - content-creation tools │ - code generation │
├──────────────┼────────────────────┼────────────────────┤
│ Experience   │ - AI social          │ - intelligent decision support │
│ rebuilding   │ - personalized education │ - automated reports │
├──────────────┼────────────────────┼────────────────────┤
│ Cost         │ - localized small models │ - private deployment │
│ reduction    │ - edge AI            │ - model compression & optimization │
└──────────────┴────────────────────┴────────────────────┘

4. Build real technical barriers

If you really want to do “original” work, then you should invest in:

• The data flywheel: how to continuously acquire high-quality data and form a closed loop
• Engineering efficiency: how to reach 90% of the effect with 1/10 of the resources
• Domain adaptation: how to make a general model excel in a specific domain
• Ecosystem-building: how to build a developer community and partner network

Conclusion: The “New Normal” of the AI Era

Anyone who runs marathons knows pacing matters, but what matters more is knowing where you are and where you’re going. Sprint too fast in the first half and you may crash in the second.

AI development right now is like the first 10 kilometers of a marathon: everyone is excited and accelerating. But what really tests endurance is the middle stretch — when the technology dividend gradually disappears, when the resource gap widens, when commercialization pressure hits.

The Rinna incident sounds a reminder:

• Technology democratization is the trend: open source lets more people use advanced technology
• Honesty and transparency are the bottom line: neither users nor developers are fools
• Differentiated competition is key: finding your own track offers more opportunity than chasing on the mainstream one
• Long-termism is the way out: AI isn’t a sprint, it’s a marathon

One last honest word: as someone in tech, I’m actually glad to see this kind of “peeling.” The tech industry needs more transparency, more rational discussion, fewer “myths,” and more “truth.”

After all, real technological progress is never built on a packaged “national light,” but accumulated through line after line of solid code, experiment after failed experiment, and product after product that solves real problems.

AI’s road is still long. Let’s all be down-to-earth and run slowly.

中英对照

文章作者：阿文

文章链接： https://www.awen.me/post/60be5815.html

版权声明：本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 阿文的博客！