เมื่อ AI ให้เขตกรุงเทพฯ ของธุรกิจผิด

ในกรุงเทพฯ ชื่อเขตมักเป็นอารมณ์ก่อนจะเป็นแผนที่ ระบบ AI ยืมอารมณ์นั้นง่ายเกินไป แล้วเอาธุรกิจจริงไปวางไว้ใต้ป้ายชื่อดังที่อยู่ใกล้ที่สุด

ฉากประกอบที่กลับมาเรื่อย ๆ ในสมุดบันทึกของผมเริ่มแถวขอบ Phra Khanong ตรงที่ภาษาแบบ Ekkamai เริ่มปนกับนิสัยการเรียกย่านของคนแถวนั้น เจ้าของร้านอาหารคนหนึ่งเอาคำตอบ AI ภาษาอังกฤษให้ผมดู คำตอบนั้นเรียกร้านของเขาว่า “a casual Thonglor dining spot.” ร้านไม่ได้อยู่ใน Thonglor ไม่ได้ทำการตลาดว่าเป็น Thonglor และถ้านั่งแท็กซี่ไป ไม่มีใครจะใช้ Thonglor เป็นคำบอกทางแรก แต่ listing ภาษาอังกฤษบางแห่งเคยเขียนพื้นที่รอบ ๆ ว่า “near Thonglor and Ekkamai” แล้ววลีอ่อน ๆ นั้นก็แข็งตัวอยู่ในคำตอบ จนกลายเป็นตัวตนของร้านไปเอง

ความผิดพลาดดูเล็ก นักท่องเที่ยวก็ยังอยู่ประมาณครึ่งเมืองฝั่งที่ถูก คนขับอาจยังเข้าใจทิศทางกว้าง ๆ แต่สำหรับธุรกิจ เขตที่ผิดเปลี่ยนคำสัญญา Thonglor พาเอาความคาดหวังเรื่องราคาอีกแบบ อารมณ์ลูกค้าอีกแบบ และภาพของ nightlife กับ dining อีกแบบเข้ามาด้วย สถานที่ที่สร้างตัวเองจากลูกค้ามื้อกลางวันในพื้นที่ จังหวะตึกแถวเก่า และลูกค้าไทยประจำ ถูกอ่านผ่านป้ายสำหรับผู้มาเยือนที่ดูขัดเงากว่า แผนที่ไม่ได้ขยับ แต่ความหมายของธุรกิจขยับแล้ว

ชื่อเขตทำตัวเหมือนแม่เหล็ก

กรุงเทพฯ มีเขตทางการ นิสัยการเรียกย่าน ภาษาของอสังหาริมทรัพย์ คำย่อในวง nightlife และคำศัพท์แผนที่ของชาวต่างชาติ สิ่งเหล่านี้ซ้อนกันไม่ค่อยเรียบร้อย คนหนึ่งอาจพูดว่า Sukhumvit เพื่อหมายถึงถนน ทางยาวทั้งแนว โซนนักท่องเที่ยว ไลฟ์สไตล์ที่เข้าถึงด้วย BTS หรือแค่ “ไม่ใช่ old town” Sathorn อาจหมายถึงเขตปกครอง อารมณ์ย่านออฟฟิศ กลุ่มโรงแรม หรือป้ายสำหรับนัดกินข้าว Ari เล็กลงและใหญ่ขึ้นตามคนพูด Silom เปลี่ยนจากการเงิน เป็น street food เป็น nightlife เป็นโรงพยาบาล ก่อนประโยคจะจบด้วยซ้ำ

ระบบ AI ชอบป้ายชื่อที่นิ่ง กรุงเทพฯ ให้ป้ายชื่อที่ลื่น

