Articles

上一篇文章中，我们构建了由 FastAPI 后端驱动的流式 AI 聊天机器人。这一模式可覆盖大多数企业场景。但对于某些需求——满足《个人信息保护法（PIPL）》《数据安全法》和等保2.0（尤其是工控/OT 系统场景）的数据不出境要求、离线运行能力、高并发下的成本控制——在设备上直接运行模型才是正确答案。

前回の記事では、FastAPIバックエンドを用いたストリーミングAIチャットボットを構築しました。このパターンはエンタープライズユースケースの大半をカバーします。しかし、個人情報保護法（APPI）・J-SOX監査証跡・経済安全保障推進法に対応した完全なデータローカライゼーション要件、オフライン動作、大量メッセージでのコスト管理など、特定の要件に対しては、デバイス上で直接モデルを実行することが正解となります。

ในบทความก่อนหน้า เราสร้าง AI chatbot ที่ใช้ FastAPI backend รูปแบบนั้นครอบคลุม enterprise use case ส่วนใหญ่ได้ดี แต่สำหรับความต้องการบางประเภท — การประมวลผลข้อมูลส่วนบุคคลโดยไม่ส่งออกนอกอุปกรณ์ตาม PDPA และ พ.ร.บ. ความมั่นคงปลอดภัยไซเบอร์ การทำงานแบบ offline และการควบคุมต้นทุนที่ปริมาณสูง — คำตอบที่ถูกต้องคือรัน model โดยตรงบนอุปกรณ์

In the previous post in this series, we built a streaming AI chatbot backed by a FastAPI server. That covers the majority of enterprise use cases. But for a growing set of requirements — strict data residency, offline functionality, zero per-token cost at scale — the right answer is to run the model directly on […]

大多数 React Native 教程止步于 UI 层——展示如何渲染聊天气泡，然后用一句含糊的"直接从应用调用 OpenAI API"带过后端部分。

React Nativeのチュートリアルの多くはUI層で止まります。チャットバブルの描画やキーボード制御は丁寧に説明しながら、バックエンドについては「OpenAI APIをアプリから直接呼ぶ」とだけ説明して終わりにしてしまいます。

บทความ React Native ส่วนใหญ่หยุดแค่ UI layer — แสดงวิธีทำ chat bubble แต่ข้ามเรื่อง backend ด้วยคำแนะนำคลุมเครือว่า "เรียก OpenAI API จากแอปโดยตรง"

Most React Native tutorials stop at the UI layer. They show you how to render chat bubbles and handle keyboard offsets—then hand-wave the backend with a vague "call the OpenAI API from your app."

在构建RAG管道或需要语义搜索的应用时，首先需要决定的是将Embedding存储在哪里。Pinecone、Qdrant、Weaviate等专用向量数据库是一种选择，但对于已经运行PostgreSQL的团队而言，pgvector是更快、更经济、运维更简单的方案。

RAGパイプラインやセマンティック検索が必要なアプリケーションを構築する際、最初に決める必要があるのは「Embeddingをどこに保存するか」です。PineconeやQdrant、Weaviateといった専用ベクトルデータベースも選択肢の一つですが、すでにPostgreSQLを運用しているチームにとって、pgvectorはより速く、安価で、運用が簡単な方法です。

ถ้าคุณกำลังสร้างระบบ RAG หรือแอปพลิเคชันที่ต้องการ Semantic Search คำถามแรกที่ต้องตัดสินใจคือจะเก็บ Embedding ไว้ที่ไหน Vector Database เฉพาะทางอย่าง Pinecone, Qdrant หรือ Weaviate เป็นตัวเลือกหนึ่ง แต่สำหรับทีมที่ใช้ PostgreSQL อยู่แล้ว pgvector คือทางเลือกที่เร็วกว่า ถูกกว่า และดูแลง่ายกว่า pgvector คือ Extension แบบ Open Source สำหรับ PostgreSQL ที่เพิ่ม Type ข้อมูล vector พร้อม Similarity Search Operator และ Index แบบ HNSW/IVFFlat เข้าไปใน Database ที่มีอยู่เดิม Embedding ของคุณอยู่ใน Database เดียวกับข้อมูลแอปพลิเคชัน Query ด้วย SQL มาตรฐาน รองรับ […]

If you’re building a RAG pipeline or any application that needs semantic search, you’ll eventually need to decide where to store your embeddings. Dedicated vector databases (Pinecone, Qdrant, Weaviate) are one option. But for most teams — especially those already running PostgreSQL — pgvector is the faster, cheaper, and operationally simpler path.

大多数企业不会意识到自身存在身份管理问题——直到安全事故发生之后。 离职员工的账户仍在三个系统中保持活跃，因为没有人更新离职操作清单。某外包人员能够访问财务门户，因为六个月前申请了"临时"访问权限，工单从未关闭。一次网络钓鱼攻击得逞——不是因为安全防护薄弱，而是因为团队在管理24套独立的登录系统，没有人注意到其中一个根本没有启用MFA。

ほとんどの企業は、セキュリティ侵害が起きるまで自社のアイデンティティ問題に気づきません。

บริษัทส่วนใหญ่ไม่รู้ว่าตัวเองมีปัญหาด้านการจัดการตัวตนดิจิทัล — จนกว่าจะเกิดเหตุ บัญชีพนักงานที่ลาออกยังค้างอยู่ในสามระบบ เพราะไม่มีใครอัปเดต Checklist การปิดบัญชี ผู้รับเหมาได้สิทธิ์เข้าถึง Portal ฝ่ายการเงิน เพราะต้องการสิทธิ์ "ชั่วคราว" เมื่อหกเดือนก่อนและไม่มีใครปิดใบงาน การโจมตี Phishing สำเร็จ — ไม่ใช่เพราะระบบรักษาความปลอดภัยบกพร่อง แต่เพราะทีมไอทีต้องดูแลระบบล็อกอิน 24 ระบบแยกกัน และไม่มีใครสังเกตว่าระบบหนึ่งไม่มี MFA

Most companies don’t discover their identity problem until after the breach. A departing employee’s account stays active in three systems because nobody updated the offboarding checklist. A contractor gets access to the finance portal because they needed "temporary" access six months ago and the ticket was never closed. A phishing attack succeeds not because your […]

大多数工程团队都有同一个心照不宣的漏洞：身份管理是所有人的问题，却是没有人负责的问题。以下是CTO和工程管理者如何解决这一问题，以及他们从中获得了什么。

多くのエンジニアリング組織が同じ無言の脆弱性を抱えています。アイデンティティはすべての人の問題でありながら、誰の責任でもない状態です。CTOやエンジニアリングマネージャーがこの問題をどう解決しているか、そして何を得ているかをご説明します。

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

Most engineering organisations share the same unspoken vulnerability: identity is everyone’s problem and no one’s responsibility. Here is how CTOs and engineering managers are fixing it — and what they gain in the process.