Langfuse эсвэл LangSmith: self-host эрх үү, бэлэн eval урсгал уу

Trace өгөгдлөө өөрийн дэд бүтцэд хадгалах шаардлагатай бол Langfuse, LangChain эсвэл LangGraph агентын үнэлгээг бэлэн урсгалаар хийх бол LangSmith илүү тохирно гэж DataCamp-ийн харьцуулалт дүгнэжээ. LangSmith нь өөр framework-д ч ажилладаг, мөн Enterprise нөхцөлөөр өөрөө байршуулж болдог тул ялгаа нь боломж байгаа эсэхээс илүү түүнийг ашиглах нөхцөлд оршино.

Хоёр бүтээгдэхүүн tracing, evaluation, prompt management-ийг хамардаг. Сонголт хийхэд нэг агентын алдаатай хариуг trace-ээс оношлоод, дараагийн өөрчлөлтөд давтан шалгах тохиолдол болгож чадах эсэхийг харах хэрэгтэй. Тэр урсгалд өгөгдөл хаана хадгалагдах, үнэлгээг хэн тохируулах, дэд бүтцийг хэн ажиллуулах нь бүтээгдэхүүний боломжтой адил чухал.

Нэг tool call-ийн алдааг trace-ээс олох нь

Нөхцөлт жишээ авъя: хүргэлтийн төлөв асуусан хэрэглэгчид агент захиалга хайх tool дуудаад өөр захиалгын төлөвөөр хариулжээ. Эцсийн өгүүлбэр буруу гэдгийг мэдэхээс гадна хэрэглэгчийн асуулт, tool-д дамжуулсан захиалгын таних утга, tool-ийн буцаасан үр дүн, түүнийг ашигласан model call-ыг нэг гүйцэтгэлд холбож харах шаардлагатай. Ингэснээр агент буруу захиалга сонгосон уу, tool буруу өгөгдөл буцаасан уу, эсвэл зөв өгөгдлийг загвар буруу тайлбарласан уу гэдгийг ялгана.

Langfuse-ийн tracing заавар OpenTelemetry болон SDK ашиглан үндсэн хүсэлт доторх model call зэрэг алхмыг тусдаа ажиглалт болгон бүртгэхийг тайлбарладаг. Cloud болон өөрөө байршуулсан орчинд илгээх хостын хаягийг тохируулж болдог учраас өгөгдлийн байрлалыг солих нь агентын бүх ажиглалтын логикийг дахин бичихтэй адил ажил биш. Харин tool-ийн оролт, гаралтын аль талбарыг мөрөнд оруулахыг баг өөрөө шийднэ.

LangGraph ашигладаг агентын хувьд LangSmith-ийн ойр зохицол нь зангилаа, төлөвийн өөрчлөлтийг гүйцэтгэлтэй нь холбож харахад хэрэгтэй. Өөр framework ашиглавал мөн trace цуглуулж болох ч тухайн агентын шийдвэрийг тайлбарлахад шаардлагатай tool-ийн аргумент, үр дүн бүртгэгдэж байгаа эсэх нь шийдвэрлэх шалгуур хэвээр. Аль платформыг сонгосон ч зөвхөн эцсийн хариуг хадгалсан мөрөөр дээрх алдааны шалтгааныг найдвартай тогтоохгүй.

Алдааг regression dataset болгох нь

Алдаатай trace бол оношлох баримт; regression dataset бол дараагийн хувилбарт дахин өгөх шалгалтын оролт юм. Нөхцөлт хүргэлтийн жишээнд хэрэглэгчийн анхны асуулт, зөв захиалгыг таних өгөгдөл, хүлээгдэх хариуг тохиолдолд хадгална. Tool дуудах зөв аргументыг тусад нь шалгавал агент санамсаргүйгээр зөв өгүүлбэр хэлсэн ч буруу захиалга сонгосон алдаа нуугдахгүй.

