DEV Community: Ohad Farkash

Shopping search translation is mostly query expansion: what 941 real queries showed

Ohad Farkash — Thu, 01 Oct 2026 16:22:27 +0000

I run OneFindMe, a search front-end for AliExpress that takes a query in Hebrew, Arabic, Russian, German and eight other languages and turns it into the short English query the marketplace actually indexes. I always described that step as "translation". After exporting 941 of those query pairs and looking at them properly, I don't think it is.

The data

The pairs come from the engine's keyword map: hand-curated mappings, mappings the engine learned and kept, and a sample of real searches. Every row is a shopper's query, its language, and the English query that retrieved the right products. It is heavily Hebrew (862 of 941 rows), so treat the other languages as examples, not statistics.

It is public under CC BY 4.0: Kaggle, Hugging Face and Zenodo (DOI 10.5281/zenodo.22930843). The full analysis is a Kaggle notebook; every number below comes from it.

Finding 1: the query usually gets longer

If this were translation, you would expect the English side to be about as long as the source, or shorter once the filler is gone. For Hebrew:

	share of queries
English query has more words	59.5%
same number of words	30.4%
fewer words	10.1%

Average length goes from 2.35 words to 3.10. The rewrite adds information far more often than it removes it.

Finding 2: what gets added is who it is for, and what form it comes in

The most frequent words on the English side are not product nouns. They are audience words and bundle words:

37% of English queries contain an audience word (women, men, baby, kids…)
15% contain a bundle word (set, kit, pack, pcs)

Some curated pairs (glosses in brackets):

shopper typed	meaning	marketplace query
חצאית	skirt	`women skirt`
טיולון לתינוק	stroller for a baby	`baby lightweight stroller`
שייקר	shaker	`protein shaker bottle mixer`
מגהץ	iron	`garment steamer handheld clothes`
דיפ פאודר	dip powder	`dip powder nail kit`
נעלי טרום הליכה	pre-walking shoes	`baby prewalker shoes soft sole`

The Hebrew for "skirt" doesn't need the word "women"; context and grammatical gender carry it. A listing title on AliExpress does need it, because that is how sellers write titles and how the marketplace's search matches them. The same goes for "shaker": in Hebrew, in a shopping context, it means the gym bottle. The English word alone is ambiguous.

Finding 3: when it gets shorter, it is dropping noise

The 10% that shrink are mostly shoppers putting conditions into the query:

shopper typed	meaning	marketplace query
כפכפי נשים מותג משלוח חינם	women's slippers brand free shipping	`women slippers brand`
מצעים תקציב נמוך	bedding, low budget	`bedding set`

"Free shipping" and "low budget" are filters, not product words, and putting them in the search string hurts more than it helps.

What I changed my mind about

It is expansion, not translation. A plain MT model gives a correct "skirt" and drops the word that listing titles lead with. The target isn't the most faithful English sentence. It is the query in the vocabulary the listings are written in.
Evaluate on retrieval, not fluency. BLEU against this target column would reward the right words, but the real test is whether the query returns the intended products. A fluent but literal translation can score fine on text overlap and still retrieve the wrong things.
Curate the head, generate the tail. The curated rows are the high-traffic queries, checked by hand. The long tail is rewritten by a language model with instructions to produce marketplace vocabulary, and the results are cached so the next shopper with the same query gets an instant answer.

Caveats

The data is mostly Hebrew. Rows marked observed are tagged with the language of the page the search was made on, not the language of the text, so a few carry a tag that doesn't match their script. I haven't measured retrieval quality per row here, only the shape of the rewrites.

If you build multilingual search for e-commerce, I'd be curious whether you see the same expansion pattern in your languages.

Written with AI assistance; the numbers are computed from the dataset in the linked notebook.

What my blind brother taught me about making a shopping search engine work with VoiceOver

Ohad Farkash — Sun, 27 Sep 2026 16:01:59 +0000

My brother is blind. When I asked him to try the shopping search engine I'd been building, OneFindMe, with VoiceOver on his iPhone, the automated checker had already told me the site was in decent shape. The first thing he tried, voice search, did nothing at all. That sent me looking for everything else the checker couldn't see.

This is what changed, what I got wrong, and the parts that were more interesting than I expected.

axe is about a third of the job

I started where everyone starts: axe-core against the home page and a results page, desktop and mobile. It found real problems. Two sort/filter <select>s had no accessible name, 130 to 250 grey 7px labels failed contrast, and there was no main landmark. All fixed, and the scan went to zero.

Then I went through the site the way my brother uses it, keyboard and screen reader only, and a different list appeared, none of it visible to axe:

Pop-up windows that didn't exist for a screen reader. Favourites, price alerts and "similar products" were plain <div>s. They opened on screen, focus stayed behind them, and VoiceOver said nothing.
Results that arrived in silence. A sighted user sees the grid fill in. A blind user had no idea the search had finished.
The wrong things first. The "trending" rail sits above the results in the DOM, so a screen reader reading from the top met a row of unrelated bestsellers before the thing you searched for.
Dead buttons. A ☰ menu button, "Home" and "History" in the bottom bar: visible, focusable, and wired to nothing. For a sighted user that's a small annoyance. For a screen reader user it's a trap.
Emoji read aloud. "Fire. Daily deals." "Bell. Price alerts." Every one of them.
Dark-mode bugs that hit everyone. A white "Load more" button with light text on it (1.2:1), and a help card with the same problem. I'd only ever looked at dark mode on the results page.

One sentence per product

A product card is a link wrapping an image, a badge, two prices, a title, a rating and an order count. Read in DOM order, that came out as "Top pick, minus sixty-six percent, 15.04, 30.70, Baby cup…". I replaced it with one aria-label on the link:

const a11yLabel = [
  shownTitle,
  `${sym}${p.price}` + (p.discount > 0 ? ` (${t.was} ${sym}${p.original_price})` : ""),
  p.rating ? `${t.rating} ${p.rating.toFixed(1)} ${t.of5}` : "",
  orders > 0 ? `${orders.toLocaleString()} ${ordersLabel}` : "",
  p.free_shipping ? t.freeShip : ""
].filter(Boolean).join(", ");

The Save and Share buttons now say which product they belong to. Forty identical "Save" buttons in a row are useless.

Announcing results

A polite live region, plus one detail that took me a while to find: a screen reader only speaks a live region when its text changes. Two identical searches in a row were silent. Clearing the region first and filling it on the next tick fixes that:

function announce(msg) {
  el.textContent = "";
  setTimeout(() => { el.textContent = msg; }, 60);
}

After a search I also move focus to the results heading with focus({ preventScroll: true }). The reading position jumps to the results, and a sighted visitor sees nothing move. I skip this while focus is in the filter bar, because arrowing through a <select> fires change on every step.

"Describe this product"

This is the part I'm proudest of, and the one I most expected to get wrong.

On AliExpress the titles are keyword piles ("2026 Summer Men's Dad Sneakers Breathable…"). The real information is in the photo, which a blind shopper can't see. So every result now has a button, visually hidden but reachable by keyboard and screen reader, that sends the product photo to a vision model. The model describes what is actually shown, in the page's language.