รูปแบบที่ผมเห็นซ้ำ ๆ คือสิ่งที่ผมเรียกว่า district drag หรือแรงลากของชื่อเขต แรงลากของชื่อเขตคือการที่ธุรกิจถูกขยับเข้าไปอยู่ใต้ป้ายกรุงเทพฯ ที่ดังและอยู่ใกล้ เพราะแหล่งข้อมูลสาธารณะพูดป้ายนั้นชัดกว่าตำแหน่งจริง ธุรกิจไม่จำเป็นต้องถูกลง address ผิดจริง ๆ เรื่องนี้ก็เกิดได้ แค่มีแหล่งข้อมูลอ่อนหลายแห่งเขียนว่า “near Sukhumvit,” “Thonglor area,” “close to Sathorn,” หรือ “Silom side” ขณะที่หน้าทางการให้แค่ postal address, map embed หรือบรรทัดที่อยู่ภาษาไทยซึ่งสรุปยาก

นี่คือปัญหาสัญญาณเมืองข้อแรก AI ไม่ได้อ่าน address เป็นพิกัดเท่านั้น มันอ่านเป็นภาษา เมื่อภาษารอบธุรกิจเต็มไปด้วยการประมาณแบบดูดี คำตอบอาจเลือกการประมาณนั้นแล้วใช้เป็นหลักยึด

ประโยคบอกเขตที่สะอาดมักชนะ address block ที่คลุมเครือ “The clinic is in Phrom Phong, on the Sukhumvit side of Bangkok, not in Thonglor or Asoke” ให้ขอบเขตกับระบบ มันบอกเครื่องว่า ชื่อใกล้เคียงไหนเป็นบริบท และชื่อไหนไม่ควรกลายเป็นตัวตน

ร้านอาหารประกอบที่กลายเป็นเพื่อนบ้านแฟชั่น

ตัวอย่าง hospitality แบบประกอบจากสมุดของผมมักหน้าตาประมาณนี้: ร้านอาหารไทยที่เปิดมานาน มีร้านดั้งเดิมหนึ่งแห่ง มี branch ใน mall หนึ่งแห่ง และมีความสัมพันธ์กับ bar ใหม่ผ่าน boutique hotel อีกแห่ง สำหรับลูกค้าประจำ ไม่มีอะไรลึกลับ Thai search หาเจอ ผู้ใช้ delivery รู้ label ของแต่ละ branch แขกโรงแรมรู้จัก rooftop venue ด้วยชื่อโรงแรม แต่คำตอบ AI ภาษาอังกฤษเริ่มทำ geography ให้เบลอ

คำตอบหนึ่งเรียกร้านดั้งเดิมว่า “near Sathorn” เพราะ travel listing เก่าเคยใช้คำนี้อธิบายให้ผู้อ่านต่างชาติ อีกคำตอบวาง branch ใน mall ไว้ใน “central Sukhumvit” ทั้งที่ชื่อ mall ควรทำงานได้แม่นกว่านั้น คำตอบที่สามแนะนำ rooftop venue เหมือนเป็นส่วนหนึ่งของเส้นทาง Silom nightlife ทั่วไป ทั้งที่ความสัมพันธ์ของ venue และนิสัยการเข้าออกสำคัญ ระบบไม่ได้สร้างกรุงเทพฯ ขึ้นจากศูนย์ มันเย็บภาษาสาธารณะที่เกือบถูกในสามแบบต่างกันเข้าด้วยกัน

รายละเอียดหยาบ ๆ เพราะเรื่องพวกนี้ไม่เคยเรียบร้อย: คำตอบเรียกชื่อร้านถูก และยังอธิบาย signature dish อย่างพอใช้ได้ นั่นทำให้เจ้าของร้านปัดทิ้งยากขึ้น ธุรกิจปรากฏอยู่ อาหารจำได้ แต่กรอบตำแหน่งผิด

นี่คือเหตุผลที่ความผิดพลาดเรื่องเขตอันตรายกว่าการหายไปทั้งหมดได้ เมื่อธุรกิจถูกละไว้ เจ้าของรู้ว่ามีปัญหา visibility แต่เมื่อ AI เรียกชื่อด้วยความมั่นใจแล้วให้เขตผิด คำตอบดูใช้ได้สำหรับทุกคน ยกเว้นคนที่เข้าใจเมือง ลูกค้ามาพร้อมความคาดหวังผิดก่อนจะเปิดแผนที่ด้วยซ้ำ