Langfuse-ийн dataset заавар одоо байгаа trace-ээс тохиолдол нэмэх, оролт ба хүлээгдэх үр дүн хадгалах, ажиллаж буй хэрэглүүрийг dataset дээр дахин ажиллуулж туршилтын үр дүнг үнэлэх урсгалыг үзүүлдэг. Дээрх жишээнд баг зөв захиалгын таних утгыг кодоор шалгаж, хэрэглэгчид очсон тайлбар ойлгомжтой эсэхийг өөр үнэлгээгээр хэмжиж болно. Энэ хоёр шалгалт өөр өөр алдааг илрүүлэх тул ганц ерөнхий оноонд нэгтгэхээс өмнө тус тусын үр дүнг харах нь ашигтай.

LangSmith-ийн evaluation баримтжуулалт нэвтрүүлэхийн өмнөх benchmark, нэгж болон regression шалгалтыг production дахь online үнэлгээнээс ялгадаг. Түүхэн production өгөгдлийг dataset болгож шинэ хувилбарт давтан ажиллуулах backtesting урсгал ч бий. Иймээс хүргэлтийн алдааг offline шалгалтад оруулаад prompt эсвэл model өөрчлөгдөх бүрт өмнөх хувилбартай харьцуулж болно; production дахь online үнэлгээ нь шинэ сэжигтэй тохиолдлыг илрүүлэх өөр үүрэгтэй.

Хоёр талд ч хүлээгдэх үр дүнг баг тодорхойлно. Захиалгын дугаарыг яг тааруулах дүрэмд кодын шалгалт тохиромжтой байж болох бол эцсийн тайлбарын утгыг үг бүрээр нь тааруулах нь хэт хатуу шалгуур болно. Үнэлгээний загвар ашиглавал буруу дохиог хүнээр нягтлах ажил мөн үлдэнэ. Платформын бэлэн урсгал нь энэ шийдвэрийг автомат болгохгүй.

Өгөгдлийн байрлал өөрчлөгдвөл ямар ажил нэмэгдэх вэ

Өөрийн дэд бүтцэд байрлуулах шаардлага хатуу үед Langfuse-ийн нээлттэй эхийн хувилбар шууд сонголт болдог. Langfuse-ийн байршуулалтын баримтжуулалт Docker Compose-ийг орон нутгийн хэрэглээ, туршилтад; production байршуулалтыг байгууллагын хариуцах дэд бүтцэд зориулсан сонголт гэж ялгадаг. Зарим нэмэлт боломжид лицензийн түлхүүр хэрэгтэй тул self-host эрхтэй байх нь бүх нэмэлт боломж үнэ төлбөргүй гэсэн үг биш.

Өөрөө ажиллуулах орчинд Langfuse Web, Worker, PostgreSQL, ClickHouse, Redis эсвэл Valkey, объектын сан орно. Trace хүлээн авах, дараалалд оруулах, хадгалах болон буцааж унших ажил эдгээр бүрэлдэхүүнд хуваагддаг. Иймээс өөрийн хадгалалтыг хянах эрхийн үнэ нь серверийн төлбөрөөр дуусахгүй: нөөцлөлт, шинэчлэлт, эвдрэл сэргээх, хандалтын эрхийг байгууллага хариуцна.

Монгол дахь багийн хувьд өгөгдлийг дотоод орчинд хадгалах шаардлага байгаа эсэхийг тодорхойлох нь зүйтэй. Trace-д хэрэглэгчийн асуулт, захиалгын таних утга, tool-ийн хариу орж болзошгүй тул шаардлагагүй хувийн мэдээллийг бүртгэхгүй байх шийдвэрийг байршуулах загвараас тусад нь гаргана. Өөрөө байршуулсан observability платформ нь агентын ашигладаг гаднын model API-д илгээх өгөгдлийг автоматаар хязгаарлахгүй.

Framework ба prompt-ийн хамаарал

LangChain эсвэл LangGraph дээрх агент LangSmith-ийн бэлэн tracing болон evaluation урсгалаас хамгийн шууд ашиг хүртэнэ. Гэхдээ LangSmith-ийг зөвхөн тэр орчинд ажилладаг гэж үзвэл боломжит сонголтыг үндэслэлгүйгээр хасна. LangChain-аас хамааралгүй stack-д ялгаа нь ижил agent run дотор model call, tool call, үр дүнг холбоход шаардагдах нэмэлт instrumentation болон түүнийг арчлах ажил юм.