Some notes:

Model choice mattered more than I thought. I compared Haiku, Sonnet and Opus on the same photos in Hebrew. Haiku invented parts that weren't there. For someone who can't check the photo, a confident wrong description is worse than none. Sonnet was as accurate as Opus and about two seconds faster, which matters when someone is waiting.
The prompt says what not to do. Describe only what is visible. Never invent sizes, brands or specifications. If unsure what a part is, leave it out.
Cache per product and language. Each product is paid for once, about 0.6 cents. The second request is instant.
Allowlist the image host. The endpoint only accepts AliExpress image URLs. Otherwise it's a free vision API on my key. The first version rejected every real result, because result cards load images through my own /img?url= proxy. It now unwraps that.

Voice search and VoiceOver

Two surprises:

Don't announce "listening". My first instinct was to have the page say "Listening, speak now". But VoiceOver would read that text out loud while the microphone is open, and the recogniser would happily transcribe it as your search. So the page stays silent while listening, and only speaks when something goes wrong.
iOS fails silently. When speech recognition isn't allowed (for example with Dictation turned off), Safari's recogniser throws an error and the page just went quiet. Every failure path now says what happened and offers the keyboard's own dictation microphone, which works in every browser.

Why I built a menu instead of installing an overlay

Accessibility overlays (the widget with the wheelchair icon) are popular, and they don't make a site accessible. Many blind users actively dislike them, because they fight with the screen reader. My brother's VoiceOver run needed nothing extra.

What is useful for low-vision visitors is a small, boring menu: three text sizes, high contrast, stop animations, highlight links, a readable font, and a voice-search language picker. I built my own, and it stays out of the screen reader's way.

Two gotchas from that:

The site is laid out in px, so changing font-size did nothing. body.style.zoom does what browser zoom does: it enlarges and reflows, with no horizontal scroll on a 390px screen.
One page monkey-patched document.getElementById. For missing ids it returned a truthy no-op stub. Every "does my element already exist?" check said yes, so the menu, the live region and the stylesheet were never created. That page now gets a querySelector-based lookup.

Where it stands

axe: zero violations on the home page in Hebrew, English and Arabic (light and dark), and on results pages in Hebrew and English (desktop and mobile).
Keyboard: skip link, visible focus everywhere, dialogs that trap focus and return it on Escape, background inert while a dialog is open.
Real use: my brother, with VoiceOver, on his phone. His verdict after the fixes: everything is accessible the way it should be. He's still using it and sending notes.

It's in beta, and some product titles still arrive in English because sellers write them that way. That's exactly what the describe button is for.

Disclosure: OneFindMe is free, with no signup, and funded by affiliate commissions from the stores, at no extra cost to buyers. I wrote this with help from an AI assistant; the code, the measurements and the testing with my brother are real.

My demo videos found 5 bugs my tests didn't: 13-language product demos from real screenshots

Ohad Farkash — Fri, 25 Sep 2026 17:41:48 +0000

I run a small search engine that sits in front of AliExpress: you describe a product in your own language, typed or spoken, and it turns that into the short English keywords the marketplace actually matches on. The site has pages in 12 languages and understands queries in 21.

I wanted a short demo video for each language. Recording 13 screen captures by hand, on a phone, from 13 "countries", was not going to happen, so I generated them from the live site instead. The videos turned out fine. The more useful result was that making them exposed five bugs that my checks had never caught.

The pipeline

Four steps, all Python:

Capture. Headless Chrome through Selenium, with mobile emulation at 412 px wide and a device pixel ratio of 2. For each query the script loads the real search URL, waits until the product grid has real cards, and saves one tall screenshot plus the positions of the elements it needs later: the search box, the results heading, the store filter bar and the voice button.
Pretend to be somewhere else. The site decides the shipping country and currency from Cloudflare's /cdn-cgi/trace endpoint, fetched with a synchronous XHR. I didn't want a German video showing Israeli shekels, so before the page loads the script patches XMLHttpRequest to answer that one request with loc=DE:

driver.execute_cdp_cmd("Page.addScriptToEvaluateOnNewDocument", {"source": r"""
  (() => { const O = XMLHttpRequest.prototype.open, S = XMLHttpRequest.prototype.send;
    XMLHttpRequest.prototype.open = function (m, u) { this.__trace = String(u).includes('/cdn-cgi/trace'); return O.apply(this, arguments); };
    XMLHttpRequest.prototype.send = function () {
      if (!this.__trace) return S.apply(this, arguments);
      Object.defineProperty(this, 'status', { value: 200 });
      Object.defineProperty(this, 'readyState', { value: 4 });
      Object.defineProperty(this, 'responseText', { value: 'fl=1\nloc=DE\n' });
    }; })();"""})