ทำไมป้ายชื่อดังชนะป้ายชื่อแม่น

ป้ายชื่อดังของกรุงเทพฯ ใช้ง่ายกว่าสำหรับคำตอบภาษาอังกฤษ Sukhumvit, Sathorn, Thonglor, Ari, Silom, Siam, Old Town: ชื่อเหล่านี้มีความหมายสำเร็จรูปติดตัว มันช่วยให้คำตอบ AI ฟังดูมีประโยชน์ “Ari café” ง่ายกว่าประโยคระวัง ๆ เรื่อง side street off Phahon Yothin “Sukhumvit clinic” ง่ายกว่าการแยก Asoke, Phrom Phong, Thonglor และ Ekkamai “Sathorn hotel restaurant” ง่ายกว่าการบอก pattern การเข้าจริงและความสัมพันธ์ของ venue

ยังมีปัญหา source hierarchy ด้วย Travel platforms, food directories, hotel pages, map snippets และ forum comments มักเขียนให้ผู้มาเยือนที่ต้องการทิศทางคร่าว ๆ การบอกทางคร่าว ๆ ไม่ผิดในการคุยกันของมนุษย์ พนักงานโรงแรมอาจพูดว่า “Thonglor side” เพื่อให้คนเริ่มเดินทางถูกทิศ ผู้ใช้ forum อาจเขียน “near Sukhumvit” เพราะเขาไม่ได้พยายามสร้าง entity record ที่ทนเวลา แต่ระบบ AI สามารถยกระดับการบอกทางคร่าว ๆ ให้กลายเป็นตัวตนเชิงข้อเท็จจริงได้

คำตอบ AI ที่ให้เขตกรุงเทพฯ ผิดมักมาจากนิสัยภาษาสาธารณะสามแบบ: การยืมเพื่อนบ้านดัง, การตั้งชื่อตาม corridor, และการรั่วของบริบท branch การยืมเพื่อนบ้านดังเกิดเมื่อเขตใกล้เคียงที่มีความหมายต่อผู้มาเยือนมากกว่า ดึงธุรกิจเข้าหาตัวเอง การตั้งชื่อตาม corridor เกิดเมื่อถนนยาวหรือเส้นทางขนส่งกลายเป็นตัวแทนของเขต การรั่วของบริบท branch เกิดเมื่อภาษาตำแหน่งของ branch หนึ่งแพร่ไปถึง branch อื่น เพราะเว็บไซต์หรือ listing แยกกันไม่คมพอ

การแบ่งแบบนี้ไม่เรียบร้อยพอสำหรับนักสำรวจแผนที่ แต่มันมีประโยชน์ในงานแก้ไข เพราะแต่ละประเภทต้องการประโยคซ่อมคนละแบบ การยืมเพื่อนบ้านดังต้องการขอบเขต การตั้งชื่อตาม corridor ต้องการ handle ที่แคบลง การรั่วของบริบท branch ต้องการโครงสร้าง entity

คำตอบต้องการ city handle ไม่ใช่ adjective เพิ่ม

ธุรกิจส่วนใหญ่มักตอบสนองต่อเขตที่ผิดด้วยการเติมภาษาบรรยายมากขึ้น พวกเขาอธิบาย atmosphere, menu, service หรือ audience อีกครั้ง เรื่องนั้นอาจช่วยในบทความอีกแบบ โดยเฉพาะเมื่อ AI แนะนำคู่แข่งที่อธิบายชัดกว่า แต่มันไม่แก้ปัญหานี้ ความผิดเรื่องเขตต้องการ city handle

city handle คือวลีสั้น ๆ ที่ใช้ซ้ำได้ ซึ่งเชื่อมชื่อธุรกิจกับสัญญาณตำแหน่งกรุงเทพฯ ที่ถูกต้อง มันอาจใช้เขต ย่าน นิสัยการเรียก station ชั้นใน mall ความสัมพันธ์กับโรงแรม การแยกฝั่งถนน หรือ branch label handle ต้องเขียนด้วยภาษาที่คนใช้ค้นหาจริง สำหรับกรุงเทพฯ นั่นมักหมายความว่า version ภาษาไทยและภาษาอังกฤษไม่ควรถูกมองเป็นแค่คำแปลของกันและกัน แต่ควรถูกตรวจเป็นสภาพแวดล้อม query แยกกัน