Prompt management-ийг тусдаа жагсаалтын мөрөөр биш, алдаатай trace ба dataset-тэй холбож үнэлнэ. Аль prompt хувилбар тухайн хариуг үүсгэснийг хадгалаагүй бол шинэ хувилбарын regression үр дүнг тайлбарлахад хэцүү. Иймээс багт хэрэгтэй зүйл нь prompt хадгалах дэлгэц дангаараа бус, хувилбараа туршилтын үр дүнтэй холбож, production-д гаргасан өөрчлөлтийн нөлөөг ялгах боломж юм.

Нэг агент хоёр платформд ижил утгатай trace үүсгэж чадаж байгаа эсэх нь framework-ийн хамаарлыг ил тод болгоно. Хэрэв нэг талд tool-ийн аргумент эсвэл model call-ын холбоо дутвал dashboard-ийн өнгө үзэмжээр бус, тэр мэдээллийг нөхөх кодын ажлаар сонголтоо үнэлэх нь илүү бодитой. Dataset-ийн оролт, хүлээгдэх үр дүнг мөн ижил байлгаж харьцуулбал үнэлгээний урсгалын ялгаа харагдана.

Cloud-ийн төлбөр ба self-host ажиллагааны өртөг

Cloud хэрэглээний өртгийг агентын хүсэлтийн тоогоор дангаар нь төсөөлөхөд амархан зөрнө. Tool олон дууддаг нэг хүсэлт хэд хэдэн ажиглалт, үнэлгээ үүсгэдэг бөгөөд trace-ийн хадгалах хугацаа ч зардалд нөлөөлнө. Тиймээс төлбөрийн нэгж, хэрэглэгчийн суудал, хадгалалтын нөхцөлийг өөрийн агентын бодит гүйцэтгэлийн бүтэцтэй тулгаж тооцох хэрэгтэй.

Self-host хувилбарын хувьд программын лицензийн үнэ бага байх нь нийт өртөг бага гэсэн баталгаа биш. Өгөгдлийн сан, объектын сан, нөөцлөлт, шинэчлэлтийг ажиллуулах хүний цагийг хамт тооцно. Харин managed cloud-д энэ ажлын ихэнхийг нийлүүлэгч хариуцах учраас баг өөрийн дэд бүтцийг ажиллуулах чадамжийг үнэлгээний урсгалд хэмнэж буй цагтай харьцуулах шаардлагатай.

Гурван нөхцөлд аль нь тохирох вэ

• Cloud ашиглах бол: LangGraph төвтэй баг trace-ээс offline шалгалт, production online үнэлгээ рүү хурдан шилжихийг хүсвэл LangSmith илүү ойр сонголт. Олон framework холбодог эсвэл цаашдаа өөрөө байршуулж магадгүй баг Langfuse Cloud-ийн instrumentation урсгалыг авч үзнэ.
• Өөрийн дэд бүтцэд байрлуулах бол: нээлттэй эхийн self-host хувилбар шаардлагатай үед Langfuse-ийн зам тодорхой. LangSmith-ийн Enterprise нөхцөлийг Langfuse-ийн дэд бүтэц, ажиллагаа болон хэрэгтэй нэмэлт лицензийн нийт өртөгтэй харьцуулна.
• LangChain-аас хамааралгүй stack ашиглах бол: Langfuse-ийн OpenTelemetry эсвэл SDK холболт тухайн агентын tool call-ыг хэр бүрэн харуулахыг шалгана. LangSmith-ийг шууд хасах үндэс байхгүй; ижил trace, ижил regression тохиолдлыг байгуулахад шаардагдах тохиргоо сонголтыг шийднэ.

Мөн уншаарай:

• MCP эсвэл A2A: хэрэгсэл холбох ба агент даалгахыг бүү андуур
• LangChain эсвэл LlamaIndex: RAG-ийн чанарыг framework дангаараа шийдэхгүй
• Toggl эсвэл Clockify: үнэгүй таймер хяналтын хэрэгсэл болж хувирна