Note the r""". My first version was a normal string, Python turned \n into a real newline inside a JavaScript string literal, the script died silently, and every "German" capture came back in shekels.

Compose. PIL draws each frame: a phone frame on the left that scrolls from the typed query down to the results, and the query and a caption on the right.
Encode. imageio-ffmpeg pipes raw frames into libx264. Set macro_block_size=1, or it quietly pads 1080 to 1088 and stretches everything.

A second script reuses the same screenshots for vertical 1080×1920 Shorts. It keeps the site address fixed at the top of the frame, because links in Shorts descriptions aren't clickable.

Right-to-left and CJK without raqm

My PIL build has no raqm, so it can't shape complex scripts on its own. Three things had to be handled by hand:

Hebrew: reorder with python-bidi. But wrap in logical order first, then reorder each line. Wrapping an already reordered string splits it in the wrong places.
Arabic: run arabic_reshaper before bidi, or the letters don't join.
Japanese: there are no spaces, so wrapping has to break per character. The fonts are also different: Inter has no CJK glyphs, and my first Japanese render showed the query as a row of black boxes.

The five bugs the videos found

This is why I'm writing this up. To make a video I had to look at every screen, in every language, as a visitor from that country.

1. A Hebrew button on every page. The share button next to the results heading said "שתף" (Hebrew for "share") in German, French and Polish. There were three copies of the label in the code. My grep for the Hebrew word found one. The other two were written as \u05e9\u05ea\u05e3 escapes, and a text search for Hebrew never sees those.

2. English in the middle of German. The related-search chips for German, Italian, Polish and Filipino fell back to English, so users saw suggestions like "kabellose kopfhörer for men". The dictionaries for those languages simply didn't exist.

3. "Baby night lamp for women." The chip generator added gender suffixes to every query, so a specific search got a nonsense suggestion. It now adds suffixes only to queries of one or two words.

4. Everyone on the English page was American. The English page is also the home of every country without its own page. Its settings mapped to US/USD, so a visitor from Tokyo or London got US shipping, dollar prices, and an eBay-US row whose "fast delivery" badge was true only in the US. The fix maps the visitor's real country to a currency. Before enabling it, I tested country-plus-currency pairs live against the search API: every non-euro currency individually, the euro countries by sampling. 36 countries are on the list now. India and Indonesia returned zero products when shipping there, so they stay on the default.

5. Results I refused to show. In Turkish the translation was right, but the marketplace's own ranking for Turkey was thin: most listings had about one order, and one smartwatch had a phone number printed on the image. In Arabic, "small cabin bag for a flight" translated correctly to "cabin travel bag" and still returned motorcycle crash bars, which is a marketplace problem, not a translation one. In both cases I cut the scene. A demo that has to hide weak results tells you something too.

What I took from it

Generating marketing material from the live product works like an end-to-end test with human eyes: every language, every locale, the real page. It found five real bugs in a single afternoon, none of which any of my existing checks had flagged. The rule I'm keeping: capture, look at every frame, and cut anything you wouldn't want a user to see, instead of retouching it.

The engine is at onefindme.com if you want to try breaking it in your language.

Written with AI assistance. The numbers and bugs come from the actual captures and fixes.

Voice search for AliExpress in 12 languages: what I learned building it

Ohad Farkash — Mon, 21 Sep 2026 07:29:28 +0000

AliExpress has a microphone in its app, and it mostly understands English. That is the whole state of voice shopping on the world's largest marketplace. So when I added voice search to OneFindMe — a free search layer for AliExpress that works in 12 languages — I expected the hard part to be speech recognition. It wasn't. Here is what actually mattered.

Recognition was the easy part

Modern browsers ship speech recognition (the Web Speech API). Chrome and Edge on desktop and Android, Safari on iOS — the coverage is good enough that I did not need an audio pipeline, a model, or a server. The user taps the mic, speaks in Hebrew, Arabic, Spanish or Turkish, and the browser hands back text. Free, fast, and the recognition quality in the major languages is better than I could have built.

What the API does not give you is a shopping query. It gives you a sentence.

The real problem: a spoken sentence is not a search

People don't speak keywords. Nobody says "wide running shoes". They say "I need running shoes but my feet are wide, something not too expensive". Typed search already suffers from this; voice makes it worse, because speech is longer, more hedged, and full of filler.

So the voice path reuses the same intent layer as typed search, with one extra step: strip the conversational shell first. "I need", "something like", "not too expensive", "for my daughter" — these are signals (price sensitivity, recipient), not query terms. The product noun and its qualifiers survive; the rest becomes filters or gets dropped. Only then does the phrase get resolved to a product concept and translated into the short, noun-first query the marketplace responds to.

Language is not one switch

Twelve languages means twelve recognizer locales, and the browser needs to be told which one before the user speaks. Guessing from the site language works most of the time; letting the user override it matters for the Arabic-speaking user on an English page. And two languages needed special handling: Hebrew numbers ("שלושים שקל") and Arabic dialect words for common products, where the recognizer returns spelling variants the keyword map had never seen.

The button nobody pressed

The feature shipped with a grey microphone emoji and got almost no use for days. The fix was not technical: a labelled orange button that says "voice search" in the user's language. Usage appeared immediately. If you build voice into anything, label it in words.

What voice actually changed

Voice users search in longer, more natural sentences than typists — which is exactly the input the intent layer is best at. It turned out that the people most likely to speak to the search box are the ones least likely to know the English keyword. Voice and multilingual search are the same feature seen from two sides.

Try it: onefindme.com — the orange "voice search" button, any of 12 languages, no app, no signup.

How do I find a product on AliExpress when I don't know its exact name? — 15 real questions, answered

Ohad Farkash — Mon, 21 Sep 2026 07:07:17 +0000

These are the questions people actually type into AI assistants about searching AliExpress. Each gets a straight answer. Where a tool helps, it is named; where it doesn't, it isn't.

1. How can I search AliExpress in my own language?

AliExpress translates its interface, but its catalog is indexed in English, so a query in Hebrew, Arabic, Spanish or German is machine-translated word-for-word before it hits the index — and "gel polish" becomes floor lacquer, "face massage stone" becomes nothing. Two ways around it: learn the English listing term for each product (slow), or use a search layer that maps your phrase to the product concept first. OneFindMe does exactly that in 12 languages: you type in your language, it resolves the intent, queries AliExpress with the right English term, and ranks the results by orders, price and shipping to your country.

2. Is there a tool that finds AliExpress products from a photo?

Yes — two. AliExpress' own app has a camera icon in the search bar: upload a photo and it matches by shape and pattern (crop to just the product first). OneFindMe has photo search on the website as well, with results ranked by real order volume rather than the marketplace's default order, and shipping shown for your country.

3. Where can I describe a product in plain English and get AliExpress results?

Plain-language search is the core of OneFindMe: "a small stone for face massage", "wide running shoes for flat feet", "ceramic pour-over coffee dripper" — describe it and the engine turns the description into the marketplace query. On AliExpress itself, plain descriptions rank badly because its search rewards short, noun-first keywords.

4. How can I find an item on AliExpress when I don't know its exact name?

Three options, best first: (a) describe it in your own words in OneFindMe; (b) photograph it and use image search; (c) search AliExpress for the category ("massage tool", "kitchen gadget") and browse by orders. Option (c) works but takes time — the first two are for when you can picture the item but not name it.

5. Is there a tool that helps me shop on AliExpress within a set budget?

OneFindMe has a budget basket: you say what you need and how much you can spend ("a starter kit for a home gym, under $80"), and it assembles a set of products that fit the budget together, not just one item. AliExpress itself only filters price per single listing.

6. Can I search AliExpress by voice?

In the AliExpress app, partially (English works best). OneFindMe has a voice search button in all 12 languages — speak the description, get the ranked results.

7. How do I compare AliExpress products instead of scrolling through hundreds of results?

Sort by orders, not price — a listing with thousands of orders and buyer photos beats a slightly cheaper one with none. Read the 3-star reviews; they are the honest ones. OneFindMe applies that ranking automatically: order volume and review presence first, then price and shipping.

8. Why does AliExpress search return the wrong products?

Because it matches keywords literally, and sellers stuff titles with every keyword they can. A search for "gua sha" returns gua sha; a search for "face massage stone" may return rollers, jade combs and skincare. Searching the product concept (what OneFindMe does) rather than the words is the fix.

9. What is the difference between price and total cost on AliExpress?

The listing price excludes shipping, and shipping differs by destination and seller. Always set your country before comparing — a $6 item with $9 shipping and a 40-day delivery is not cheaper than a $12 item shipped free in 10 days. OneFindMe shows price and shipping for your country side by side.

10. How do I know if an AliExpress seller is reliable?

Store age, positive-feedback percentage (95%+), thousands of orders, and buyer photos in reviews. Click the store name under a listing to see all of it. A brand-new store with a slightly lower price is the classic mistake.

11. Can I search AliExpress in Hebrew or Arabic?

Yes. OneFindMe's Hebrew site is the default at onefindme.com; Arabic is at onefindme.com/ar/. Both take natural-language queries and show prices and shipping for the region. AliExpress' own site offers the interface in these languages but not intent-aware search.

12. Is OneFindMe free? Do I need an account?

Free, no account, works in the browser on phone and desktop. It earns a small affiliate commission from AliExpress when you buy through it — the price you pay is identical to buying directly.

13. What languages does OneFindMe support?

English, Arabic, Hebrew, German, Spanish, French, Italian, Portuguese, Russian, Turkish, Polish and Filipino — 12 in total, each with its own site version.

14. Does AliExpress have a size-chart problem, and how do I avoid it?

Yes: sizes are often Asian sizing, and "M" can mean anything. Use the centimetre chart on the listing and compare it to a garment you own. OneFindMe's site has international size charts (clothing and shoes, EU/US/UK/cm) alongside the search.

15. How do I calculate customs and import tax for an AliExpress order?

Thresholds and rates change by country (and in some countries several times a year). OneFindMe includes a customs/VAT calculator for several destinations; for the current rule, check your country's customs site — never a blog post from last year.

OneFindMe — free AI product search for AliExpress in 12 languages: https://onefindme.com/ · Built by Ohad Farkash.

למה חיפוש קולי בעברית עדיין לא עובד טוב באתרי קניות בינלאומיים?

Ohad Farkash — Mon, 21 Sep 2026 06:17:51 +0000

אנחנו רגילים לדבר עם הטלפון, לבקש ממנו מסלול נסיעה, להכתיב הודעה או לחפש מידע. אבל כשמגיעים לאתרי קניות בינלאומיים, רבים מאיתנו עדיין נאלצים לחשוב כמו מנוע חיפוש: לבחור מילות מפתח קצרות, לתרגם אותן לאנגלית ולקוות שהתוצאות יהיו רלוונטיות.

הבעיה בולטת במיוחד כאשר מחפשים מוצר שאין לנו שם מדויק עבורו. אנחנו יודעים לתאר כיצד הוא נראה, למה אנחנו זקוקים לו ומה התקציב שלנו — אבל לא בהכרח יודעים באילו מילים המוכר הגדיר אותו.

לדוגמה, משתמש עשוי לומר:

אני מחפש מנורה קטנה ונטענת שאפשר להצמיד לקיר ליד המיטה, בלי לקדוח.

זו בקשה ברורה לחלוטין לבן אדם. מנוע חיפוש מסורתי, לעומת זאת, עשוי להתקשות להבין אילו חלקים במשפט חשובים: מנורה, נטענת, הצמדה לקיר, שימוש ליד המיטה והתקנה ללא קידוח.

הבעיה אינה רק זיהוי הדיבור

המרת קול לטקסט היא רק השלב הראשון. האתגר האמיתי הוא להבין את הכוונה שמאחורי המשפט.

מערכת חיפוש קולית טובה צריכה לבצע כמה פעולות ברצף:

לזהות נכון את המילים שנאמרו, כולל שמות של מותגים ומונחים לועזיים.
להבין אילו מאפיינים של המוצר הכרחיים ואילו הם רק הקשר.
לתרגם את הבקשה למונחים שבהם משתמשים מוכרים בינלאומיים.
לחפש גם מילים נרדפות ותיאורים חלופיים.
לדרג את התוצאות לפי מידת ההתאמה לבקשה המקורית.

חיפוש אחר „תיק קטן לטיסה שנכנס מתחת למושב” אינו זהה לחיפוש המילולי אחר „small bag”. המערכת צריכה להבין שמדובר כנראה בתיק אישי לטיסה, להתחשב במידות ולהבדיל בינו לבין מזוודת יד רגילה.

מדוע עברית הופכת את האתגר למורכב יותר?

באתרי מסחר בינלאומיים, שמות המוצרים והתיאורים נכתבים בדרך כלל באנגלית או מתורגמים אוטומטית משפות אחרות. התרגום אינו תמיד טבעי ולעיתים אותו מוצר מופיע תחת כמה שמות שונים.

גם לעברית עצמה יש מאפיינים שמקשים על החיפוש:

מילה אחת עשויה להופיע בצורות שונות בגלל תחיליות וסיומות.
משתמשים משלבים עברית ואנגלית באותו משפט.
שמות מותגים נכתבים לעיתים בעברית ולעיתים באותיות לטיניות.
אנשים מתארים את השימוש במוצר במקום את שמו.
שפת הדיבור שונה מהמונחים המופיעים בקטלוגים.

משתמש עשוי לומר „כפכפים חומים עם פרווה מאחור”, בעוד שבקטלוג המוצר יופיע תחת מונחים כמו mule, clog, slipper או fur-lined shoe.

תרגום מילולי של המשפט אינו מספיק. יש צורך בשכבת הבנה שמחברת בין האופן שבו אדם מתאר מוצר לבין האופן שבו המוצר מסווג בקטלוג.

מחיפוש של מילים לחיפוש של כוונה

מנועי חיפוש מסורתיים מנסים למצוא התאמה בין מילות השאילתה לבין הטקסט שמופיע בדף המוצר. חיפוש מבוסס בינה מלאכותית מנסה להבין מה המשתמש באמת רוצה למצוא.

במקום לפרק את הבקשה רק למילות מפתח, המערכת יכולה לזהות מאפיינים כמו:

סוג המוצר
צבע וחומר
שימוש מיועד
טווח מחיר
קהל יעד
מידות
תכונות שחייבות להופיע
תכונות שצריך להימנע מהן

אם משתמש אומר „אני צריך מתנה לילד בן עשר שאוהב חלל, עד 100 שקל”, החיפוש אינו צריך להתמקד רק במילים „ילד”, „חלל” ו„100 שקל”. עליו להבין שמדובר ברעיון למתנה, להתאים את המוצרים לקבוצת הגיל ולכבד את מגבלת התקציב.

למה קול מתאים במיוחד לחיפוש מוצרים?

בשדה חיפוש רגיל אנשים נוטים לכתוב שתיים או שלוש מילים. בדיבור הם מספקים באופן טבעי יותר פרטים:

אני מחפשת תיק שחור קטן לערב, עם רצועה ארוכה, שלא יהיה מבריק מדי.

המידע הנוסף יכול לשפר את התוצאות — בתנאי שהמערכת מסוגלת להבין אותו. החיפוש הקולי אינו רק תחליף למקלדת; הוא מאפשר למשתמש לנסח צורך שלם במקום לנחש את מילות המפתח הנכונות.

הוא עשוי להיות שימושי במיוחד בנייד, בזמן נסיעה, עבור אנשים שמתקשים להקליד או כאשר שם המוצר אינו ידוע.

הניסיון של OneFindMe

במהלך העבודה על OneFindMe ניסיתי להפוך את החיפוש באתרי מסחר לשיחה טבעית יותר. המשתמש יכול לתאר בעברית את המוצר שהוא רוצה, להשתמש בחיפוש קולי או להעלות תמונה, והמערכת מתרגמת את הבקשה לחיפוש מוצרים מתאים ב־AliExpress.

המטרה אינה רק להמיר עברית לאנגלית. המערכת צריכה לזהות את סוג המוצר, להבין את המאפיינים החשובים וליצור שאילתות שמתאימות לאופן שבו המוצרים מתוארים בפועל.

לדוגמה, הבקשה „מדף קטן למקלחת שלא צריך לקדוח בשבילו” צריכה להוביל למוצרים המוגדרים כמדפים הנצמדים באמצעות דבק או ואקום — גם אם המילים המדויקות שאמר המשתמש אינן מופיעות בכותרת המוצר.

עדיין קיימות מגבלות

חיפוש קולי אינו פתרון קסם. רעשי רקע, מבטאים, שמות מותגים ומילים שמשלבות עברית ואנגלית עלולים לגרום לטעויות. גם לאחר שהדיבור זוהה נכון, המערכת עלולה לפרש באופן שגוי את הכוונה.

לכן חשוב לאפשר למשתמש לראות את הבקשה שזוהתה, לערוך אותה ולהמשיך לחדד את התוצאות. שילוב נכון בין קול, טקסט ותמונה עשוי להיות יעיל יותר מהסתמכות על דרך חיפוש אחת בלבד.

העתיד של חיפוש המוצרים

המעבר הגדול אינו ממקלדת למיקרופון, אלא מחיפוש המבוסס על מילות מפתח לחיפוש המבוסס על שיחה וכוונה.

במקום ללמוד כיצד הקטלוג מנסח את שמות המוצרים, המשתמש יוכל פשוט להסביר מה הוא מחפש. המערכת תהיה זו שתצטרך להבין, לתרגם ולמצוא את ההתאמה.

כאשר זה יעבוד היטב בעברית ובשפות נוספות, חיפוש מוצרים בינלאומי ירגיש פחות כמו פתרון חידה — ויותר כמו שיחה עם אדם שמבין מה אנחנו רוצים.

What I learned building a 12-language AI product search for AliExpress

Ohad Farkash — Sun, 20 Sep 2026 11:16:33 +0000

AliExpress has one of the largest product catalogs on the planet, but its search
assumes you already know the exact English keyword. If a shopper can only describe what they
want — "that little stone thing for face massage" — the results collapse into noise. I spent a
while building OneFindMe, a free multilingual search layer that sits in front of AliExpress,
and these were the lessons that actually moved the needle.

1. Translating the intent, not the words

Naive translation is a trap. "לק ג'ל" (Hebrew) machine-translates to "gel polish", which on
AliExpress surfaces floor lacquer as often as nail products. The fix was to resolve the shopping
intent to a canonical product query first, then translate that — not translate the raw phrase.
A small curated keyword map beat the general model for the high-traffic terms, because the model
kept inventing plausible-but-wrong category ids.

2. Only the first few words of a query survive

Long, descriptive queries rank worse than short ones on the marketplace API. The product noun has
to lead. "comfortable running shoes for wide feet women" performs far worse than "wide running
shoes". So the pipeline trims to the product noun + one or two qualifiers before it ever hits the
API.

3. Rank by orders, not price

The cheapest listing is almost never the best answer. Sorting candidates by real order volume,
then lightly penalising listings with no reviews, produced results people actually clicked. Price
is a filter, not a ranking signal.

4. Cache the translation, not the results

Product availability changes hourly, but the translation of "wireless earbuds" into a good query
does not. Caching the query resolution (and letting unknown terms cache their translation on
first use, so the second shopper gets an instant answer) cut latency dramatically without serving
stale stock.

5. Every market is different

The same query needs different handling per country: shipping thresholds, which categories pay,
even modesty defaults in some regions where the marketplace's own "relevance" surfaces things a
shopper did not ask for. Filtering the junk while never filtering a legitimate intent turned out
to be the hardest, most locale-specific part.

If you want to see the result, OneFindMe is live and free — type what you want in any of 12
languages and it does the translating, trimming, and ranking described above. Happy to answer
questions about any of these in the comments.

A Green API Is Not a Working Page

Ohad Farkash — Fri, 18 Sep 2026 11:48:19 +0000

I spent a morning connecting a session-recording tool to OneFindMe, the AliExpress product search engine I run in twelve languages, expecting to learn something about user behaviour. Instead it handed me a list of JavaScript errors, and every single one turned out to be a bug that had been in production for weeks while every check I had was green.

That is the part worth writing down. Not the bugs — bugs are ordinary. The fact that my entire measurement apparatus was structurally incapable of seeing them.

The one that cost the most

The error text was Unexpected identifier 's'. Twenty-eight occurrences.

The card that renders each product built its click payload like this:

const pJson = JSON.stringify({ id, title, price })
  .replace(/'/g, "&#39;")
  .replace(/"/g, "&quot;");

return `<a href="${url}" onclick="onProductClick('${pJson}')">…</a>`;

That escaping is correct — for an HTML attribute. It is wrong for a JavaScript string, and the attribute is both.

The HTML parser decodes ' back into a bare apostrophe before the browser compiles the attribute as JavaScript. So for a product titled Women's Vacation Dress, what the engine actually tries to compile is:

onProductClick('{"id":1,"title":"Women's Vacation Dress"}')

The string ends at Women'. Syntax error. The handler never compiles.

HTML entity escaping does not protect a JavaScript string literal in an inline handler. Entities are decoded first.

I proved it in the live page rather than reasoning about it, with a control:

const title = "Women's Vacation Dress";           // vs "Elegant Satin Dress"
host.innerHTML = `<a onclick="probeClick('${pJson}')">card</a>`;
document.getElementById('probeCard').click();
// apostrophe title  → handler did NOT run
// clean title       → handler ran

Then I counted how often it mattered: 9 of 24 products on one search, 14 of 42 on another. Roughly a third of every result page.

The damage is worth being precise about, because the obvious guess is wrong. The `` was untouched, so no sale was lost — shoppers still reached the retailer. What broke was everything the handler did: the favourite button and the share button silently did nothing on those products, and the click never reached my analytics.

Which means every click-through rate I had measured, for months, was an undercount — and I had been making product decisions on those numbers.

The fix is the one you already know: get the data out of the JavaScript entirely.

`js <a href="…" data-act="open" data-p="${pJson}">…</a> `

`js document.addEventListener("click", (e) => { const el = e.target.closest("[data-act][data-p]"); if (!el) return; dispatch(el.dataset.act, el.dataset.p); // parser treats it as text; nothing compiles }); `

The button that had not existed for months

Next error: Cannot read properties of null (reading 'classList').

`js function toggleDeals() { dealsActive = !dealsActive; const btn = document.querySelector(".deals-btn"); btn.classList.add("active"); // btn is null if (currentQuery) reSearch(); // never reached } `

.deals-btn did not exist anywhere on the page. It had been renamed at some point and this function never updated. It threw on line three, before the line that actually did the work — so the two visible buttons that called it were completely inert.

Then I opened the session recording attached to that error, and it stopped being an abstraction:

`js 01:02 clicked "Show all" 01:07 clicked "Show all" 01:27 clicked "Show all" 01:28 clicked "Show all" 01:28 clicked "Show all" `

Five clicks in 26 seconds, inside a seven-minute session where the same person also hit "load more" nine times. That is not a confused user. That is someone who wanted to buy something, pressing a button that did nothing, until they gave up.

A handler that throws leaves no trace on the server. No 500, no slow query, no error log. The only signature it leaves is a human being clicking the same thing over and over — and you can only see that if something is recording the page.

Three more, all invisible to the API

The product rows had no CSS at all. The page carried its own inline styles and had stopped loading the shared stylesheet; nobody noticed that the rules for one component never came with it. Cards rendered as full-width inline elements with uncapped images — one product per phone screen. The check that found it is one line:

`js [...document.styleSheets].some(s => [...s.cssRules].some(r => (r.selectorText || "").includes("product-card"))) // false `

Then the cards collapsed to one pixel. The message list is a column flexbox that overflows, and flex-shrink defaults to 1, so every child gets squeezed to make the container fit. The images were fully downloaded and completely invisible:

`js card.getBoundingClientRect().height // 1 card.querySelector('img').naturalWidth // 480 ← the image was fine all along `

flex-shrink: 0 took the card from 1px to 167px.

And loading="lazy" never fired inside that scroll container. Nine cards sat in the viewport with zero decoded images, while the exact same URL loaded instantly when fetched directly:

`js new Image().src = img.src; // loads, 480px img.complete // false, indefinitely `

Forcing eager on one loaded it immediately. Lazy loading is the wrong default for a handful of thumbnails the user explicitly asked to see; I removed it.

What I assert on now

The common thread is not carelessness. It is that my assertions were about the wrong layer. I was checking that the server returned the right JSON quickly, and it always did. The bugs all lived between the JSON and the pixels.

So after any change that reaches a screen, I now check the rendered DOM, not the response:

the order of nodes, not just their presence — reordering a streaming response once cut one sentence into three pieces across two product rows, and every timing measurement stayed perfect while it happened;
each element's measured box — getBoundingClientRect(), because "the element exists" and "the element is one pixel tall" are the same to a selector;
whether images actually decoded — img.complete && img.naturalWidth > 1, because a broken image and a lazy image are indistinguishable from src;
whether a CSS rule for the class exists at all, before debugging the layout it supposedly produces;
and all of it at a phone viewport, since that is where most of the traffic is.

Two of these bugs were years old. Both were found within five minutes of pointing something at the rendered page instead of the API — the same engine I described in an earlier piece about what broke when I put an LLM in front of product search, where the lesson was also that the interesting failures were in the seams rather than the model.

There is a broader version of this. Backend observability got very good — traces, structured logs, percentile latency — and it is all measuring the half of the system that was not broken here. The frontend half gets a synthetic Lighthouse run on a fast laptop and, if you are lucky, an error counter nobody reads.

The cheapest fix is not a new tool. It is to stop treating a green endpoint as evidence about a page, and to write one assertion that can only pass if the thing the customer sees is actually there.

The engine is OneFindMe — free, no signup. Every bug above came out of its production logs, and it is still finding new ways to break.

Can multilingual AI improve product search on international marketplaces?

Ohad Farkash — Wed, 16 Sep 2026 10:05:13 +0000

International marketplaces may support several languages, but their search engines often perform much better in English.

A shopper can describe exactly what they want in Spanish, French, or Arabic and still receive irrelevant results. Product titles are frequently machine-translated, overloaded with keywords, or written differently from the way real customers naturally describe products.

While developing OneFindMe, a multilingual AI product-search project for AliExpress, I noticed that translating the same query into English could significantly change the results.

This led me to explore a different approach: allowing shoppers to describe a product naturally in their own language—or upload an image—and using AI to interpret the intent before searching the marketplace.

I’m curious about the technical and user-experience side of this problem:

Should AI translate the query first, or search using semantic meaning across languages?
How should a search system handle badly translated or keyword-heavy product titles?
Would users prefer natural-language search, image search, or a combination of both?
Have you encountered similar problems while building multilingual search systems?

I’d appreciate feedback from developers who have worked with semantic search, embeddings, multilingual models, or marketplace APIs.

I Asked AI to Build a Shopping Basket Under a Hard Budget — Here's What Broke

Ohad Farkash — Fri, 28 Aug 2026 15:06:02 +0000

I run OneFindMe, an AI product-search front end for a
large marketplace. The last thing I shipped was a feature that sounds trivial and
isn't: type a need and a hard budget — "useful things for a big dog, 80 total" —
and get back a real basket of real products that never goes a cent over.

The word doing the work is real. The model is not allowed to invent a single
product, price, rating or shipping figure. Everything with a number attached comes
from the marketplace API. The model only gets to do the one thing it's actually
good at: understand what a human meant. Drawing that line is where all the
interesting failures lived.

Here's what broke.

What the AI is actually allowed to do

When someone types "useful things for a big dog, 80," the model does not return
products. It returns a plan:

{
  "domain": ["dog", "pet", "כלב"],
  "roles": [
    { "he": "Chew toy",  "kw": "dog chew toy" },
    { "he": "Leash",     "kw": "large dog leash" },
    { "he": "Brush",     "kw": "pet hair brush" },
    { "he": "Bowl",      "kw": "dog food bowl" }
  ]
}

That's it. A set of complementary roles that together serve the need, each with
a search keyword. No prices, no products, no ratings — the model never sees a
catalogue. Every role keyword then goes to the real search endpoint, in parallel,
and comes back with real listings: price, image, rating, order count, affiliate
link. The AI understood the intent; the marketplace supplied the facts.

This split is the whole design. The moment you let a language model emit a price
or a product name, you've built a very confident fiction generator. Keep it on the
intent side of the wall and it's genuinely useful.

The data that simply does not exist: shipping

The feature has a switch: does the budget include shipping? Honoring it turned
out to be impossible in the obvious way, because the affiliate API does not
return a shipping cost. It returns an item price and a delivery time in days —
never a freight figure. There is no endpoint that gives you "this item ships to
that country for X."

I could have had the model estimate shipping. That's exactly the invention I'd
banned. So the honest version:

"Include shipping" → filter the search to free-shipping items only. Now shipping is a verified zero, not a guess, and the budget math stays true.
"Products only" → ignore shipping entirely and say so.

Currency was a smaller version of the same lesson: the marketplace converts prices
server-side when you pass a target currency, so there is no live FX call to
reconcile per item — you just work in one currency the whole way through.
Coupons exist in the payload but change without notice, so they're surfaced as a
caveat, never subtracted from the total. If a number can't be trusted, it doesn't
get to move the budget.

Choosing items without going over: yes, it's Knapsack

Once each role has a pool of real candidates, picking a combination that maximizes
value without exceeding the budget is the 0/1 Knapsack
problem wearing a shopping hat.

I didn't reach for a full dynamic-programming solution, for three reasons: the
item count is small (a handful of roles, ~20 candidates each), the whole thing
runs inside a request budget of a few seconds, and there's a constraint textbook
knapsack doesn't have — diversity. Two chew toys is not a good dog basket even
if the numbers are optimal.

So it's a greedy build with a fill pass:

// 1. base: cheapest viable item per role, so every role is covered
for (const role of rolesByCheapest) {
  const pick = role.candidates.find(c => spend + c.price <= budget);
  if (pick) { basket.push(pick); spend += pick.price; }
}

// 2. fill: add new-role items (variety first), then upgrade to pricier/better
//    picks, until only a few units of budget remain
while (budget - spend > SLACK && basket.length < MAX) {
  const add = bestAffordableNewRole(spend);      // prefer an unused role
  const up  = bestUpgradeThatUsesBudget(spend);  // else spend up on a better item
  if (!apply(add, up)) break;
}

The base pass guarantees coverage. The fill pass is what makes the basket actually
feel like the budget you asked for — which brings me to the bug that embarrassed
me most.

The basket that spent 36 of a 200 budget

Early on, a "cosmetics basket, 200" came back at 36. Technically valid — every
item real, under budget, nothing invented. Practically useless. A customer asking
for a 200 basket and getting 36 worth of stuff feels short-changed, not thrifty.

The cause was the value function. "Quality first" scored items by rating and
sales, which has no opinion about using the budget. It happily picked one cheap,
well-rated item per role and stopped. The fix was two-part: scale the number of
roles with the budget (a 200 cosmetics basket wants 6–9 item types, not 3), and
add the fill loop above, which explicitly targets a near-full budget. Cosmetics at
200 now lands at ~199. Never over — that constraint is absolute — but close enough
that the number you typed is the number you get.

The bug that made it look like a scam

The one that actually scared me: a nail-polish basket returned a women's coat
for 80. Nothing about a coat belongs in a nail order.

Root cause was a relevance shortcut. Each role carried a "must contain" keyword to
filter noise, and the role top coat had contributed coat. A listing titled
"Women Suede Coat" matched coat and sailed through. A generic word from one role
had opened the door to a completely different category.

The fix was to stop filtering per role and filter per basket. The planner now
returns a domain — a few need-specific stems, in every language the title might
be in — and every item, whatever its role, must contain one of them:

const domain = ["nail", "polish", "manicure", "ציפורנ"]; // for "nail polish"
const relevant = p =>
  domain.some(stem => (p.title + " " + p.titleLocal).toLowerCase().includes(stem));

A coat contains none of nail / polish / manicure, so it's gone — regardless of
which role's keyword it happened to match. Precision beat recall here on purpose:
in a basket, one off-topic item reads as "this thing is broken," and I'd rather
drop a borderline product than ship the coat.

Speed beat correctness. Again.

The first working version took 10–16 seconds cold: one planning call to the model,
then N marketplace searches. Users don't wait 15 seconds for a basket; they leave.

Two things fixed it. The searches were already cached, so the second time anyone
builds a similar basket the role searches are warm. And the plan — the roles for
a given need and budget band — is cacheable too, and priority-independent, so I
cache it and skip the model entirely on a repeat. A brand-new query is still
~10s (N cold marketplace round-trips are the floor), but a repeat is 0.4s. As
the cache warms across users, more baskets land in the fast path. Same lesson I
keep relearning: a correct answer that arrives too late is a wrong answer.

What happens when a price changes after you build the basket

It will. Prices and stock on a live marketplace move by the hour. The basket you
show is a snapshot, and pretending otherwise is the same sin as inventing a
shipping figure. So the total is computed server-side from the freshest search at
build time, the items carry the marketplace's own "prices may change" caveat, and
the buy links go straight to the live listing where the real, current price is
authoritative. The basket is a starting point that respects your budget, not a
locked quote — and it says so.

The pattern underneath all of it

Every one of these fixes is the same move: let the model interpret, never let it
assert. It's brilliant at turning "stuff for a big dog, 80" into search terms and
domain anchors. It's a liability the instant it emits a price. Keep the language
work and the truth work on opposite sides of a hard wall, and the failures stop
being "the AI hallucinated" and start being ordinary, fixable engineering — a
missing field, a too-greedy heuristic, a generic keyword that matched the wrong
thing.

The budget basket that came out of it is live on OneFindMe if you want to see the
shape of it. But the interesting part was never the demo. It was the wall.

Localizing a marketplace search for 12 markets: the assumptions that cost me

Ohad Farkash — Tue, 25 Aug 2026 10:19:24 +0000

I run OneFindMe, an AI product-search front end for
AliExpress in 12 languages. Translating the UI was the easy part. The hard part
was everything I assumed about what each market wants — and kept getting wrong
until I measured instead.

This is three of those assumptions, what the data actually said, and the code
that changed. If you're localizing anything commerce-shaped past the string
table, you'll recognize the pattern: the bug is never the translation, it's the
belief underneath it.

Assumption 1: "same homepage, translated, is localized"

The first version showed every market the same "today's deals" row — the same
eight products, just translated. A shopper in Saudi Arabia and a shopper in
Brazil saw identical items in different words.

That isn't localization, it's translation wearing a localization costume. The
Gulf shopper doesn't want the same products as the Brazilian one; they want
things that sell there — an abaya, an oud diffuser, an Arabic coffee pot.
Showing them a translated version of someone else's shortlist is worse than
showing nothing, because it signals the site doesn't actually know their market.

The fix was per-market seed lists, chosen by audience before geography. A
single dispatch, checked in this order:

function dealsTerms() {
  if (lang === "ar" || ARAB_COUNTRIES.has(country)) return DEALS_GULF;
  if (country === "IL") return DEALS_IL;
  if (EU_COUNTRIES.has(country)) return DEALS_EU;
  return DEALS_INTL;
}

Language is checked before country on purpose: an Arabic speaker who happens
to be browsing from Germany should still get the Gulf row, not the EU one. The
person's language is a stronger signal of what they're shopping for than the IP
they happen to be behind.

Lesson: a translated shortlist is not a localized shortlist. Localize the
selection, not just the labels — and let the audience signal win over the geo
signal when they disagree.

Assumption 2: I knew what a market considered acceptable

Here's the one I'm least proud of, and the most useful.

A women's-clothing search on the Arabic surface returned some items I looked at
and thought: I should filter these out for a conservative market. I started
writing a modesty filter — block anything that looked immodest on the Arabic
side. It felt responsible.

Then I did the thing I should have done first: I opened the actual AliExpress
Saudi storefront, as a Saudi user, and ran the same query. AliExpress itself
puts "sexy"-labelled and form-fitting clothing on the first page of a plain
dress search there. Immodest clothing is the market norm, not an edge case.

My filter would have made my engine stricter than the store the shopper was
walking into anyway — blocking a sports bra from someone who searched for
women's clothing, while the destination site shows it on page one. That's not
protecting anyone; it's just lost results.

So I threw the modesty filter away. What I kept was much narrower: a filter for
things that were a relevance failure in any market — a fetish costume
surfacing on a search for "dress" is wrong for a shopper in Riyadh and one in
Tel Aviv. That list is short and explicit, and deliberately excludes words with
innocent uses (a "nightclub dress" is an ordinary party dress; "Lolita" is a
real fully-covering fashion style; "sexy" is 42% of AliExpress's own first
page).

Lesson: don't encode your assumption about a market into a filter. Go
observe the market — the real benchmark for what to show is the store the user
is heading to. I almost shipped a paternalistic filter built on a guess; four
minutes of looking inverted the whole decision.

Assumption 3: more traffic in a language means demand in that language

I'd built full localized pages for three Gulf markets, confident all three had
Arabic shopping demand. Then I pulled the search-console data per country, and
two of the three had almost no Arabic queries at all — the "traffic" was
my own users mis-geolocated through carrier routing and VPNs, searching in other
languages entirely.

I'd spent weeks building for demand that a five-minute export would have shown
me wasn't there. Worse: content I'd written as filler in one language quietly
out-performed the pages I'd carefully localized, because that's where the real
demand was.

Lesson: "traffic from country X" and "demand in language X" are different
measurements, and you can't tell them apart without looking at the actual
queries. Export the per-market data before you build the per-market page, not
after.

The pattern under all three

Every one of these was the same shape: a reasonable-sounding assumption about a
market I wasn't in, encoded into code, that a small measurement would have
corrected before I wrote a line. Translating strings is a solved problem.
Localizing judgment — what to show, what to filter, what to build — is where
the real work is, and it's all measurement, not intuition.

Localize the selection, not just the strings. A translated shortlist isn't local.
Let the audience signal beat the geo signal when they conflict.
Observe the market before you filter it. The benchmark is the store the user is going to, not your idea of that market.
Per-market demand data before per-market pages. Traffic ≠ demand.

If you're building commerce in markets you don't personally live in, the
uncomfortable truth is that your instincts about those markets are a liability
until they're checked. Mine were wrong three times in a row. Curious whether
anyone's found a faster way to catch these than shipping and measuring — the
comments are open.

I build OneFindMe — AI product search for
AliExpress by text or image, in 12 languages. It's free; it runs on affiliate
commission at no extra cost to the buyer.

Building a 12-language AI product search on the edge: what actually broke

Ohad Farkash — Tue, 25 Aug 2026 10:10:26 +0000

I run OneFindMe, an AI product-search front end for
AliExpress. You describe what you want in plain language — in any of 12 languages
— or upload a photo, and it returns the product, similar items, and cheaper
alternatives. It runs entirely on a Cloudflare Worker with an LLM doing the
language work.

This isn't a launch post. It's the three problems that were genuinely hard, the
wrong first solutions I shipped, and what actually fixed them. If you're putting
an LLM in front of a marketplace search API, you'll hit all three.

The stack, briefly

Cloudflare Workers for the whole API — search, translation, image understanding, caching.
Claude Haiku for query translation and image identification. I tried Sonnet too, but for this task — short product names and image labels — Haiku was actually the better fit, and it's far cheaper when every search is an LLM call.
Workers KV as the cache layer.
A static multilingual front end on Cloudflare Pages.

The core loop is: take a natural-language query in any language → turn it into a
clean marketplace search term → hit the affiliate search API → rank and filter →
return. The interesting failures are all in the "turn it into a clean search
term" step.

Problem 1: the model translated too well

The first version asked the model to "translate this shopping query to English."
It did — beautifully, fluently, and uselessly.

A user searching for a שמלת ערב (evening dress) got back
an elegant formal gown suitable for evening occasions. Grammatically perfect.
It also returned almost nothing from the marketplace, because nobody titles a
product listing in fluent prose. Marketplace sellers write
Women Elegant Evening Party Dress Sexy Backless — keyword soup, not sentences.

The fix was to stop asking for translation and start asking for the 2-3 word
noun phrase a seller would put in a title. The prompt changed from "translate"
to "return the short product name an AliExpress seller would use." Fluency was
the enemy; the model's instinct to produce natural language was exactly wrong for
a keyword search index.

Lesson: when an LLM feeds a keyword system, you don't want its best language.
You want the language of the target index. Prompt for that explicitly.

Problem 2: the model invented category IDs, and they outranked reality

To narrow results, I let the model suggest an AliExpress category ID alongside
the keywords. Category-constrained search returns cleaner results — when the ID
is real.

The model would confidently return category IDs that did not exist. Not
often, but often enough. And a nonexistent category ID doesn't error — it returns
an empty or garbage result set, which then replaced the perfectly good
keyword-only results the same query would have produced. The hallucinated
constraint silently beat the honest fallback.

Two things fixed it. First, a hard allow-list: category IDs the model proposes
are checked against a map of known-good IDs and dropped if unrecognised. Second,
and more important, the keyword search always runs; the category is an
optional refinement layered on top, never a replacement. If the category path
returns nothing, the keyword results are still there.

Lesson: never let a model's optional enrichment silently override your
deterministic baseline. Layer it, gate it, and make the baseline win by default.

Problem 3: cold search was 6-8 seconds, and that was the whole business

An uncached search does real work: an LLM call to build the query, the
marketplace API round trip, ranking, filtering. Cold, that's 6-8 seconds. Users
don't wait 6-8 seconds. The single biggest driver of bounce wasn't relevance —
it was latency on the first search.

The cache helps enormously: every search result is cached in KV for up to 30
days, so a warm search returns in ~200 ms. But you can't cache a query nobody has
run yet, and the first person to search a term pays the full cost.

Two moves cut the perceived wait to near zero without making the search
actually faster:

Instant bestsellers. The moment a search starts, the UI shows a row of known-good bestseller results for the category while the real search runs behind it. The screen is never empty; the real results swap in when ready.
Self-warming on unknown terms. When a new keyword is translated for the first time, the translation is saved and the search is pre-cached, so the next person to search that term — and there's almost always a next person — gets the 200 ms warm path.

Neither makes the cold path faster. Both make it invisible. That distinction —
optimising perceived latency instead of actual latency — moved the metric that
mattered more than any relevance tuning did.

Lesson: on a search product, the empty-state-while-loading is a feature, not
a gap. Show something instantly and backfill.

The one I'd warn you about hardest

A subtle one, because it looks like success: don't trust the marketplace's own
"is this product available" signal in isolation. The affiliate API would report
live, purchasable products as gone. Filtering on it alone silently emptied result
pages that should have been full. Availability needs corroboration, not a single
boolean — the same lesson as the hallucinated category, in a different costume:
one unreliable signal shouldn't be allowed to zero out a good result set.

What I'd tell myself at the start

Prompt for the target system's language, not the user's. A keyword index wants keywords, not prose.
A model's optional output must never override your deterministic path. Gate it against known-good values; layer it; let the baseline win.
Optimise perceived latency first. Instant partial results beat a faster spinner every time.
One signal should never zero out a result set. Corroborate before you filter to empty.

The engine runs in 12 languages now, and every one of those bugs showed up
identically in each. If you're building anything that puts an LLM between a human
sentence and a structured search index, you'll meet all four. Happy to compare
notes in the comments — especially if you've found a better answer to the
cold-search problem than "show bestsellers and pray."

I build OneFindMe — AI product search for
AliExpress by text or image, in 12 languages. It's free; it runs on affiliate
commission at no extra cost to the buyer.