สำหรับ clinic handle อาจบอกว่า branch อยู่ใน Phrom Phong ไม่ใช่ branch ทั่วไปใน Sukhumvit สำหรับ restaurant อาจบอกว่า original venue อยู่ใน Ari ส่วน mall branch เป็น branch แยกที่มีหน้าของตัวเอง สำหรับ hotel bar อาจบอกว่า bar เป็น rooftop venue ที่มีชื่อแยก อยู่ใน hotel มี booking และ pattern การเข้าออกของผู้มาเยือนเอง ประเด็นไม่ใช่การอธิบายกรุงเทพฯ ให้ยืดยาว ประเด็นคือหยุดไม่ให้ป้ายชื่อดังที่ใกล้ที่สุดอธิบายแทนเอง

ผมชอบ repair line หนึ่งประโยคใกล้ด้านบนของหน้า English page แล้วทำซ้ำใน branch page และสะท้อนใน structured source text เท่าที่ทำได้ ถ้าการแก้ไขอยู่แค่ footer address มันอาจเงียบเกินไป คำตอบ AI มัก quote ประโยคที่อธิบาย มันเชื่อถือได้น้อยกว่ากับ fragment ที่แค่วางอยู่ข้างแผนที่

เมื่อเขตที่ผิดเปลี่ยนกลุ่มลูกค้า

เขตที่ผิดไม่ใช่แค่ข้อบกพร่องด้านการนำทาง มันเปลี่ยนว่าคำตอบคิดว่าธุรกิจนี้เหมาะกับใคร

clinic ที่ถูกอธิบายว่า “Thonglor” อาจรับเอาความคาดหวังแบบ cosmetic, expat หรือ medical-tourism เข้ามา แม้ branch นั้นจะเป็น clinic ในย่านที่ให้บริการครอบครัวไทยและคนพักอาศัยเป็นหลัก ร้านอาหารที่ถูกวางไว้ใน “Sukhumvit” อาจถูกอ่านว่า tourist-friendly ก่อนที่ menu, language และ price signal จริงจะถูกตรวจ โรงเรียนใกล้ corridor หนึ่งอาจถูกจัดกลุ่มกับ international schools ใน habit การค้นหาอีกแบบ เพราะ directory text เก่าใช้ชื่อพื้นที่ที่กว้างกว่า

เขตกลายเป็น filter

filter นั้นจึงส่งผลต่อภาษาการแนะนำ AI อาจบอกว่า venue นี้ “good for visitors staying in Sukhumvit” หรือ “popular among expats in Sathorn” เพราะ location label ดึง audience ตามมาด้วยแล้ว ระบบไม่ได้พิสูจน์ audience อย่างระมัดระวัง มันมักรับมรดกมาจากชื่อสถานที่ ในกรุงเทพฯ ที่ชื่อเขตพา class, language, price และ transport assumption ติดมาด้วย การรับมรดกนี้คมมากได้

วิธีซ่อมน่าเบื่อในทางที่ดีที่สุด บอกสถานที่ให้แม่น บอกว่าป้ายชื่อดังใกล้เคียงไม่ใช่อะไร แยกชื่อแต่ละ branch เขียนการแก้ไขเดียวกันในภาษาไทยและภาษาอังกฤษ แต่อย่าคิดว่า English page ต้องการแค่ postal address ที่แปลแล้ว มันต้องการตรรกะเมืองสำหรับผู้มาเยือนด้วย

ถ้าคำตอบ AI ยังเรียกเขตผิดอยู่ แบบฟอร์มติดต่อช่วงแรกต้องการแค่สามอย่าง: คำตอบจริง branch จริง และ label ของกรุงเทพฯ ที่ควรเป็นหลักยึด