MarketDX lets AI assistants (like Claude) pull market data through MCP — a set of "tools" the LLM can call itself: find stocks, pull financials, run screens, and so on.

Sounds simple, but one step is quietly expensive: turning a human phrase into the values the system actually understands.

Take a real question:

"Retail stocks whose current assets are accelerating sharply"

Before it can screen anything, the system has to convert three pieces into tokens the database knows:

• "current assets" → CurrentAssets
• "accelerating sharply" → accelerating
• "retail" → 2550 (a GICS code)

We do this with a family of find_* tools (find_fsconcept, find_fspattern, find_gics, …). The trouble is how they work:

1. The LLM calls find_fsconcept("current assets") → the system returns a list of candidates (top-k), maybe 10 of them
2. The LLM reads them and picks the right one
3. Repeat with find_fspattern → top-k → pick
4. Repeat with find_gics → top-k → pick
5. Only then call the real screening tool with the chosen values

Count the round-trips: four back-and-forths before the real work even starts. Each one has network latency, and — worse — the LLM has to burn reasoning tokens reading the top-k and deciding every single time.

That's the "ping-pong" MCP hits on nearly every query. The more complex the question (several concepts), the more rounds, and the longer the user waits.

How find_* works inside (vector search 101)

First, how does find_* turn "current assets" into CurrentAssets? This is the heart of the story.

The key technique is a vector embedding — it turns the meaning of text into a long list of numbers (a vector with thousands of dimensions). Text with similar meaning ends up with vectors that sit close together in that space.

We do two things:

1. Prepare once, ahead of time: every concept in the catalog ("Total Revenue", "Current Assets", "Gross Margin", …) is turned into a vector by an embedding model (we use Gemini's) and stored.
2. At query time: take the user's phrase ("current assets"), embed it the same way, and find its nearest neighbours (by cosine similarity) — closer vector = closer meaning.

Sort by closeness, take the top k = the top-k. (There's also a first pass that matches exact words/aliases — lexical match — before the semantic step, but the idea is the same: "return the ~10 most similar candidates.")

Here's the weakness: "close in vector space" doesn't always mean "correct." Near-meaning terms — "return on equity" vs "dividend per share", "allowance for doubtful accounts" vs "provision for doubtful accounts" — have vectors so close they get mixed together in the top-k, and sometimes the wrong one even ranks higher than the right one. That's exactly why the system doesn't dare commit to a single answer.

Why return top-k at all?

Good question — why doesn't find_* just return one answer and be done?

Because rank 1 isn't always right. We measured it on find_fspattern (which matches financial-statement "patterns"): blindly trusting the vector's #1 is correct only 71% of the time — but the right answer is somewhere in the top-10 100% of the time.

find_fspattern (51 patterns):
  trust rank 1 blindly     → 71% correct
  answer is in top-10      → 100%

See that 71% → 100% gap? That's why top-k exists — the system isn't confident enough to commit, so it hands the choices back to the LLM. And that handoff is the ping-pong.

The idea: move "the choosing" to the server

If the problem is "the system won't choose, so it punts to the LLM" — what if we had something that dares to choose, on the server side?

That's where Jev comes in. From Parts 1–2 we know it's a fast, cheap "decision model": give it options and a question, and it returns one answer plus a confidence score — no long text to generate.

So the new shape is:

Before:  user → LLM picks route → find_* returns top-k → LLM picks → call real tool   (ping-pong)
After:   user → LLM sends raw phrase into the tool → tool lets Jev choose → carry on   (one round)

The LLM sends "current assets" straight into the screening tool; the tool calls Jev internally to turn it into CurrentAssets, then screens — cutting out the whole "return top-k, let the LLM pick" detour.

The question is whether Jev chooses accurately enough to do this. We tried two scenarios.

Small catalog: let Jev pick from the whole set at once

find_fspattern has 51 patterns total — small enough to hand the entire set to Jev as options and let it choose in one shot.

Results:

find_fspattern (51 patterns, Thai & English queries):
  Jev picks once            → 92.9% correct
  vector rank 1 (old way)   → 71.4% correct

Jev leaves the old rank-1 in the dust and gets close to the 100% ceiling that normally requires the LLM to re-pick — but in a single shot, no ping-pong.

Surprise: most of the "misses" were our fault

At first we had a case that looked like a Jev miss: the query "the stock's value doubled" — Jev answered "higher than the rest" instead of "compound growth."

We nearly blamed Jev — until we looked at what we'd fed it. We were only sending each pattern's short definition, and the compound-growth definition talked only about "annual rate (CAGR)" — the word "doubled" never appeared. Yet the real database had another description field spelling out "the value doubles or triples."

The fix: feed the full description that the search itself actually uses — and Jev got it right immediately.

This echoes what we learned in Part 2: before blaming the model, look at what you fed it. Almost every "miss" turned out to be context we didn't fully supply, or a reference answer of ours that was too narrow.

The main case: too many candidates to fit — vector + Jev

This is the common, important one: most catalogs are too big to hand to Jev whole. The financial-concept finder (find_fsconcept) has 428 entries (statement lines + ratios + valuation multiples); the stock finder has tens of thousands; the economic-data finder tens of thousands more.

Dumping all 428 into Jev at once won't work (expensive and over the limit). But we don't have to throw away what we have — let the existing vector search pre-filter first:

raw phrase → [vector search narrows to top-15] → [Jev picks 1 of 15] → token

Vector search does what it's good at (narrow thousands to ten); Jev does what it's good at (pick the right one out of ten) — and the choosing still happens on the server, no ping-pong back to the LLM.

Results:

find_fsconcept (428 entries, English queries):
  vector rank 1 (old way)      → 68% correct
  vector top-15 → Jev picks    → 100% correct

Jev fixed every case the vector mis-ranked — genuinely hard ones, like:

• "ผลตอบแทนผู้ถือหุ้น" or "return on equity (ROE)" in English — vector guessed "dividend per share" → Jev picked roe
• "หนี้ที่มีภาระดอกเบี้ยรวม" or "total interest-bearing debt" in English — vector guessed "accrued interest" → Jev picked total_debt
• "งานระหว่างก่อสร้าง", "เงินลงทุนที่ถือจนครบกำหนด", "กำไรขาดทุนเบ็ดเสร็จอื่นสะสม" or "construction in progress", "held-to-maturity investments", "accumulated other comprehensive income" — deep accounting terms the vector drifted on, but Jev picked correctly

Even more impressive, it got the type right: "gross profit" → the statement line (gross_profit), while "gross margin" → the ratio (gross_margin). Different things — Jev doesn't confuse them.

And the cost? — vector + Jev is still cheaper

You might assume adding Jev makes it more expensive. The opposite is true.

Pre-filtering with vectors is ~4× cheaper, because Jev's cost is driven by the length of the options you feed it — reading 10 options is far cheaper than reading 400.

On top of that, the vector's embedding cost is nearly zero, because we store the vectors of previously-seen queries permanently (repeat query = no recompute). And Jev itself bills for input only, output is free, and it's several times cheaper than a general LLM.

In round-trips: from 4 rounds → 1. The user gets an answer noticeably faster, and the client-side LLM doesn't have to break focus to sift top-k on every question — it can spend those tokens on what matters. That's a genuinely better MCP experience.

Lessons worth keeping (the real ones)

Shipping this for real means being honest about the limits. We found four.

1. The context you feed matters more than you think. Almost every Jev "miss" was us feeding an incomplete description, or a reference answer that was too narrow. Fixing the descriptions in the database improves the whole system — vector and Jev both consume the same descriptions.

2. "Asking to confirm" has to be smart, or it destroys the UX you just fixed. Sometimes Jev genuinely isn't sure — the question is ambiguous, or two options are neck-and-neck. We designed the tool to look at the shape of the confidence, not just one number:

• clearly confident → use it
• borderline but usable → answer anyway, with a note on how it interpreted the phrase (don't block)
• two options genuinely close and genuinely different → then ask the user to confirm (rare)

The principle: only ask to confirm when "the right answer exists but Jev can't pick it cleanly" — not every time it's unsure. Otherwise you're back to ping-pong.

3. Multiple languages → translate to English first (and this is a vector limitation, not Jev's). Testing deep accounting terms across languages, we found the Thai word for goodwill (ค่าความนิยม) fell to rank 45 in the vector search — out of the top-15, so Jev never saw it as an option. On the surface it looks like Jev failed.

But we proved it's a cross-language weakness of the embedding, not Jev — ask the same term in English ("goodwill") and it ranks #1 instantly; Jev even knows that のれん (Japanese) means goodwill. Luckily our MCP tools already require the client to translate to English before sending — so this doesn't bite in practice.

4. Razor-thin accounting distinctions — Jev sails through. We built the meanest test we could: pairs of terms that differ by a hair but mean different things.

25 brutal pairs — Jev scored 100% at an average confidence of 0.998, versus the vector's rank-1 at 48%. This is the scariest failure mode (being confidently wrong), and Jev passed it comfortably in English.

Conclusion: when to collapse a resolver with Jev

From what we've tried, the playbook is clear:

• Small catalog (a few dozen): let Jev pick from the whole set in one shot.
• Large catalog (hundreds / thousands / tens of thousands): use vector search to pre-filter to ~10–15, then let Jev pick — you still collapse the round-trips and pay less.
• Add a cache shortcut: phrases you've resolved before (e.g., "current assets" → CurrentAssets) get stored, so next time you return instantly without calling Jev again.

All of this turns MCP from "four rounds of ping-pong per question" into "one round" — faster, cheaper, and lighter on the client LLM.

A caveat: don't flip everything in one day. The safe path is to run Jev in parallel with the old resolver on real traffic for a while, compare the results, watch the confidence distribution, then enable it piece by piece — and keep a fallback in case Jev is slow or down (we measure ~1 second normally, but with a tail that can spike into the tens of seconds).

Still, the direction is clear: a resolver is the "round-trip tax" MCP pays on every query — Jev pays that tax for you. And no matter how many candidates there are, the vector + Jev pairing collapses it, both faster and cheaper.

MarketDX turns financial news into an impact graph. At its core is a step that reads each article and classifies + scores it — and it runs on every article that flows in. It's the highest-volume LLM task in the system, so if Jev can take it over, the savings are the biggest. That made it the right place for a real test. It breaks into four sub-decisions:

1. News type — what kind of story is this (earnings / M&A / legal / macro / …)?

2. Impact (1–5) — how much should an investor care?

3. Link to an investment theme (megatrend) — which trend does this move?

4. Impact detail — direction (positive/negative), strength, and the channel it acts through.

We tested them one at a time and read the actual output every time. Here's what happened.

Part 1: News type — better than the number suggests

We gave Jev a Choice of 16 types and compared it to what the current system had assigned. The headline was "74% agreement" — which sounds ordinary. But reading the actual disagreements flipped the picture:

• Most "mismatches" were genuinely ambiguous boundaries (e.g., "analyst raises price target" vs "analyst revises earnings estimate") where Jev's answer was just as defensible.

• In some cases Jev was more correct — the old system had classified two near-identical stories as different types (inconsistent); Jev classified them the same, and closer to the actual content.

The one real trap: Jev was reluctant to answer "noise / not real news" — it kept trying to force a "real" category. The fix was a policy tweak: tell it plainly that "noise is a normal, common answer — don't force a category just because a keyword matches." The result:

• On a fresh, unseen set of 45 articles: it caught junk correctly 20/20, and never once wrongly flagged real news as junk (0/25).

Lesson: Jev's biases are fixable by clarifying the policy — no example-feeding required.

Part 2: Impact — a bias we found, fixed, and a production bug it caught

Asked to score 1–5 directly (a single Score question), Jev had a central bias — nearly everything landed on 3, and it never assigned 1 (noise). Useless as a gate.

The fix that worked — break it into sub-questions and combine them ourselves. Instead of one fuzzy "how important is this," we asked several yes/no questions (is there genuinely new information? is it unusually large? is it surprising? is it wide-reaching? is it promotional/PR?) and combined the answers into a score with a formula we control. Now the scores spread realistically, it can assign 1 to noise again, and it cleanly filters ads/spam.

The surprise: along the way, Jev caught a bug in the existing system — a genuine earnings report from a major industry bellwether had been tagged "short news / unimportant" by a length-based rule, while Jev correctly rated it high. Strong proof that "chase the old system" is the wrong goal.

Part 3: Linking to investment themes — a lesson about context and drilling down

This was the hardest part: there are 25 top-level themes and ~300 sub-nodes across three levels, and most articles don't move any theme at all.

The first attempt failed: asking broadly "does this move any theme?" — Jev could barely tell movers from non-movers, because the question was too abstract.

What fixed it (two things):

1. Add context, not just names. Theme names alone are short and ambiguous, so we included each theme's description and examples in the question.

2. Ask per-theme and drill top-down — pick the top-level theme first → then the sub-theme → then deeper (a drill-down).

With those two changes the picture turned strongly positive — Jev almost never links a story to the wrong theme (very high precision).

A "product taste" call we had to make: should linking be strict (only stories that truly move a whole theme) or broad coverage (a company in that sector counts too)? We chose "broad coverage, but nothing jarring — if a reader would go 'huh, that doesn't belong,' don't link it." Once we framed the question that way, Jev delivered exactly that — it links stories that fit (an airline under Aviation, a gold miner under Critical Materials) and rejects the off-topic ones, without ever spraying to the wrong theme.

Drilling to the specific sub-node: when it went down to pick the exact node, Jev hit 80% exact / 90% right-subtree, and in several cases it was more precise than the old system (which stopped at "Precious Metals" where Jev correctly drilled to "Gold").

Impact detail: direction (positive/negative) and strength worked well. The "channel" field looked noisy at first — until we realized we'd modelled it wrong: one event hits several channels at once (a solar subsidy is pricing + demand + capital). Once we let it return multiple channels (multi-label) instead of forcing one, the problem disappeared.

Four lessons

1. Don't judge a new AI by "does it match the old one." The old one can be wrong too (we caught several of its bugs). Read the real output and decide.

2. Jev's biases are fixable through the policy in the prompt — no example-feeding (which would cause overfitting).

3. Decompose hard judgments and combine them yourself — both impact (many yes/no questions) and theme-linking (top-down drill-down) beat asking in one shot.

4. Add context, and allow multiple answers where reality is multi-valued (impact channels, news types).

Cost comparison (rough numbers, per 1,000 decisions)

Assume one news-classification decision, ~1,200 tokens in, a short answer out:

• Jev is the cheapest — roughly 3–10× less than the small/mid LLMs, partly because output is free (the more parallel questions you ask, the bigger the edge).

• Compared to vector embeddings (a similarly cheap option) it's a different job: embeddings tell you "what's similar," they can't decide; Jev decides. The best pattern is to use both — cheap embedding shortlist → Jev decides.

These are ballpark figures at 2026 prices, and real cost depends on prompt length. Treat them as orders of magnitude, not exact accounting.

On speed: Jev runs ~1s per call (with occasional multi-second spikes) — fine for per-item decisions, but don't loop it over millions of items directly; shortlist first with something cheaper.

When to use Jev

Use Jev when the work is a clear decision (classify / score / yes-no), volume is high, and you want calibrated confidence to gate on. Jev is cheaper, fast enough, and its output is locked to your options (it can't hallucinate something out of range).

Stick with an LLM when you need writing, explanation, translation, or multi-step reasoning — Jev can't do those and isn't meant to.

The overall result: across MarketDX's news classification and scoring, Jev matched or beat the existing LLM system on almost every axis (handling noise/spam, not mislinking themes, precise sub-node drilling) at several times lower cost.

An honest caveat before going live: all of this was judged by us (with Claude Opus) reading a sample of a few hundred articles — not because the quality is unproven, but because scale, drift, and edge cases need confirmation on real traffic. Before flipping a switch you'd want to run it in parallel with the old system for a while, keep a standard sample set to watch quality, and account for the occasional latency spike and slight run-to-run variance.

Bottom line: for high-volume decisions, Jev is worth investing in — not to replace LLMs wholesale, but to take over the decision parts, which turn out to be far more common than you'd think.

The AI models most of us know — GPT, Claude, Gemini, DeepSeek — work by generating text one token at a time. You ask, they write an answer. That's powerful for writing, summarizing, translating, or reasoning step by step.

But a huge amount of real software doesn't need text — it needs a decision:

• What kind of news is this?

• How important is it, on a scale of 1–5?

• Should we process this content, or drop it?

Jev (from TypeSafe AI) is built specifically for that. It doesn't write prose. It picks an answer from a set you define and returns a typed result with a confidence score — instantly.

It has exactly three question types:

• Choice — pick one option from a defined set (with a probability for each)

• Score — rate against ordered levels you describe

• Noul — yes/no, returned as a probability from 0 to 1

There's an interesting economic wrinkle too: Jev bills for input only — output is free — and it's fast (roughly ~1 second in our tests), because it never has to write text token by token.

The core question we set out to answer: can a model that only makes decisions be smart and accurate enough to replace tasks we run on big LLMs today? Part 1 starts at the foundation — does it actually understand language and possess real knowledge? — before Part 2 tries it on a real workload.

What MarketDX does?

MarketDX is a platform that turns financial news into an impact graph — it reads a story and works out which assets and investment themes it moves, in which direction, and how that ripples out to related players. Under the hood there are a lot of "decision" steps, and many of them run on every single article that comes in. That means shaving cost off each decision compounds fast — which is exactly why Jev caught our attention.

How we tested?

Two ground rules shaped everything, and they change how you should read the results:

1. Judge quality by reading the output yourself, not by "does it match the old system." Our current system is also an LLM (which is sometimes wrong). Measuring "how often does Jev agree with the LLM" tells you how similar it is, not how good. The goal is to be better, not identical — so we read the actual results and judged them ourselves.

2. Write the prompt without leaking the answer. It's fine to state the task definition in the prompt (e.g., "treat these as the same meaning even if politeness or slang differs"). What we do not do is drop in example sentences that give away the expected answer — that inflates the results and hides real weaknesses.

Test 1: Language — does it understand meaning across languages?

The question: does Jev know that "Have you eaten yet?" (polite) and "Yo, you grubbed yet?" (slang) mean the same thing? And in how many languages?

Method: we hand-wrote sentences in 23 languages (English, Chinese, Japanese, Arabic, Hindi, Korean, Thai, Taiwanese Hokkien, and more). For each language, three variants, then asked Jev whether the pairs "carry the same core meaning":

• A vs B — polite ↔ slang, same meaning → should score high

• A vs N — very similar wording but a different intent (e.g., "Have you eaten yet?" [asking] vs "Oh, you've eaten already?" [surprised confirmation]) → genuinely borderline

• A vs C — different topic entirely ("have you eaten?" vs "are you hungry?") → should score low

Results (averaged across all 23 languages, scores 0–1):

What it means: Jev ranks the gradient correctly (clearly-same > borderline > different) in almost every language, and it does so across all 23 including slang — not just English. Impressively, it separates "are you hungry?" from "have you eaten?" even though the sentences overlap heavily.

Real weaknesses we found:

• Low-resource dialects (Taiwanese Hokkien) are the weakest — it can't slice fine distinctions as sharply as major languages.

• Ambiguous idioms — e.g., British "have your tea" (which can mean the evening meal or the drink) — Jev takes the literal reading.

A useful side-finding: we fired the identical request three times; the billed token count stayed the same every time → Jev has no prompt cache (unlike several LLMs). To save money you shrink the input or batch several questions into one request, not repeat-and-cache.

Test 2: World knowledge — shallow and deep

The question: beyond understanding language, does it actually know things — both general knowledge and deep, specialized knowledge?

Method: a 4-option multiple-choice exam, 75 questions, across 3 difficulty tiers × 15 subjects (accounting, law, finance, medicine, physics, history, philosophy, and more):

• General — broad common knowledge

• Shallow — what a student in that field should know

• Deep — genuinely specialized: e.g., R&D cost treatment under IFRS vs US GAAP, Japan's Yayoi period, the Gettier problem in epistemology, the Modigliani–Miller theorem

(We shuffled the answer positions on every question so the correct answer wasn't clustered in one slot.)

Results:

Its confidence was ~1.00 on nearly every question, and it answered the deep, specialized items correctly.

An honest reading: 100% is impressive, but it also means we never found the ceiling. Our "deep" questions, while specialized, are still textbook facts. We didn't test genuinely contested knowledge, obscure long-tail trivia, or problems that require multi-step reasoning rather than recall. So the fair conclusion is "broad and deep enough," not "no limits."

Wrap-up (Part 1)

These two foundational tests answer the question "is Jev smart enough?" fairly clearly:

• It understands language and meaning across 23 languages, including slang and shifts in register, accurately and with sensible gradients.

• It has knowledge, both broad and deep, across many fields.

• It's fast (~1s) and bills for input only.

With the fundamentals looking solid, we felt safe pointing it at real MarketDX work — which is Part 2: we put Jev on a high-volume decision task that runs on every article, look at how it did, the traps we hit and fixed, and how the cost compares to the LLMs we use today (DeepSeek / OpenAI / Gemini).

MarketDX เปิดให้ผู้ช่วย AI (เช่น Claude) เรียกข้อมูลตลาดผ่าน MCP — ชุด "เครื่องมือ" ที่ LLM เรียกใช้ได้เอง ค้นหุ้น ดึงงบ สกรีน ฯลฯ

ฟังดูง่าย แต่มีขั้นตอนหนึ่งที่แพงเงียบ ๆ คือ การแปลงคำพูดคนให้เป็นค่าที่ระบบเข้าใจ

ลองดูคำถามจริง:

"หุ้นในกลุ่มค้าปลีกที่มีสินทรัพย์หมุนเวียนเพิ่มขึ้นก้าวกระโดด"

ก่อนจะสกรีนได้ ระบบต้องแปลง 3 ชิ้นนี้เป็น "โทเคน" ที่ฐานข้อมูลรู้จัก:

• "สินทรัพย์หมุนเวียน" → CurrentAssets
• "เพิ่มขึ้นก้าวกระโดด" → accelerating
• "กลุ่มค้าปลีก" → 2550 (รหัส GICS)

งานนี้เราทำด้วยเครื่องมือตระกูล find_* (find_fsconcept, find_fspattern, find_gics ...) ปัญหาคือมันทำงานแบบนี้:

1. LLM เรียก find_fsconcept("สินทรัพย์หมุนเวียน") → ระบบคืน รายการผู้สมัคร (top-k) กลับมาสัก 10 ตัว
2. LLM อ่านแล้วเลือก อันที่ใช่
3. ทำซ้ำกับ find_fspattern → คืน top-k → เลือก
4. ทำซ้ำกับ find_gics → คืน top-k → เลือก
5. แล้วค่อย เรียกเครื่องมือสกรีนจริงด้วยค่าที่เลือกได้

นับ round-trip ดู: สี่รอบไปกลับ กว่าจะได้เริ่มงานจริง ทุกรอบมี latency ของเน็ต บวกกับที่หนักกว่านั้น — LLM ต้องเผา reasoning token อ่าน top-k แล้วตัดสินใจเลือกทุกครั้ง

นี่คือ "การปิงปอง" ที่ MCP เจอแทบทุกคำถาม ยิ่งคำถามซับซ้อน (หลาย concept) ยิ่งปิงปองหลายรอบ ผู้ใช้ก็รอนานขึ้น

find_* ทำงานยังไงข้างใน (vector search 101)

ก่อนไปต่อ ขออธิบายว่า find_* แปลง "สินทรัพย์หมุนเวียน" เป็น CurrentAssets ได้ยังไง เพราะมันคือหัวใจของเรื่องนี้

หัวใจคือเทคนิคชื่อ vector embedding — แปลง "ความหมาย" ของข้อความให้เป็นชุดตัวเลขยาว ๆ (เวกเตอร์หลายพันมิติ) ข้อความที่ความหมายใกล้กันจะได้เวกเตอร์ที่อยู่ใกล้กันในปริภูมิ

ระบบเราทำสองอย่าง:

1. เตรียมล่วงหน้า (ครั้งเดียว): ทุกแนวคิดใน catalog (เช่น "Total Revenue", "Current Assets", "Gross Margin") ถูกแปลงเป็นเวกเตอร์ด้วยโมเดล embedding (เราใช้ของ Gemini) แล้วเก็บไว้ในฐานข้อมูล
2. ตอนมีคำถาม: เอาคำที่ผู้ใช้ถาม ("สินทรัพย์หมุนเวียน") มาแปลงเป็นเวกเตอร์แบบเดียวกัน แล้ว หาเพื่อนบ้านที่ใกล้ที่สุด (nearest-neighbor ด้วย cosine similarity) — เวกเตอร์ยิ่งใกล้ = ความหมายยิ่งคล้าย

เรียงผลตามความใกล้ เอา k อันบนสุด = top-k (จริง ๆ มีอีกชั้นคือจับคำตรงตัว/ชื่อพ้อง — lexical match — มาก่อน semantic แต่หลักการรวมคือ "คืนผู้สมัครที่คล้ายที่สุดมาสัก 10 ตัว")

จุดอ่อนอยู่ตรงนี้: "ใกล้ในเชิงเวกเตอร์" ไม่ได้แปลว่า "ใช่" เสมอ คำที่ความหมายเฉียด ๆ กัน — "ผลตอบแทนผู้ถือหุ้น" กับ "เงินปันผลต่อหุ้น", "ค่าเผื่อหนี้สงสัยจะสูญ" กับ "ตั้งสำรองหนี้สงสัยจะสูญ" — เวกเตอร์มันใกล้กันมากจนโผล่ปนกันใน top-k และบางทีตัวผิดดันอยู่อันดับสูงกว่าตัวถูกด้วยซ้ำ นั่นคือเหตุผลที่ระบบ ไม่กล้า ฟันธงอันเดียว

ทำไมต้องคืน top-k ตั้งแต่แรก?

คำถามที่ดีคือ — ทำไม find_* ไม่คืนคำตอบเดียวไปเลย ให้จบ?

เพราะ อันดับ 1 ไม่ได้ถูกเสมอ เราวัดจริงกับ find_fspattern (ตัวหา"รูปแบบ" ของงบ): ถ้าเชื่ออันดับ 1 ของ vector search ดื้อ ๆ จะถูกแค่ 71% แต่ถ้าดู top-10 ทั้งชุด — คำตอบที่ถูก อยู่ในนั้น 100%

find_fspattern (51 รูปแบบ):
  เชื่ออันดับ 1 ดื้อ ๆ         → ถูก 71%
  คำตอบอยู่ใน top-10          → 100%

เห็นช่องว่าง 71% → 100% ไหม? นั่นแหละคือเหตุผลที่มี top-k — ระบบไม่มั่นใจพอจะฟันธง เลยโยนตัวเลือกกลับให้ LLM ตัดสิน และนั่นคือต้นตอของการปิงปอง

ไอเดีย: ย้าย "การเลือก" ไปไว้ฝั่งเซิร์ฟเวอร์

ถ้าปัญหาคือ "ระบบไม่กล้าเลือก เลยโยนกลับให้ LLM" — แล้วถ้าเรามีตัวที่ กล้าเลือกแทน อยู่ฝั่งเซิร์ฟเวอร์ล่ะ?

นี่คือจุดที่ Jev เข้ามา จากตอน 1-2 เรารู้แล้วว่ามันเป็น "โมเดลตัดสินใจ" ที่เร็วและถูก — ให้ตัวเลือกกับคำถาม มันคืน คำตอบเดียว + ความมั่นใจ (confidence) ไม่ต้อง generate ข้อความยาว

โครงใหม่จึงเป็น:

เดิม:  user → LLM เลือก route → find_* คืน top-k → LLM เลือก → เรียก tool จริง   (ปิงปอง)
ใหม่:  user → LLM ส่งคำดิบเข้า tool → tool ให้ Jev เลือกเอง → ทำงานต่อได้เลย     (รอบเดียว)

LLM ส่ง "สินทรัพย์หมุนเวียน" เข้าเครื่องมือสกรีนตรง ๆ เครื่องมือเรียก Jev แปลงเป็น CurrentAssets ข้างในเอง แล้วสกรีนต่อได้เลย — ตัดขั้นตอนโยน top-k กลับไปให้ LLM เลือกทิ้งทั้งหมด

คำถามคือ Jev เลือกแม่นพอจะทำแบบนี้ไหม เราลองสองสถานการณ์

กรณี catalog เล็ก: ให้ Jev เลือกจากทั้งชุดทีเดียว

find_fspattern มีรูปแบบทั้งหมด 51 ตัว — เล็กพอจะยัดทั้งชุดเป็นตัวเลือกให้ Jev เลือกในครั้งเดียว

อ่านผล:

find_fspattern (51 รูปแบบ, คำถามไทย/อังกฤษ):
  Jev เลือกทีเดียว           → ถูก 92.9%
  vector อันดับ 1 (แบบเดิม)   → ถูก 71.4%

Jev ทิ้งอันดับ-1 แบบเดิมขาด และเข้าใกล้เพดาน 100% ที่ปกติต้องพึ่ง LLM มาเลือกซ้ำ — แต่ทำในครั้งเดียว ไม่ต้องปิงปอง

เซอร์ไพรส์: เคสที่ "พลาด" ส่วนใหญ่เป็นความผิดของเรา

ตอนแรกเรามีเคสที่ดูเหมือน Jev พลาด: คำถาม "มูลค่าหุ้นเพิ่มขึ้นเป็นสองเท่า" Jev ตอบผิดเป็น "สูงกว่าค่าอื่น" แทนที่จะเป็น "เติบโตทบต้น" (compound growth)

เกือบโทษ Jev แล้ว — แต่พอไปดู สิ่งที่เราป้อนให้มัน เราส่งแค่ "นิยามสั้น" ของแต่ละรูปแบบ ซึ่งนิยามของ compound growth เขียนเน้นแต่ "อัตราต่อปี (CAGR)" ไม่มีคำว่า "เป็นสองเท่า" เลย ทั้งที่ในฐานข้อมูลจริงมีคำอธิบายอีกฟิลด์ที่เขียนชัดว่า "มูลค่าเพิ่มเป็นสองเท่า/สามเท่า"

วิธีแก้: ป้อนคำอธิบายให้ครบเหมือนที่ระบบค้นหาใช้จริง — แก้ปุ๊บ Jev ตอบถูกทันที

บทเรียนนี้ย้ำสิ่งที่เราเจอตั้งแต่ตอน 2: ก่อนโทษโมเดล ให้ดูสิ่งที่เราป้อนมันก่อน เกือบทุกเคสที่ "พลาด" กลายเป็น context ที่เราให้ไม่ครบ หรือเฉลยของเราเองที่แคบเกินไป

กรณีหัวใจ: candidate เยอะเกินจะยัดหมด — vector + Jev

นี่คือกรณีที่เกิดบ่อยและสำคัญที่สุด catalog ส่วนใหญ่ใหญ่เกินกว่าจะยัดทั้งชุดให้ Jev — ตัวหาแนวคิดงบการเงิน (find_fsconcept) มีถึง 428 รายการ (บรรทัดงบ + อัตราส่วน + ตัวคูณราคา) ตัวหาหุ้นมีเป็นหมื่น ตัวหาข้อมูลเศรษฐกิจมีเป็นหลักหมื่น

โยนทั้ง 428 ตัวให้ Jev เลือกทีเดียวทำไม่ได้ (ทั้งแพงและเกินขีดจำกัด) แต่เราไม่จำเป็นต้องทิ้งของเดิม — เอา vector search ที่มีอยู่แล้วมาช่วยกรองก่อน:

คำดิบ → [vector search กรองเหลือ top-15] → [Jev เลือก 1 จาก 15] → โทเคน

vector search ทำสิ่งที่มันเก่ง (กรองจากพันเหลือสิบ) Jev ทำสิ่งที่มันเก่ง (เลือกตัวที่ใช่จากสิบ) — และการเลือกยังอยู่ฝั่งเซิร์ฟเวอร์ ไม่ต้องปิงปองกลับหา LLM

อ่านผล:

find_fsconcept (428 รายการ, คำถามอังกฤษ):
  vector อันดับ 1 (แบบเดิม)         → ถูก 68%
  vector top-15 → Jev เลือก        → ถูก 100%

Jev แก้ ทุกเคส ที่ vector จัดอันดับ 1 ผิด และเป็นเคสยากจริง เช่น:

• "ผลตอบแทนผู้ถือหุ้น (ROE)" — vector เดาเป็น "เงินปันผลต่อหุ้น" → Jev เลือก roe ถูก
• "หนี้ที่มีภาระดอกเบี้ยรวม" — vector เดาเป็น "ดอกเบี้ยค้างจ่าย" → Jev เลือก total_debt ถูก
• "งานระหว่างก่อสร้าง", "เงินลงทุนที่ถือจนครบกำหนด", "กำไรขาดทุนเบ็ดเสร็จอื่นสะสม" — ศัพท์บัญชีลึกที่ vector ลอยหมด แต่ Jev เลือกถูก

ที่น่าทึ่งกว่าคือมันแยกแยะ "ประเภท" ได้ถูก: "กำไรขั้นต้น" → บรรทัดในงบ (gross_profit) ส่วน "อัตรากำไรขั้นต้น" → อัตราส่วน (gross_margin) — คนละตัวกัน Jev ไม่สับสน

แล้วต้นทุนล่ะ? — vector + Jev ยังถูกกว่า

หลายคนคงคิดว่าเพิ่ม Jev เข้าไปก็ต้องแพงขึ้นสิ ตรงกันข้าม

การกรองด้วย vector ก่อน ถูกลง ~4 เท่า เพราะต้นทุนหลักของ Jev คือความยาวของตัวเลือกที่ป้อนเข้าไป — อ่าน 10 ตัวย่อมถูกกว่าอ่าน 400 ตัว

แถมค่า embedding ของ vector แทบเป็นศูนย์ เพราะเราเก็บ vector ของคำค้นที่เคยเจอไว้ถาวรอยู่แล้ว (คำค้นซ้ำ = ไม่ต้องคำนวณใหม่) ส่วนตัว Jev เอง — คิดเงินเฉพาะ input, output ฟรี, และถูกกว่า LLM ทั่วไปหลายเท่า

เทียบเป็น round-trip: จาก 4 รอบ → 1 รอบ ผู้ใช้ได้คำตอบไวขึ้นชัดเจน และ LLM ฝั่ง client ไม่ต้องเสียสมาธิมานั่งเลือก top-k ทุกคำถาม — มันเอา token ไปคิดเรื่องที่สำคัญกว่าได้ นี่คือ UX ของ MCP ที่ดีขึ้นจริง

บทเรียนที่ต้องจำ (มีจริง)

การจะเอาไปใช้จริงต้องซื่อสัตย์กับข้อจำกัด — เราเจอ 4 เรื่อง

1. context ที่ป้อนสำคัญกว่าที่คิด เกือบทุกเคสที่ Jev "พลาด" คือเราป้อนคำอธิบายไม่ครบ หรือเฉลยของเราเองแคบเกิน แก้คำอธิบายในฐานข้อมูล = ดีขึ้นทั้งระบบ (ทั้ง vector และ Jev กินคำอธิบายชุดเดียวกัน)

2. "ถามยืนยัน" ต้องฉลาด ไม่งั้นทำลาย UX ที่เพิ่งแก้มา บางครั้ง Jev ก็ไม่มั่นใจจริง ๆ — คำถามกำกวมเอง หรือมีตัวเลือกสูสีสองตัว เราออกแบบให้เครื่องมือ ดู "รูปทรง" ของความมั่นใจ ไม่ใช่แค่ตัวเลขเดียว:

• มั่นใจชัด → ใช้เลย
• ก้ำกึ่งแต่พอได้ → ตอบไปก่อน พร้อมแนบหมายเหตุว่าตีความยังไง (ไม่บล็อก)
• สองตัวสูสีจริง + ต่างกันจริง → ค่อยถามผู้ใช้ยืนยัน (เกิดน้อยมาก)

หลักคือ: ถามยืนยันเฉพาะตอนที่ "คำตอบที่ถูกมีอยู่จริงแต่ Jev เลือกไม่ขาด" เท่านั้น ไม่ใช่ถามทุกครั้งที่ไม่มั่นใจ — ไม่งั้นก็กลับไปปิงปองเหมือนเดิม

3. หลายภาษา = ให้แปลเป็นอังกฤษก่อน (และนี่คือข้อจำกัดของ vector ไม่ใช่ Jev) เราลองศัพท์บัญชีลึกหลายภาษา เจอว่า "ค่าความนิยม" (goodwill) ภาษาไทย ตกไปอยู่อันดับ 45 ของ vector — หลุด top-15 ไป Jev เลยไม่เห็นให้เลือก ดูเผิน ๆ เหมือน Jev พัง

แต่เราพิสูจน์แล้วว่า เป็นความอ่อนของ vector (embedding) ข้ามภาษา ไม่ใช่ Jev — ถ้าถามคำเดียวกันเป็นภาษาอังกฤษ ("goodwill") มันขึ้นอันดับ 1 ทันที Jev เองก็รู้ว่า のれん (ญี่ปุ่น) = goodwill ด้วยซ้ำ

โชคดีที่เครื่องมือ MCP ของเรากำหนดให้ client แปลเป็นอังกฤษก่อนส่งอยู่แล้ว — ปัญหานี้จึงไม่เกิดในทางปฏิบัติ

4. เส้นแบ่งบาง ๆ ทางบัญชี — Jev ผ่านสวย เราจัดชุดทดสอบโหดสุด: คู่ศัพท์ที่ต่างกันนิดเดียวแต่คนละความหมาย

25 คู่โหด — Jev ถูก 100% ด้วยความมั่นใจเฉลี่ย 0.998 เทียบกับ vector อันดับ 1 ที่ถูกแค่ 48% นี่คือจุดที่ห่วงที่สุด (ตอบผิดแบบมั่นใจ) แต่กลับผ่านสบายในภาษาอังกฤษ

สรุป: เมื่อไหร่ควรยุบ resolver ด้วย Jev

จากที่ลองมา แนวทางที่ชัดคือ:

• catalog เล็ก (ไม่กี่สิบ): ให้ Jev เลือกจากทั้งชุดทีเดียว
• catalog ใหญ่ (ร้อย/พัน/หมื่น): ใช้ vector search กรองก่อนเหลือ ~10-15 → ให้ Jev เลือก — ยังยุบ round-trip และถูกลงพร้อมกัน
• มีทางลัด cache: คำที่เคยแปลแล้ว (เช่น "current assets" → CurrentAssets) เก็บผลไว้ ครั้งต่อไปคืนเลย ไม่ต้องเรียก Jev ซ้ำ

ทั้งหมดนี้ทำให้ MCP จาก "ปิงปองสี่รอบต่อคำถาม" เหลือ "รอบเดียว" — เร็วขึ้น ถูกลง และ LLM ฝั่ง client เบาลง

ข้อควรระวัง: อย่าเพิ่งสลับทั้งหมดในวันเดียว วิธีที่ปลอดภัยคือรัน Jev คู่ขนานกับของเดิมบน traffic จริงสักพัก เทียบผล ดู distribution ของความมั่นใจ แล้วค่อยเปิดทีละส่วน — และเตรียม fallback ไว้เผื่อ Jev ช้าหรือล่ม (เราวัดได้ว่าปกติ ~1 วินาที แต่มี tail ที่พุ่งได้เป็นสิบวินาที)

แต่ทิศทางชัด: resolver คือ "ภาษี round-trip" ที่ MCP จ่ายทุกคำถาม — Jev ช่วยจ่ายภาษีนั้นแทน และแม้ candidate จะเยอะแค่ไหน การจับคู่ vector + Jev ก็ยังยุบมันได้ ทั้งเร็วขึ้นและถูกลง

MarketDX แปลงข่าวการเงินเป็นกราฟผลกระทบ หัวใจคือขั้นตอน "อ่านข่าวแล้วจัดประเภท + ประเมิน" ที่ยิง ทุกข่าว ที่ไหลเข้ามา — เป็นงาน LLM ที่ volume สูงสุดในระบบ ถ้าแทนได้คือประหยัดก้อนใหญ่สุด เราเลยเลือกงานนี้เป็นสนามทดสอบจริง มันประกอบด้วย 4 การตัดสินใจย่อย:

1. ประเภทข่าว (news type) — ข่าวนี้เป็นแนวไหน (earnings / M&A / กฎหมาย / มาโคร / ฯลฯ)

2. ความสำคัญ (impact 1–5) — นักลงทุนควรสนใจแค่ไหน

3. เชื่อมกับธีมการลงทุน (megatrend) — ข่าวนี้เกี่ยวกับเทรนด์ไหน

4. รายละเอียดผลกระทบ — ทิศทาง (บวก/ลบ), ความแรง, ช่องทางที่กระทบ

เราลองทีละส่วน แล้วอ่านผลจริงทุกครั้ง นี่คือเรื่องราวที่เกิดขึ้น

ส่วนที่ 1: ประเภทข่าว — ดีกว่าที่ตัวเลขบอก

ให้ Jev เลือกประเภทจาก 16 แบบ (Choice) เทียบกับที่ระบบเดิมเคยจัด ผลแรก "ตรงกัน 74%" ดูเหมือนธรรมดา — แต่พออ่านเคสที่ไม่ตรงจริง ๆ กลับพลิก:

• ส่วนใหญ่ที่ "ไม่ตรง" คือ เส้นแบ่งที่กำกวมโดยธรรมชาติ (เช่น "บทวิเคราะห์ปรับราคาเป้า" vs "ปรับประมาณการกำไร") ซึ่ง Jev ก็ตอบได้สมเหตุสมผลพอ ๆ กัน

• บางเคส Jev ถูกกว่า — ข่าวเดียวกันที่ระบบเดิมจัดคนละประเภทในสองรอบ (ไม่คงเส้นคงวา) Jev จัดเหมือนกันทั้งสองครั้งและตรงเนื้อกว่า

กับดักเดียวที่เจอ: Jev ไม่ค่อยยอมตอบว่า "ข่าวขยะ/ไม่สำคัญ" (noise) — มันพยายามหาประเภท "จริง ๆ" ให้เสมอ วิธีแก้: ปรับคำสั่งเชิงนโยบาย บอกมันว่า "ข่าวขยะเป็นคำตอบปกติ อย่าฝืนยัดประเภทเพราะคำมันตรง" ผลคือ:

• ทดสอบกับข่าวชุดใหม่ที่ไม่เคยเห็น 45 ชิ้น: จับข่าวขยะได้ 20/20 และ ไม่มีสักครั้งที่เผลอตีข่าวจริงเป็นขยะ (0/25)

บทเรียน: bias ของ Jev แก้ได้ด้วยการปรับ "นโยบาย" ในคำถาม ไม่ต้องยกตัวอย่างป้อน

ส่วนที่ 2: ความสำคัญ (impact) — เจอ bias, แก้ได้, แถมจับ bug ของระบบเดิม

ถ้าให้ Jev ให้คะแนน 1–5 ตรง ๆ (Score เดียว) มันมี อคติเกาะกลาง — เกือบทุกข่าวได้ 3 และ ไม่เคยให้ 1 (ขยะ) เลย ใช้เป็น gate คัดกรองไม่ได้

วิธีแก้ที่ได้ผล — แตกเป็นคำถามย่อยแล้วรวมเอง: แทนที่จะถาม "สำคัญเท่าไร" ทีเดียว เราถามเป็นคำถามใช่/ไม่ใช่หลายตัว (มีข้อมูลใหม่จริงไหม / เป็นเรื่องใหญ่ผิดปกติไหม / เซอร์ไพรส์ไหม / กระทบวงกว้างไหม / เป็นโฆษณา/PR ไหม) แล้ว เอาคำตอบมาประกอบเป็นคะแนนเองด้วยสูตรที่เราคุมได้ ผลคือคะแนนกระจายสมจริง กลับมาให้ 1 กับข่าวขยะได้ และคัดโฆษณา/สแปมได้แม่น

เซอร์ไพรส์: ระหว่างทาง Jev จับ bug ของระบบเดิมได้ — ข่าวผลประกอบการจริงของบริษัทใหญ่ระดับผู้นำอุตสาหกรรม ถูกระบบเดิมตีเป็น "ข่าวสั้น/ไม่สำคัญ" (จากกฎความยาว) แต่ Jev ให้ความสำคัญสูงอย่างถูกต้อง — เป็นหลักฐานชัดว่า "การไม่ไล่ตามของเดิม" คือสิ่งถูกต้อง

ส่วนที่ 3: เชื่อมกับธีมการลงทุน — บทเรียนเรื่อง "บริบท" และ "การไล่จากบนลงล่าง"

นี่คือส่วนยากสุด: ธีม (megatrend) มี 25 หมวดใหญ่ + ~300 หมวดย่อย 3 ชั้น และข่าวส่วนใหญ่ ไม่แตะ ธีมไหนเลย

ความพยายามแรกล้มเหลว: ถามกว้าง ๆ ว่า "ข่าวนี้ขยับธีมไหนไหม" — Jev แยกข่าวที่แตะกับไม่แตะแทบไม่ออก เพราะคำถามนามธรรมเกินไป

สิ่งที่แก้ได้ (2 อย่าง):

1. ใส่บริบท ไม่ใช่แค่ชื่อ — ชื่อธีมสั้น ๆ กำกวม เราจึงแนบคำอธิบาย + ตัวอย่างของแต่ละธีมเข้าไปในคำถามด้วย

2. ถามเจาะทีละธีม แล้วไล่จากบนลงล่าง — เลือกหมวดใหญ่ก่อน → เจาะหมวดย่อย → เจาะย่อยลงอีก (แบบ drill-down)

พอทำสองอย่างนี้ ผลพลิกเป็นบวกชัด — Jev แทบไม่เคยเชื่อมข่าวไปผิดธีมเลย (ความแม่นสูงมาก)

คำถามเชิง "รสนิยมผลิตภัณฑ์" ที่ต้องตัดสิน: ควรเชื่อมแบบ "เข้มงวด" (เฉพาะข่าวที่ขยับทั้งธีมจริง ๆ) หรือ "ครอบคลุม" (ข่าวบริษัทใน sector นั้นก็เชื่อมได้)? เราเลือก "ครอบคลุม แต่ต้องไม่ทำให้คนอ่านแล้ว 'เอ๊ะ'" พอปรับคำถามตามนี้ Jev ทำได้ตรงเป้า — เชื่อมข่าวที่เข้ากัน (สายการบิน→ธีมการบิน, เหมืองทอง→ธีมวัตถุดิบ) และปฏิเสธที่ขัดตา โดยยังไม่เชื่อมไปผิดธีม

เจาะลงถึงหมวดย่อยชั้นลึก: เมื่อไล่ลงไปเลือกหมวดย่อยจริง ๆ Jev เลือก ตรง 80% / อยู่ถูกกลุ่ม 90% และหลายเคส Jev เจาะได้ ละเอียด/แม่นกว่าระบบเดิม (เช่นระบบเดิมหยุดที่ "โลหะมีค่า" แต่ Jev เจาะถึง "ทอง")

รายละเอียดผลกระทบ: ทิศทาง (บวก/ลบ) และความแรง — ทำได้ดี ส่วน "ช่องทางที่กระทบ" ตอนแรกดูเพี้ยน แต่พบว่าเป็นเพราะเรา ออกแบบผิด — เหตุการณ์หนึ่งกระทบหลายช่องทางพร้อมกัน (นโยบายโซลาร์ = ทั้งเรื่องราคา+ดีมานด์+กฎเกณฑ์) พอเปลี่ยนให้ตอบได้ หลายช่องทาง (multi-label) แทนที่จะบังคับเลือกอันเดียว ปัญหาก็หายไป

บทเรียนรวม 4 ข้อ

1. อย่าตัดสิน AI ใหม่ด้วยการวัดว่า "เหมือนของเดิม" — ของเดิมก็ผิดได้ (เราเจอ Jev จับ bug ระบบเดิมหลายครั้ง) ต้องอ่านผลจริงแล้วตัดสิน

2. อคติของ Jev แก้ได้ด้วย "นโยบาย" ในคำถาม — ไม่ต้องยกตัวอย่างป้อน (ซึ่งจะทำให้ผลลวง)

3. งานที่ซับซ้อน = แตกเป็นคำถามย่อยแล้วประกอบเอง — ทั้ง impact (แตกเป็นหลาย yes/no) และ megatrend (ไล่จากบนลงล่าง) ได้ผลดีกว่าถามรวดเดียว

4. ใส่บริบท และยอมให้ตอบได้หลายคำตอบ เมื่อความจริงเป็นแบบนั้น (ช่องทางผลกระทบ, ประเภทข่าว)

เทียบต้นทุน (ตัวเลขประมาณ, ต่อการตัดสินใจ 1,000 ครั้ง)

สมมติงานจัดประเภทข่าว 1 ครั้ง ป้อน ~1,200 token ได้คำตอบสั้น ๆ:

• Jev ถูกสุด — ประมาณ 3–10 เท่า เมื่อเทียบกับ LLM ตัวเล็ก/กลาง ส่วนหนึ่งเพราะ output ฟรี (ยิ่งถามหลายคำถามในครั้งเดียว ยิ่งได้เปรียบ)

• เทียบกับ vector embedding (อีกทางที่ราคาใกล้กัน) — คนละงานกัน: embedding บอกได้แค่ "อะไรคล้ายกัน" ตัดสินใจไม่ได้ ส่วน Jev ตัดสินใจได้เลย แพตเทิร์นที่ดีคือใช้คู่กัน (embedding คัดตัวเลือก → Jev ตัดสิน)

หมายเหตุ: ราคาเป็นค่าประมาณ ณ ปี 2026 และต้นทุนจริงขึ้นกับความยาว prompt ตัวเลขนี้ไว้ให้เห็น "อันดับความต่าง" ไม่ใช่บัญชีเป๊ะ

เรื่องความเร็ว: Jev ~1 วินาทีต่อครั้ง (นาน ๆ ทีมี spike หลายวินาที) — เร็วพอสำหรับงานตัดสินทีละข่าว แต่ ไม่ควรเอาไปวนลูปกับข้อมูลเป็นล้านตรง ๆ ควรคัดตัวเลือกด้วยวิธีที่ถูกกว่าก่อน

สรุป: เมื่อไหร่ควรใช้ Jev

ควรใช้ Jev เมื่อ งานเป็น "การตัดสินใจ" ที่ชัดเจน (จัดประเภท / ให้คะแนน / ใช่-ไม่ใช่), volume สูง, และต้องการความมั่นใจที่เชื่อถือได้เพื่อใช้เป็น gate — Jev ถูกกว่า เร็วพอ และคำตอบถูกล็อกให้อยู่ในกรอบ (สร้างคำตอบพิลึกไม่ได้)

ยังต้องใช้ LLM เมื่อ งานต้องเขียน อธิบายเหตุผล แปลภาษา หรือคิดหลายขั้น — Jev ทำไม่ได้ และไม่ได้ตั้งใจให้ทำ

ผลรวมจากการทดสอบ: บนงานจัดประเภท+ประเมินข่าวของ MarketDX ทั้งชุด Jev ทำได้ดีเท่าหรือดีกว่าระบบ LLM เดิมเกือบทุกจุด (จัดการข่าวขยะ/โฆษณา, ไม่เชื่อมผิดธีม, เจาะหมวดย่อยแม่น) ที่ต้นทุนถูกกว่าหลายเท่า

ข้อควรระวังก่อนใช้จริง (พูดตามตรง): ผลทั้งหมดนี้มาจากการที่เรา (ด้วย Claude Opus) อ่านและตัดสินบนตัวอย่างหลักร้อยข่าว — ไม่ใช่ว่าคุณภาพยังไม่ชัด แต่ก่อนจะเปลี่ยนระบบจริงควร รันคู่ขนานกับของเดิมบน traffic จริงสักพัก เพื่อยืนยันที่ปริมาณเต็ม เก็บชุดตัวอย่างมาตรฐานไว้เฝ้าคุณภาพ และเผื่อเรื่องความไม่คงที่เล็กน้อยของคำตอบ + spike ความหน่วงนาน ๆ ที

โดยรวม: สำหรับงานตัดสินใจปริมาณมาก Jev เป็นเครื่องมือที่คุ้มค่าและน่าลงทุนทำต่อ — ไม่ใช่มาแทน LLM ทั้งหมด แต่มาแทน "ส่วนที่เป็นการตัดสินใจ" ซึ่งจริง ๆ แล้วมีอยู่เยอะกว่าที่คิด

โมเดล AI ที่เราคุ้นเคย (LLM อย่าง GPT, Claude, Gemini, DeepSeek) ทำงานด้วยการ สร้างข้อความทีละคำ — คุณถาม มันเขียนคำตอบออกมาเป็นประโยค นั่นทรงพลังมากสำหรับงานเขียน สรุป แปล หรือคิดเป็นขั้นตอน

แต่ในซอฟต์แวร์จริง งานจำนวนมากไม่ได้ต้องการ "ข้อความ" — มันต้องการ การตัดสินใจ:

• ข่าวชิ้นนี้เป็นข่าวประเภทไหน?
• มันสำคัญระดับไหน (1–5)?
• เนื้อหานี้ควรทำต่อ หรือทิ้ง?

Jev (จาก TypeSafe AI) ถูกออกแบบมาเพื่อสิ่งนี้โดยเฉพาะ — มันไม่เขียนข้อความ แต่ เลือกคำตอบจากตัวเลือกที่เรากำหนด แล้วคืนค่าเป็นคำตอบที่มีชนิดชัดเจน (typed) พร้อมระดับความมั่นใจ (confidence) ทันที

มันมีคำถามอยู่ 3 แบบเท่านั้น:

• Choice — เลือก 1 จากตัวเลือกที่กำหนด (พร้อมความน่าจะเป็นของแต่ละตัว)
• Score — ให้คะแนนตามระดับที่นิยามไว้
• Noul — ใช่/ไม่ใช่ คืนเป็นความน่าจะเป็น 0–1

จุดที่น่าสนใจเชิงเศรษฐศาสตร์: Jev คิดเงินเฉพาะ input ส่วน output ฟรี และตอบเร็ว (หลัก ~1 วินาที) เพราะมันไม่ต้องไล่เขียนข้อความทีละคำ

คำถามหลักของเราคือ: โมเดลที่ "ตัดสินใจอย่างเดียว" แบบนี้ มันฉลาด/แม่นพอจะแทนงานที่วันนี้เราใช้ LLM ตัวใหญ่ทำอยู่ไหม? ตอนที่ 1 นี้เราเริ่มจากพื้นฐานที่สุด — มันเข้าใจภาษาและมีความรู้จริงหรือเปล่า ก่อนจะไปดูงานจริงในตอนที่ 2

MarketDX ทำอะไร?

MarketDX เป็นแพลตฟอร์มที่ แปลงข่าวการเงินเป็นกราฟผลกระทบ — อ่านข่าวแล้วบอกว่าข่าวนั้นกระทบสินทรัพย์/ธีมการลงทุนตัวไหน ทิศทางบวกหรือลบ และส่งต่อไปยังผู้เล่นที่เกี่ยวข้องอย่างไร เบื้องหลังมีงาน "ตัดสินใจ" แบบนี้อยู่เต็มไปหมด และหลายงานยิงทุกข่าวที่ไหลเข้ามา — ซึ่งแปลว่าถ้าลดต้นทุนต่อการตัดสินใจได้ ผลรวมมหาศาล จึงเป็นเหตุผลที่เราสนใจ Jev

หลักการทดสอบของเรา

ก่อนดูผล ต้องเข้าใจ 2 กติกาที่เรายึด เพราะมันเปลี่ยนวิธีอ่านผลทั้งหมด:

1. ตัดสินคุณภาพด้วยการ "อ่านเอง" (eyeball) ไม่ใช่ดูว่า "ตรงกับของเดิม" ของเดิมในระบบเราก็คือ LLM (ซึ่งบางทีก็ผิด) การวัดว่า Jev "ตรงกับ LLM เดิมกี่ %" จึงไม่ได้บอกว่า Jev ดีหรือแย่ — บอกแค่ว่ามันเหมือนของเดิมแค่ไหน เป้าหมายจริงคือ ให้ดีขึ้น ไม่ใช่เหมือนเดิม เราจึงอ่านผลลัพธ์จริงแล้วตัดสินเอง

2. เขียนคำถามให้โมเดลแบบไม่ "ใบ้คำตอบ" เราใส่ "นิยามงาน" ในคำถามได้ (เช่น บอกว่าให้ถือว่าความหมายเดียวกันแม้จะต่างที่ความสุภาพ) แต่เรา ไม่ใส่ตัวอย่างประโยคที่เฉลยคำตอบ เพราะนั่นทำให้ผลดูดีเกินจริง

บททดสอบ 1: ภาษา — เข้าใจ "ความหมาย" ข้ามภาษาไหม?

คำถามที่อยากรู้: ประโยค "กินข้าวหรือยังครับ" (สุภาพ) กับ "เฮ้ย แดกมายัง" (สแลงหยาบ) — Jev รู้ไหมว่ามันหมายความเดียวกัน? แล้วทำได้กี่ภาษา?

วิธี: เราสร้างประโยคเองใน 23 ภาษา (ไทย จีน ญี่ปุ่น อังกฤษ อาหรับ ฮินดี เกาหลี ฮกเกี้ยน ฯลฯ) แต่ละภาษามี 3 แบบ แล้วถาม Jev ว่าคู่ไหน "หมายความเดียวกัน":

• A vs B — สุภาพ ↔ สแลง (ความหมายเดียวกัน) → ควรได้คะแนนสูง
• A vs N — คล้ายกันมากแต่เจตนาต่าง (เช่น "กินข้าวมาหรือยัง" [ถาม] vs "กินข้าวมาแล้วเหรอ" [ทวงแบบรู้อยู่แล้ว]) → คลุมเครือ
• A vs C — คนละเรื่อง ("กินข้าวยัง" vs "หิวข้าวยัง") → ควรได้คะแนนต่ำ

ผล (ค่าเฉลี่ยทั้ง 23 ภาษา, คะแนน 0–1):

อ่านผล: Jev ไล่ระดับได้ถูก (เหมือนชัด > ก้ำกึ่ง > ต่าง) เกือบทุกภาษา และทำได้ทั้ง 23 ภาษารวมสแลง — ไม่ใช่เก่งแค่อังกฤษ ที่น่าประทับใจคือมันแยก "หิว" ออกจาก "กินแล้ว" ได้ทั้งที่ประโยคหน้าตาคล้ายกันมาก

จุดอ่อนที่เจอ (มีจริง):

• ภาษาถิ่นข้อมูลน้อย (ฮกเกี้ยน) อ่อนสุด — แยกความหมายใกล้ ๆ ได้ไม่คมเท่าภาษาหลัก
• สำนวนกำกวม เช่น "have your tea" ในอังกฤษ (แปลว่ากินมื้อเย็นก็ได้ ดื่มชาก็ได้) — Jev เลือกความหมายตรงตัว

เกร็ดที่เจอระหว่างทาง: เรายิงคำถามเดิมซ้ำ 3 ครั้ง จำนวน token ที่คิดเงินเท่าเดิมทุกครั้ง → Jev ไม่มีส่วนลดแบบ cache (ต่างจาก LLM หลายเจ้า) ถ้าจะประหยัดต้องเขียนคำถามให้สั้น หรือรวมหลายคำถามในครั้งเดียว

บททดสอบ 2: ความรู้รอบโลก — ตื้นและลึก

คำถามที่อยากรู้: นอกจากเข้าใจภาษา มันมี "ความรู้" จริงไหม ทั้งความรู้ทั่วไปและความรู้เฉพาะทางเชิงลึก?

วิธี: ข้อสอบปรนัย 4 ตัวเลือก 75 ข้อ แบ่ง 3 ระดับ × 15 สาขา (บัญชี กฎหมาย การเงิน แพทย์ ฟิสิกส์ ประวัติศาสตร์ ปรัชญา ฯลฯ):

• ทั่วไป — ความรู้กว้าง ๆ
• ตื้น — ระดับที่นักศึกษาสาขานั้นควรตอบได้
• ลึก — เฉพาะทางจริง เช่น การลงบัญชีค่า R&D ระหว่างมาตรฐาน IFRS กับ US GAAP, ยุคยาโยยของญี่ปุ่น, Gettier problem ในปรัชญา, ทฤษฎี Modigliani–Miller ทางการเงิน

(เราสลับตำแหน่งตัวเลือกทุกข้อ กันไม่ให้เฉลยไปกองอยู่ตัวเลือกเดิม)

ผล:

ความมั่นใจของ Jev เกือบทุกข้อ = ~1.00 และตอบถูกแม้ข้อเชิงลึกเฉพาะทาง

อ่านผลอย่างซื่อสัตย์: 100% น่าประทับใจ แต่ก็แปลว่า เรายังหา "เพดาน" ของมันไม่เจอ — ข้อสอบเชิงลึกของเราถึงจะเฉพาะทาง แต่ก็ยังเป็นความรู้ที่มีในตำรา เรายังไม่ได้ลองความรู้ที่กำกวม/มีข้อถกเถียง หรือโจทย์ที่ต้องใช้เหตุผลหลายชั้น สรุปได้แค่ว่า "ความรู้กว้างและลึกพอ" ไม่ใช่ "ไม่มีขีดจำกัด"

สรุปตอนที่ 1

สองบททดสอบพื้นฐานนี้ตอบคำถามว่า "Jev ฉลาดพอไหม" ได้ค่อนข้างชัด:

• เข้าใจภาษา/ความหมาย ข้าม 23 ภาษา รวมสแลงและ register ต่าง ๆ ได้แม่นและไล่ระดับความคล้ายได้จริง
• มีความรู้ ทั้งกว้างและลึกในหลายสาขา
• เร็ว (~1 วินาที) และคิดเงินเฉพาะ input

พอเห็นว่าพื้นฐานแน่น เราจึงกล้าเอาไปลองกับ งานจริงของ MarketDX — ซึ่งเป็นเรื่องของ ตอนที่ 2: เราเอา Jev ไปแทนงานตัดสินใจที่ยิงทุกข่าว ผลเป็นยังไง เจอกับดักอะไร แก้ยังไง และถ้าเทียบต้นทุนกับ LLM เดิม (DeepSeek / OpenAI / Gemini) มันคุ้มแค่ไหน