بەلكىم سىزمۇ مۇنداق جاۋابنى كۆرگەنسىز: Agent ئەستايىدىل «پايدىلانما 1، مۇناسىۋەت دەرىجىسى 61%» دەپ، ماۋزۇ ۋە مەنبەنى تولۇق كۆرسىتىدۇ، ئاندىن شۇ پايدىلانمىغا ئاساسەن خاتا جاۋاب بېرىدۇ. بۇ قۇرۇق توقۇلمىدىنمۇ زەھەرلىك؛ قۇرۇق توقۇلمىغا گۇمان قىلىسىز، مەنبەسى باردەك كۆرۈنگەن خاتا جاۋاب بولسا ھۇشيارلىقىڭىزنى بىۋاسىتە تۆۋەنلىتىدۇ. كۆپىنچە مودېل توقۇۋاتقان ئەمەس، ئىزدەش زەنجىرى «تېمىسى يېقىن، ئەمما جاۋاب يوق» ماتېرىيالنى ئېلىپ كەلگەن؛ مودېل پەقەت بېرىلگەن نەرسىنى سادىقلىق بىلەن ھەزىم قىلغان.
ئالدىنقى ماقالىدە HexClaw نىڭ Loop قاتلىمىنى ئېچىپ چۈشەندۈرگەنىدىم: ھالقا ئۆزى ئايلىنىدۇ، نازارەتچى نىشانغا سېلىشتۇرۇپ ئىلگىرىلەشنى باھالايدۇ، يېتەلمىسە كېيىنكى ئايلانمىنى قوشىدۇ. ئۇنى يېزىپ بولغاندىلا كېيىن نېمە يېزىش كېرەكلىكىنى بىلدىم؛ ھالقا ئايلىنىشقا باشلىغاندا، بۇرۇن ئانچە كۆزگە چېلىقمايدىغان مەسىلە سىستېمىلىق خەتەرگە ئايلاندى: ھەر بىر ئايلانما context ئىستېمال قىلىدۇ. بىر قېتىم شاۋقۇن كىرگۈزۈش پاراڭدا بىر قېتىملىق خاتالىق؛ Loop دا بولسا شۇ خاتالىق كېيىنكى پىلاننىڭ كىرگۈزۈشى بولۇپ، قوشۇلما ئۆسۈمگە ئايلىنىدۇ.
بۇ نۇقتىنىڭ ساھەدە ئاللىبۇرۇن نامى بار: Context Engineering. ئۆتكەن يىلنىڭ ئوتتۇرىلىرىدا بىر نەچچە ساھە پېشۋاسى ئۇنى كەڭ تارقاتتى، بۈگۈن بەك كۆپ دېيىلىدىغان بولۇپ قالدى. راستىنى ئېيتسام، دەسلەپ تارقالغاندا يەنە بىر مودا ئاتالغۇ دەپ قاراپ ئانچە ئارىلىشىمىدىم؛ HexClaw بىلىم ئامبىرىنىڭ پۈتۈن لىنىيەسىنى تاماملىغاندىن كېيىنلا، ئۇنىڭ مەن قىلىۋاتقان ئىشنى تەسۋىرلەيدىغانلىقىنى ئېتىراپ قىلدىم. ئېلېكترونلۇق سودا شىركىتى Shopify نىڭ CEO سى Tobi Lütke، «AI ئالدىن»نى پۈتۈن خىزمەتچى خاتىرىسىگە كىرگۈزگەن دەسلەپكى باشلىقلاردىن بىرى، مۇنداق ئېنىقلىما بەرگەن: «LLM ۋەزىپىنى ھەل قىلالايدىغان بولۇشى ئۈچۈن كېرەكلىك بارلىق context نى تەمىنلەش سەنئىتى». OpenAI نىڭ دەسلەپكى ئەزاسى، Tesla نىڭ سابىق AI دىرېكتورى Andrej Karpathy نىڭ سۆزى تېخىمۇ كەڭ تارقالدى:
«Context engineering — context كۆزنىكىنى كېيىنكى قەدەمدە دەل لازىم بولىدىغان ئۇچۇر بىلەن تولدۇرۇشنىڭ نازۇك سەنئىتى ۋە ئىلمى.»
مەنىسى: كۆزنەككە سېلىنىدىغىنى كۆپ ئۇچۇر ئەمەس، كېيىنكى قەدەم ئېھتىياجلىق بولغان دەل شۇ ئۇچۇر.
دىققەت قىلىڭ، ھېچقايسىسى «تېخىمۇ كۆپ بېرىش» دېمىگەن. Anthropic ئىنژېنېرلىق بىلوگىدا تېخىمۇ ئېنىق ئېيتىدۇ: context كەمچىل بايلىق، نىشان «ئىمكانقەدەر كىچىك يۇقىرى سىگناللىق token توپلىمى»نى تېپىش.
يېقىنقى ئىككى يىللىق ئەمەلىي تەتقىقاتمۇ بۇ يۆنىلىشنى كۈچەيتتى. Chroma گۇرۇپپىسى «قانچە كۆپ سالسا شۇنچە ئەستە تۇتالماسلىق»نى Context Rot دەپ ئاتىدى: token كۆپەيگەنسېرى مودېلنىڭ context تىن توغرا ئۇچۇر تېپىش ئىقتىدارى تۆۋەنلەيدۇ. Anthropic بۇ دەلىلگە ئەگىشىپ دىققەتنى خامچوت، attention budget دەپ قارىدى؛ ھەر قوشۇلغان token بۇ خامچوتنى خەجلەيدۇ. Liu قاتارلىقلارنىڭ Lost in the Middle تەتقىقاتى ئۇزۇن context نىڭ ئوتتۇرىسىدىكى ئىشلىتىلىش دەرىجىسى U شەكىللىك چۆكىدىغانلىقىنى بۇرۇنلا بايقىغان. RAG قىلىدىغانلار ئۈچۈن ئەڭ ئېغىرى SIGIR 2024 دىكى The Power of Noise: تاسادىپىي قوشۇلغان مۇناسىۋەتسىز ھۆججەت ئاساسەن زىيانسىز، توغرىلىقنى ھەقىقەتەن تۆۋەنلىتىدىغىنى «تېمىسى يېقىن، ئەمما جاۋاب يوق» توسقۇن ھۆججەتلەر. بۇ دەل ۋېكتور ئىزدەش ئەڭ ياخشى كۆرۈپ ئېلىپ كېلىدىغان تۈر.
شۇڭا بۇ ماقالە «RAG ئەسلەش نىسبىتىم قانچىلىك يۇقىرى»نى سۆزلىمەيدۇ. RAG ھەققىدىكى ماقالە بەك كۆپ، كۆپىنچىسى قانداق تېخىمۇ كۆپ تېپىشنى ئېيتىدۇ. بۇ يەردە ئەكسىنى، مەن HexClaw بىلىم ئامبىرى كودىدا ئەڭ كۆپ كۈچ سەرپ قىلغان قانداق تېخىمۇ قاتتىق تاشلاشنى سۆزلەيمەن. ئىزدەش زەنجىرىنىڭ ئالتە جەريانىنى ئايرىم ئاچساق، بىرىلا قوشۇش، قالغانلىرى ئېلىش: ئېغىرلىقنى تۆۋەنلىتىش، تۆۋەن چەك قويۇش، تەكرارنى چىقىرىش، تارايىتىش ۋە يېتەرلىك ئەمەسلىكىنى ئېتىراپ قىلدۇرۇش.
بۇ ماقالىدىن ئېلىپ كېتىشىڭىزنى ئەڭ خالايدىغان بىر گەپ: ئىزدەش سىستېمىسىنىڭ يادرولۇق ئىقتىدارى «تېپىش» ئەمەس، «رەت قىلىش». ئىشلەپچىقىرىش دەرىجىلىك RAG زەنجىرى ماھىيەتتە «ياق» دېيىشكە مەسئۇل ئېقىم لىنىيەسى؛ ھەر بىر «ياق» ھەقىقىي بىر مەغلۇبىيەت شەكلىگە ماس كېلىدۇ.
Prompt، ئاخىرقى ماقالە → Context، بۇ ماقالە → Harness، كېيىنكى ماقالە → Loop، ئاساسىي ماقالە، ئېلان قىلىنغان
Context نىڭ يەنە يېرىمى ئەسلەتمە تەرەپ؛ «چۈش كۆرىدىغان Agent ئەسلەتمىسى»نى كۆرۈڭ.
تولۇق كۆرۈنۈش رەسىمى: ئالتە جەريان، بىر پۈتۈن تۆۋەنلەش پەلەمپىيى ۋە ئۈچ باھالاش دەرۋازىسى. تۇراقلىق قىممەتلەرنىڭ ھەممىسى مەنبە كودتىن ئېلىنغان، توقۇلغان ئەمەس.

بۇ ئېقىم قەيەرگە ئورنىتىلغان: ھەر بىر پاراڭ ئايلانمىسى دەرۋازىدىن ئۆتىدۇ
ئاۋۋال ئورنىنى ئېنىقلايلى. HexClaw ماتورى ھەر بىر ئىشلەتكۈچى ئۇچۇرىنى بىر تەرەپ قىلغاندا مۇقىم بىر قەدەم بار؛ كود ئىزاھىدا 5.5 دەپ نومۇرلانغان «بىلىم ئامبىرى ئىزدەش، RAG context كۈچەيتىش». بىلىم ئامبىرى ئوچۇق بولسىلا نۆۋەتتىكى ئۇچۇر بىلەن kb.Query() نىڭ تولۇق ئىزدەشى ئىجرا بولىدۇ، topK سۈكۈتتىكى قىممىتى 3، تېپىلغان مەزمۇن بۇ ئايلانمىغا context سۈپىتىدە كىرگۈزۈلىدۇ. ئىزدەش مەغلۇپ بولسا پەقەت log خاتىرىلىنىدۇ، جاۋاب توسۇلمايدۇ. ماتېرىيال قاتلىمىنىڭ خاتالىقى پاراڭنى ئۈزۈشكە لايىق ئەمەس. بۇ بىرىنچى «ئېلىش پەلسەپىسى»: بۇ ئايلانمىدا پايدىلانما بولمىسىمۇ بولىدۇ، ئىزدەش خاتالىقى جاۋاب خاتالىقىغا يۇقماسلىقى كېرەك.
ھەر ئايلانمىدا ئۆزى ئىجرا بولىدىغان بۇ يولدىن باشقا، Agent ئۆزى چاقىرالايدىغان knowledge_search قورالى بار. كود ئىزاھى ۋەزىپە بۆلۈنۈشىنى ئېنىق يازغان: ئۆزلۈكىدىن كىرگۈزۈش «ھەر ئايلانمىدا پۈتۈن ئامبارنى ئىزدەش»، قورال بولسا مودېل scoped recall، يەنى دائىرىسى چەكلىك ئەسلەش خالىغاندا ئىشلىتىلىدۇ. مەنبە، تۈر ياكى كۈن بويىچە سۈزەلەيدۇ؛ مەسىلەن «پەقەت مەن يۈكلىگەن PDF»، «پەقەت ئۆتكەن ھەپتە ساقلىغانلىرىم». شەرت ساقلاش قاتلىمىغا بىۋاسىتە تۆۋەن يەتكۈزۈلىدۇ. بىرى ئارقا كۆرۈنۈش رادىئاتسىيەسىگە ئوخشايدۇ، بىرى تەشەببۇسكار ھەرىكەت.
سۈزۈش يولغا قويۇشتا ئۆلچەملىك ئىش قىلىشنى كۆرسىتىدىغان بىر تەپسىلات بار: مەنبە ۋە تۈر شەرتى topK دىن بۇرۇن ساقلاش قاتلىمىغا چۈشۈرۈلىدۇ. پۈتۈن ئامباردىن topK ئېلىپ ئاندىن سۈزسە، ھەقىقىي ماس ھۆججەت نامزات كۆلچىكىگە كىرەلمەي جىمجىت قالدۇرۇلۇشى مۇمكىن. ئەمما كۈن شەرتى قەستەن تۆۋەنگە چۈشۈرۈلمىگەن: SQLite دا كۈن RFC3339 تېكىستى بولۇپ ساقلىنىدۇ، ۋاقىت رايونى ئوخشىمىغان تىزمىنى بىۋاسىتە سېلىشتۇرۇش ئىشەنچلىك ئەمەس. شۇڭا كود Go قاتلىمىغا قايتىپ ھەقىقىي time.Time بىلەن سېلىشتۇرىدۇ؛ سەۋەبى ئىزاھتا ئېنىق. ئىككى سۈزۈش، ئىككى ئۇسۇل، ھەر بىرىنىڭ سەۋەبى بار. كود كۆچۈرۈلگەنمۇ ياكى ئويلىنىپ يېزىلغانمۇ، بۇنداق جايدا بىلىنىدۇ.
ئەمدى ئېقىمغا كىرىمىز. كود ئىزاھىدىكى تولۇق تەرتىپ: سوئال كېڭەيتىش → كەڭ ئەسلەش → RRF بىرىكتۈرۈش → مۇناسىۋەت تۆۋەن چېكى → LLM قايتا رەتلەش. Feature flag دەرۋازىسى يوق، سۈكۈتتىكى سەپلىمىدە ھەممىسى ئوچۇق؛ قايسى بۆلەك كەم بولسا شۇ ھالقا ئۆزلۈكىدىن تۆۋەنلەيدۇ. «سۈكۈتتىكى ھالەتلا ئەڭ ياخشى ئەمەلىيەت» تاللىشىغا كېيىن قايتىمىز.
نۆل جەريان: ئامبارغا كىرگۈزگەندىن باشلاپ شاۋقۇننى توسۇش
نۇرغۇن ئادەم ئىزدەش سۈپىتى سوئال ۋاقتىدا بەلگىلىنىدۇ دەپ ئويلايدۇ، ئەمەلىيەتتە يېرىمى يېزىش ۋاقتىدىلا بەلگىلىنىدۇ. ئاۋۋال ماتېرىيال كىرىشى: يۈكلەش كۆپ ئۇچرايدىغان فورماتلارنى قوبۇل قىلىدۇ، مەزمۇن چىقىرىش ئارقا تەرەپتە بىرلىككە كەلگەن. PDF ئۈچۈن poppler نىڭ pdftotext ى ئىشلىتىلىدۇ، ToUnicode تولۇق بىر تەرەپ قىلىنىپ خەنزۇچە بۇزۇلغان ھەرپنى ھەل قىلىدۇ؛ كونا .doc سىستېما قورالىدىن ئۆتىدۇ؛ رەسىم كۆرۈش مودېلىغا بىۋاسىتە بېرىلىپ ئىزدەشكە بولىدىغان تېكىستكە ئايلاندۇرۇلىدۇ. ئەڭ يېڭى قەدەم ھۆججەت ئىچىگىمۇ كىردى: PDF سىكان بەتلىرى، Word ئىچىدىكى سۈرەت، دىئاگرامما ۋە فورمۇلا بىرمۇبىر چىقىرىلىپ VLM بىلەن تېكىستكە ئايلاندۇرۇلىدۇ، «ھۆججەت كۆرۈنۈش تەھلىلى» بۆلىكى سۈپىتىدە ئاساسىي تېكىستكە قوشۇلۇپ ئامبارغا كىرىدۇ. ئىككى تەپسىلات مۇھىم: كۆرۈش تەھلىلى بىلىم ئامبىرى سەپلىگەن ئوخشاش كۆرۈش مودېلىنى قايتا ئىشلىتىدۇ، يۈكلەش زەنجىرىدە باشقا مودېل چاقىرىش يولى قۇرۇلمايدۇ، ئىقتىدار تارماقلانمايدۇ؛ كۆرۈش مودېلى سەپلەنمىسە سەمىمىي تۆۋەنلەيدۇ، پەقەت تېكىست قاتلىمىنى ئىندېكسلاپ «رەسىم مەنىسى ئامبارغا كىرمىدى» دەپ ئېنىق ئاگاھلاندۇرىدۇ، جىمجىت ئۆتۈپ كەتمەيدۇ. كىرىش قانچە كەڭ بولسىمۇ، كېيىنكى قائىدە ئوخشاش.
كىرگەندىن كېيىنكى بىرىنچى كېسىش chunk قىلىش. ئۇنى «ھەرپ سانىغا قاراپ كېسىش» دەيدىغان ئاددىي ئىش دەپ قاراش ئاسان، ئەمما ئۇ نەقىل قىلىشقا بولىدىغان ئەڭ كىچىك دەلىل بىرلىكىنى بەلگىلەيدۇ. بەك كىچىك بولسا مودېل سەۋەب-ئاقىۋەتنى ئالالمايدۇ؛ بەك چوڭ بولسا مۇناسىۋەتسىز مەزمۇن ۋېكتور ئوخشاشلىقىنى سۇيۇلدۇرۇپ، «ئىچىدە بىر ئاز مۇناسىۋەت باردەك» چوڭ پارچىلارلا كېلىدۇ. HexClaw قۇرۇلمىنى ئالدىن، قايتىلانما كېسىشنى زاپاس قىلىدۇ: ماۋزۇ قاتلىمى بار ھۆججەت قۇرۇلمىسى بويىچە، ئاددىي تېكىست ياكى ماۋزۇسىز مەزمۇن قايتىلانما ئۇسۇلدا كېسىلىدۇ. سۈكۈتتىكى چوڭلۇقى 400 ھەرپ، قوشنا پارچىلار 80 ھەرپ ئۈستى-ئۈستىگە چۈشىدۇ؛ بۇ كېسىش نۇقتىسىدىكى مەنىنى ئۈزۈپ قويماسلىق ئۈچۈن. توختام ۋە پاتېنت قاتارلىق تەبىئىي قۇرۇلمىلىق تېكىستتە بۇ ئالاھىدە قىممەتلىك: ماددا بىلەن تەلەپنىڭ ئۆزى دەلىل بىرلىكى، قۇرۇلما بويىچە كېسىلگەندە جاۋاب «بىر پارچە» ئەمەس، «نەچچىنچى ماددا»نى كۆرسىتەلەيدۇ. كېسىش يوقاتقان پۈتۈن كونتېكىست تۆۋەندىكى بىرىنچى ئىش بىلەن تولۇقلىنىدۇ.
كېسىلگەندىن كېيىن ئېقىم يەنە ئۈچ كىچىك ئىش قىلىدۇ.
بىرىنچى: ھەر chunk قا «كېلىپ چىقىشى»نى تىكىش. ھۆججەت بۆلەكلەنگەندىن كېيىن، ھەر chunk نىڭ ئالدىغا ھۆججەت قاتلىمىدىكى context، يەنى ماۋزۇ يولى ۋە ئىختىيارىي LLM ئەھۋال خۇلاسىسى قوشۇلىدۇ. ۋېكتور embedding بىلەن BM25 تولۇق تېكىست ئىندېكسى شۇ كۈچەيتىلگەن تېكىست ئۈستىدە قۇرۇلىدۇ. بۇ Anthropic ئوتتۇرىغا قويغان Contextual Retrieval، contextual embeddings ۋە contextual BM25. ئۇلارنىڭ ئەمەلىي نەتىجىسىدە top-20 ئىزدەش مەغلۇبىيىتى 49% تۆۋەنلىگەن، قايتا رەتلەش قوشۇلغاندا 67% تۆۋەنلىگەن. ھەل قىلىدىغان مەسىلە ئېنىق: يالغۇز chunk «بۇ سەپلىمىنىڭ سۈكۈتتىكى قىممىتى 30 كۈن» دېسە، context بولمىسا قايسى سىستېمىنىڭ قايسى سەپلىمىسى ئىكەنلىكى نامەلۇم. «كېلىپ چىقىشى» قوشۇلغاندىن كېيىن مەنىلىك ياكى سۆزلۈك ئىزدەشتە توغرا سوئال ئۇنى تاپالايدۇ، خاتا سوئال خاتا تېپىشىمۇ قىيىنلىشىدۇ. Chunk ئەھۋال خۇلاسىسىنى يازىدىغان LLM چاقىرىشىنىڭمۇ خامچوتى بار: ھۆججەت تېكىستى ئەڭ كۆپ 6000 rune، بىر chunk ئەڭ كۆپ 1200 rune، ھەر ھۆججەتتە پەقەت ئالدىنقى 200 chunk قا ئەھۋال يېزىلىدۇ؛ ئېشىپ كەتسە جىمجىت ئەمەس، WARN چىقىرىلىدۇ. كۈچەيتىش ئۇسۇلىنىڭ ئۆزىمۇ چىقىم چەكلىمىسىگە بويسۇنىدۇ.
ئىككىنچى: سوئال بىلەن ھۆججەت ۋېكتور بوشلۇقىغا ئوخشاش يۈز بىلەن كىرمەيدۇ. ۋەزىپە ئالدى قوشۇمچىسىنى قوللايدىغان embedding مودېلىدا، مەسىلەن nomic ئائىلىسىدىكى search_query / search_document، سوئال ۋە ھۆججەتكە ئايرىم بۇيرۇق ئالدى قوشۇمچىسى قوشۇلىدۇ. سوئال بىلەن جاۋاب مەنىلىك بوشلۇقتا ئەسلىدىنلا ئوخشاش شەكىلدە بولماسلىقى كېرەك؛ سىممېترىك بولمىغان embedding «سوئال بىلەن جاۋاب ئىزدەش» يۆنىلىشىنى تېخىمۇ توغرا قىلىدۇ. ئالدى قوشۇمچە پەقەت embedding كىرگۈزۈشىگە تەسىر قىلىدۇ، ساقلانغان مەزمۇن ۋە BM25 نى بۇلغىمايدۇ.
ئۈچىنچى: embedding API ئېغىزىدا كېسىش دەرۋازىسى. ھەر قانداق تېكىست embedding غا كىرىشتىن بۇرۇن rune بويىچە 6000 غا كېسىلىدۇ. بۇ سان ئەمەلىي: CJK نىڭ ئەڭ ناچار تەخمىنەن 1 token/rune ھالىتىدىمۇ ئاساسلىق embedding مودېللىرىنىڭ 8191/8192 token چېكىدىن تۆۋەن. نورمال 400 ھەرپلىك chunk بۇ چەككە يەتمەيدۇ؛ ئۇزۇن query، HyDE ھاسىل قىلغان پەرەز ھۆججەت ياكى خاتا يوللانغان پۈتۈن ماقالە قاتارلىق تاسادىپىي ئەھۋالنى توسۇپ، بىر قېتىملىق 413 خاتالىقى ياكى ئارتۇق چىقىمدىن ساقلايدۇ. كېسىش بىلەن embedding cache ئىككى ئۈستىلەشكە بولىدىغان بېزەكلىگۈچ؛ كېسىش سىرتتا، cache ئىچىدە بولۇشى تەۋسىيە قىلىنىدۇ، cache ئاچقۇچى كېسىلگەندىن كېيىنكى تېكىستكە باغلانىدۇ. ئوخشاش ئۇزۇن ھۆججەت قايتا كىرگەندە كېسىش ۋاقتى پەرقلىق بولغانلىقى ئۈچۈن cache ئىناۋەتسىز بولمايدۇ. ئىككى بېزەكلىگۈچنىڭ تەرتىپىنىمۇ ئېنىق ئويلىنىدىغان يەر، ئىنژېنېرلىق بىلەن demo نىڭ چېگراسىدۇر.
ساقلاش ئاساسى SQLite ۋە FTS5 مەۋھۇم جەدۋىلى؛ ئايرىم ۋېكتور ئامبىرى قوشۇلمىغان، ۋېكتور ۋە تولۇق تېكىست ئىندېكسى ئوخشاش يەرلىك ھۆججەتتە. قوزغالغاندا chunk ئۆچۈرۈلۈپ ئىندېكسى قالغان يېتىم FTS5 خاتىرىلىرى تازىلىنىدۇ؛ ئۆچۈرۈلگەن ماتېرىيالنىڭ نەتىجىدە قايتا كۆرۈنۈشى توسۇلىدۇ. بۇمۇ «ئۆتمۈشتىن كەلگەن شاۋقۇن»نى توسۇش.
بىرىنچى ۋە ئىككىنچى جەريان: بىردىنبىر قوشۇش ھالقىسىنىڭمۇ يۇقىرى چېكى بار
پۈتۈن ئېقىمدا پەقەت بىرىنچى جەريان قوشۇش قىلىدۇ: سوئال كېڭەيتىش. ئىشلەتكۈچىنىڭ ئەسلى سوئالى دائىم قىسقا ۋە ئېغىزچە، بىۋاسىتە ئىزدىسە قالدۇرۇۋېتىدۇ. HexClaw ئۈچ يولنى تەڭ ئىجرا قىلىدۇ: ئەسلى query ساقلىنىدۇ، multi-query 3 مەنىلىك ۋارىيانت ھاسىل قىلىدۇ، HyDE يەنە بىر يول قوشىدۇ. HyDE ئاۋۋال LLM غا «پەرەز جاۋاب» يازدۇرۇپ، ئاندىن شۇنىڭ بىلەن ئىزدەيدۇ؛ سوئال بىلەن جاۋابنىڭ ۋېكتور شەكلى پەرقلىق، پەرەز جاۋاب بىلەن ھەقىقىي جاۋابنىڭ شەكلى يېقىن. ئومۇمىي سان قاتتىق 5 دە توختايدۇ. كود ئىزاھىدىكى سەۋەب ئاددىي: «ئەسلەش چىقىمىنى كونترول قىلىش». قوشۇش ھالقىسىنىڭمۇ چېكى بار، بۇ ئۆزىنى چەكلەش پۈتۈن زەنجىرگە سىڭگەن.
ئاندىن كەڭ ئەسلەش: ھەر query بىر ۋېكتور ئىزدەش ۋە بىر BM25 تولۇق تېكىست ئىزدەشتىن ئۆتىدۇ. نامزات كۆلچىكى CandidateK = 50، شۇنداقلا ھەمىشە ئاخىرقى topK نىڭ كەم دېگەندە 3 ھەسسىسى بولىدۇ. ئىزاھتا «rerank تارايىتىشىغا يېتەرلىك بوشلۇق قالدۇرۇش» دېيىلگەن. بۇ تىپىك over-retrieve لايىھىسى: ئاۋۋال قەستەن كەڭ تېپىش، كېيىنكى ھەر ئېلىش جەريانىدا تاشلايدىغان نەرسە بولسۇن.
ئۈچىنچى جەريان: بىرىكتۈرۈش ۋە تۈزىتىلگەن ھەقىقىي بىر ئازگال
ھازىر قولدا ئەڭ كۆپ ئون رەتلىك تىزىملىك بار: 5 query × ۋېكتور/تېكىست ئىككى يول. ئۇلارنىڭ نومۇر ئۆلچىمىنى سېلىشتۇرغىلى بولمايدۇ: cosine ئۇدا گېئومېتىرىيەلىك مىقدار، BM25 سۆز چاستوتىسى ستاتىستىكىسى. بىۋاسىتە ئېغىرلىق بىلەن قوشۇش بەدەن تېمپېراتۇرىسى بىلەن ھاۋا بېسىمىنى قوشقانغا ئوخشايدۇ. ساھەنىڭ ئۆلچەملىك چارىسى RRF، Reciprocal Rank Fusion، Cormack قاتارلىقلار، SIGIR 2009. نومۇرغا ئەمەس رەتكە ئىشىنىدۇ، ھەر يول 1/(k+rank) تۆھپە قوشىدۇ، k ساھەدىكى ئۆلچەملىك 60. بۇ تۇراقلىق سان بىلەن ماقالە مەنبەسى سەپلىمە مەيدانى ئىزاھىدا يېزىلغان.
ئەمما HexClaw دەرسلىكتىكى RRF نى ئەمەس، نومۇر ئېغىرلىقى قوشۇلغان RRF نى ئىشلىتىدۇ؛ چۈنكى دەرسلىك نەشرى ئەمەلىي ئىشلىتىشتە يىقىلغان. بۇ ئازگالنى تولۇق ئېيتىشقا ئەرزىيدۇ: ساپ rank RRF پەقەت رەتكە قاراپ نومۇرغا قارىمايدۇ، شۇڭا «بىر يولدىكى يالغۇز ئاجىز ماسلىق» rank-1 سۈپىتىدە تولۇق ئېغىرلىق ئالىدۇ. قاچان بۇنداق بولىدۇ؟ تىللار ئارا ئىزدەشتە: خەنزۇچە سوئال، ئىنگلىزچە ھۆججەت، سۆزلۈك ئورتاقلىقى يوق دېگۈدەك. BM25 پەقەت تاسادىپىي ئوخشاش بىر سۆزنى تاپىدۇ، نومۇرى بەك تۆۋەن، ئەمما شۇ يولدا بىرىنچى. ساپ RRF بۇ يالغان سۆزلۈك ماسلىقىنى ھەقىقىي كۈچلۈك ۋېكتور مەنىلىك ماسلىقىدىن ئۈستۈن قىلىدۇ. تۈزىتىش rank تۆھپىسىنى شۇ يولنىڭ نورماللاشتۇرۇلغان نومۇرىغا كۆپەيتىش:
بۇ fuse يادرولۇق لوگىكىسى، تىزىش ئۈچۈن ئازراق قىسقارتىلغان؛ ئىزاھلار ئەسلى كودتىن.
تەسىرى ئىككى يۆنىلىشلىك: نورمال نومۇرى تۆۋەن ئاجىز ماسلىقنىڭ rank پايدىسى شۇ نىسبەتتە ئازىيىدۇ؛ ھەقىقىي ئېنىق ماسلىق، مەسىلەن فۇنكسىيە نامىنى ئىزدىگەندە BM25 تولۇققا يېقىن نومۇر بېرىدىغان ھالەت، يەنىلا تولۇق ئېغىرلىقنى ساقلايدۇ. ئىزاھنىڭ ئاخىرقى جۈملىسى ئېنىق: «يالغان ماسلىقنىڭ يولدىن ئازدۇرۇشىنى يىلتىزىدىن تۈزىتىپ، ئېنىق ئاتالغۇ ماسلاشتۇرۇش ئىقتىدارىنى يوقاتماسلىق». بىرىكتۈرۈلگەن نومۇر يەنە ۋاقىت ئاجىزلىشىشىدىن ئۆتىدۇ، يېرىم ئۆمرى 30 كۈن؛ مۇناسىۋەت تەڭ بولسا يېڭى ماتېرىيال كونىدىن ئۈستۈن.
تۆتىنچى، بەشىنچى ۋە ئالتىنچى جەريان: تۆۋەن چەك، قايتا رەتلەش ۋە چىقىش
بىرىكتۈرگەندىن كېيىن پۈتۈن ئېقىمدىكى پوزىتسىيەسى ئەڭ ئېنىق دەرۋازا مۇناسىۋەت تۆۋەن چېكى. ۋېكتور ئوخشاشلىقى 0.55 تىن تۆۋەن، 0–1 گە نورماللاشتۇرۇلغان cosine نومۇرىدا، ھەمدە ھېچقانداق ئاچقۇچلۇق سۆز ماسلىقى يوق نامزات بىۋاسىتە تاشلىنىدۇ. ئىزاھ بۇنى «ساپ ئاجىز ۋېكتور ماسلىقى» دەپ ئاتايدۇ. مەنىلىك مودېل «بىر ئاز ئوخشايدۇ» دەپ، سۆزلۈك جەھەتتە ھېچ دەلىلى يوق نەرسە دەل The Power of Noise دىكى ئەڭ زەھەرلىك توسقۇن تۈر. ھۆكۈم لوگىكىسى بەك قىسقا:
8–10-قۇرغا دىققەت قىلىڭ: تۆۋەن چەك بارلىق نامزاتنى يوقاتسا، شەرت يۇمشىتىلىپ ئەسلىچە قايتۇرۇلىدۇ. «ياق» دېيىشنىڭمۇ چېكى بار؛ تۆۋەن چەك ياخشى نەتىجە ئىچىدىكى ناچار نەتىجىنى توسۇيدۇ، ئىشلەتكۈچىنىڭ پۈتۈن سوئالىنى ئەمەس. ئاز ۋە ئېنىق بولسۇن، ئەمما ھەممىسى يوق بولمىسۇن.
تۆۋەن چەكتىن كېيىن نامزات بىرىكتۈرۈلگەن نومۇر بويىچە رەتلىنىپ، 50 لىك قايتا رەتلەش كۆلچىكىگە چەكلىنىدۇ ۋە ئاخىرقى رەت دەرۋازىسىغا كىرىدۇ. بۇ يەردە ئۈچ پەلەمپەي بار: مەخسۇس cross-encoder قايتا رەتلىگۈچ ئالدىن، ئۇ تېز، تېجەشلىك ۋە توغرىراق؛ ئۇ بولمىسا LLM-as-reranker سۆھبەت مودېلىنى قايتا ئىشلىتىپ ھەر نامزاتنىڭ مۇناسىۋىتىنى باھالايدۇ؛ LLM مۇ بولمىسا MMR كۆپ خىللىق تاللاشقا قايتىدۇ، λ=0.7. MMR تاسادىپىي تاللانمىغان: ئۇ يېقىن تەكرار chunk لار topK نى تولدۇرۇۋېتىشتىن ساقلايدۇ. بىر گەپ ئۈچ ھۆججەتتە ساقلىنىپ، ھەممىسى يۇقىرى مۇناسىۋەتلىك بولسا، ھەممىسىنى تاللاش ئۈچ ھەسسە token سەرپ قىلىپ پەقەت بىر ھەسسە ئۇچۇر ئېلىشقا تەڭ. كۆپ خىللىقنىڭ ئۆزىمۇ شاۋقۇن تۆۋەنلىتىش.
ئاخىرقى، ئالتىنچى جەريان چىقىشتىكى ئىپادە. ئىزدەش نەتىجىسى قۇرۇق تېكىست بولۇپ context قا قوشۇلمايدۇ؛ ھەر بىرىدە «پايدىلانما N، مۇناسىۋەت xx%، ھۆججەت ماۋزۇسى ۋە مەنبە» دېگەن كىملىك بار. پۈتۈن كىرگۈزۈش ئاخىرىدا مۇقىم بىر جۈملە بار:
«يۇقىرىدىكى پايدىلانما ئۇچۇرغا ئاساسەن ئىشلەتكۈچىنىڭ سوئالىغا جاۋاب بېرىڭ. پايدىلانما ئۇچۇر جاۋاب بېرىشكە يېتەرلىك بولمىسا، راستىنى ئېيتىڭ.»
بۇ توردا ئىجرا بولىدىغان زەنجىرنىڭ ئاخىرقى مۇداپىئە سىزىقى. ئالدىنقى بەش جەريان «نېمە بېرىش»نى سۈزىدۇ، بۇ جۈملە «بەرگەندىن كېيىن قانداق جاۋاب بېرىش»نى باشقۇرىدۇ. ئۇ prompt قاتلىمىدىكى چەك، كۈچى چەكلىك؛ نەشر دەرۋازىسى بۆلىكىدە بۇنىڭ ھېسابىنى ئېنىقلايمىز.
تۆۋەنلەش مەغلۇبىيەت ئەمەس، لايىھەنىڭ بىر قىسمى
بۇ تۆۋەنلەش پەلسەپىسىنىڭ كونكرېت باشلىنىشى بار. بىلىم ئامبىرىنى تولۇقلىغاندا دەسلەپ ئۇچرىغىنىم مۇرەككەپ ئالگورىزىم ئەمەس، بىر قۇر خاتالىق ئىدى:
يۈزەكى قارىغاندا Ollama غا بىر embedding مودېلى چۈشۈرۈلمىگەن، چۈشۈرسە تۈگەيدۇ. ئەمما ئۇ سىستېما چېگراسى سوئالىنى چىقاردى: بىر بىلىم ئامبىرى، نېمىشقا Embedding مودېلى قاچىلانمىغانلىقى ئۈچۈن ھەتتا ھۆججەت ساقلاشقا يول قويمايدۇ؟ ماتېرىيال كىرىشىنىڭ بىرىنچى دەرۋازىسى «ۋېكتورلاشتۇرۇش چوقۇم مۇۋەپپەقىيەتلىك بولسۇن» بولسا، بۇ تېخى بىلىم ئامبىرى ئەمەس، ۋېكتور ئىزدەش demo سى.
شۇڭا تۆۋەنلەش پەلەمپىيىنىڭ بىرىنچى قەۋىتى يېزىش تەرەپتە قۇرۇلدى: ئەسلى تېكىست ئاۋۋال ئامبارغا، chunk ئاۋۋال يېزىلىدۇ، FTS5 تېكىست ئىندېكسى ئاۋۋال ئىشلىتىلىدۇ. Embedding مەيدانى بوش بولالايدىغان BLOB، مودېل سەپلەنسە ۋېكتور تولۇقلىنىدۇ؛ مەغلۇپ بولسا warning بىلەن ساپ تېكىست ئىندېكسىغا تۆۋەنلەيدۇ، ھۆججەت ھەرگىز قايتۇرۇلمايدۇ. (doc_id, chunk_index) نىڭ بىردىنبىرلىك شەرتى قايتا ئىندېكسلىغاندا ئوخشاش ئورۇندىكى chunk نىڭ توپلىنىشىنىمۇ توسۇيدۇ. بىر جۈملە: Embedding كۈچەيتىلگەن ئىندېكس، ھۆججەتنىڭ ئۆزى ئەمەس.
سوئال تەرەپنىڭ پەلەمپىيى ئارقىدىن ئۇلىنىدۇ:
▸ LLM كەم: مەسىلەن پەقەت embedding بار، سۆھبەت مودېلى يوق؛ سوئال كېڭەيتىش ۋە LLM قايتا رەتلەش ئۆزلۈكىدىن ئاتلىنىدۇ، رەت MMR غا قايتىدۇ. زەنجىر يەنىلا تولۇق، پەقەت ئىككى كۈچەيتىش كەم.
▸ Embedder كەم: ھېچ مودېل سەپلەنمىگەن؛ ۋېكتور يولى تاقىلىدۇ، ئېغىرلىق ساپ تېكىست 0/1 غا ئۆتىدۇ، زەنجىر FTS5 + BM25 ساپ ئاچقۇچلۇق سۆز ئىزدەشكە ئايلىنىدۇ. مۇناسىۋەت تۆۋەن چېكىمۇ ئۆزى كۈچتىن قالىدۇ، چۈنكى ئۇ ۋېكتور نومۇرى ئۈچۈن.
▸ FTS5 مەغلۇپ: سوئالدىكى ئالاھىدە ھەرپ خاتالىق چىقارسا ياكى خەنزۇچە بۆلۈش ماس كەلمەي نەتىجە نۆل بولسا، يەنە LIKE scan زاپىسىغا تۆۋەنلەيدۇ. سۆز بۆلۈش تەرەپتە CJK bigram ۋە ئەسلى سۆزنى ساقلاش بار، خەنزۇچە ۋە كود بەلگىسىنىڭ ھەر ئىككىسىگە سۆزلۈك ئورۇن بار.
▸ تۆۋەن چەك ھەممىنى تاشلىسا: شەرت يۇمشىتىلىپ قايتۇرۇلىدۇ، نەتىجە بوشىتىلمايدۇ.
▸ ئىزدەش خاتالىقى: log يېزىلىدۇ، بۇ ئايلانما پايدىلانمىسىز، جاۋاب نورمال داۋاملىشىدۇ.
ھەر قەۋەتنىڭ ئېنىق ئەڭ تۆۋەن ئىقتىدارى بار، ھەممىسى ئۆزلۈكىدىن ۋە ئىشلەتكۈچىگە سەزدۈرمەي بولىدۇ. بۇ «سۈكۈتتىكى ھالەت ئەڭ ياخشى ئەمەلىيەت، feature flag يوق» بىلەن ئوخشاش پوزىتسىيە: ئىزدەش سۈپىتىنى ئېلىش ئۈچۈن ئىشلەتكۈچى سەپلىمە ھۆججىتىنى تەتقىق قىلىشقا مەجبۇر بولماسلىقى، بىر مودېل كەم دەپ پۈتۈن سىستېما ئىشتىن توختىماسلىقى كېرەك. يەرلىك دېتال ھەر خىل مۇھىتقا يولۇقىدۇ، تۆۋەنلەش پەلەمپىيى ئۇنىڭ ماسلىشىشچانلىقى.
ئوخشاش سەمىمىيلىك سىغىمدا بار. HexClaw ئايرىم ۋېكتور ئامبىرى قوشمىغان؛ Go قاتلىمى embedding BLOB ئۈستىدە پۈتۈنلەي ئېنىق cosine scan قىلىدۇ: ھەر قۇرنى يېشىپ ھېسابلاپ بولسا تاشلايدۇ، ۋېكتور ئىچكى ساقلىغۇچتا دائىمىي تۇرمايدۇ. ھەر 1000 قۇردا بىكار قىلىش سىگنالى تەكشۈرۈلىدۇ، ئۇزۇن scan نى ھەر ۋاقىت توختاتقىلى بولىدۇ. 100000 chunk تىن ئاشسا WARN چىقىرىپ، تەخمىنىي ئىندېكسنى ئويلىشىش ۋاقتى كەلگەنلىكىنى ئېنىق ئېيتىدۇ.
تاللاشنىڭ پوزىتسىيەسى ئېنىق: شەخسىي بىلىم ئامبىرى كۆلىمىدە ئېنىق scan تەخمىنىي ئىزدەشتىن مۇقىمراق، بالدۇر ئىقتىدار ياخشىلاش ئۈچۈن ئەسلەشنى قۇربان قىلمايدۇ. ھەقىقەتەن توغرىسىغا كېڭەيتىش كېرەك بولغاندا توغرا يول بوسۇغىنى چوڭايتىش ئەمەس، پۈتۈن ئىندېكس قاتلىمىنى ئايرىپ ANN، HNSW ياكى DiskANN قاتارلىق تەخمىنىي ئىندېكسقا ئالماشتۇرۇش. شەرتى source / doc / chunk دەلىل مەيدانلىرىنىڭ مەنىسى ئەينەن ساقلىنىشى. O(n·d) ئۇنىڭ ھەقىقىي چېگراسى، يۈز مىڭ بولسا ئۆزى كۆرسەتكەن سېرىق كارتا.
Memory مۇ Context: ئىككى ئىزدەش، ئىككى خىل توغرىلىق ئۆلچىمى
بىر سوئالدىن قاچقىلى بولمايدۇ: HexClaw نىڭ ئەسلەتمە سىستېمىسىمۇ context مەنبەسى، نېمىشقا ئەسلەتمە بىلەن بىلىم ئامبىرىنىڭ ئىزدەش مېخانىزمى پۈتۈنلەي باشقا؟ ئەسلەتمە تەرەپ 0.7 ۋېكتور ۋە 0.3 BM25 ئېغىرلىق يىغىندىسى، ئاندىن يېقىنلىق ۋە مۇھىملىققا كۆپەيتىلىدۇ؛ بىلىم ئامبىرى RRF ۋە LLM قايتا رەتلەش. بۇ كىمنىڭ ئىلغارلىقى ئەمەس، ئىككى سانلىق مەلۇماتنىڭ توغرىلىق ئۆلچىمى باشقا.
ئەسلەتمە «سىز ھەققىدىكى ئاز، يۇقىرى قىممەتلىك پاكىت»، بىر نەچچە يۈز تۈر كۆلىمىدە؛ «ئۆتكەن ھەپتە ئېيتقان ئىش ئۈچ ئاي بۇرۇنقىدىن ئالدىن» بولۇشى كېرەك، ۋاقىت ۋە مۇھىملىق بىرىنچى دەرىجىلىك. بىلىم ئامبىرى «كۆپ ھۆججەت ئىچىدىن دەلىل تېپىش»، ئونمىڭلىغان chunk كۆلىمىدە؛ ئون خىل رەتتىن ھەقىقىي مۇناسىۋەتلىك ئۈچ تۈرنى بىرىكتۈرۈش كېرەك، شاۋقۇنغا چىدامچانلىق بىرىنچى دەرىجىلىك. بىر مېخانىزم بىلەن ئىككى تۈرنىلا ھەل قىلماق ھەقىقىي ئاسانچىلىق. Context Engineering نىڭ بىر قاتلام بولۇش مەنىسىمۇ شۇ: ئۇ بىر ئىزدەش ئالگورىزىمى ئەمەس، ھەر ئۇچۇر مەنبەسىگە ئۆز خۇسۇسىيىتىگە ماس باشقۇرۇش بېرىش.
ئەسلەتمە تەرەپ قائىدىلىرى ئىككى ماقالە بۇرۇن تولۇق چۈشەندۈرۈلگەن. بۇ يەردە «ئىككى خىل توغرىلىق»نى ئەڭ ياخشى كۆرسىتىدىغان تۆت لايىھەنى سېلىشتۇرىمىز:
▸ زىتلىق قاپلىمايدۇ، ئورۇن بېسىپ تارىخ ساقلايدۇ. ئادەتتە يۈخاڭدا تۇرۇپ شىخۇغا بارغىنىڭىزنى ئېيتىسىز. «ھازىر قەيەردە» پەقەت بىر قىممەتلىك پاكىت، بۇ ئىككىسى زىت. كۆپ سىستېما يۈخاڭنى شىخۇغا بىۋاسىتە قايتا يازىدۇ، HexClaw يازمايدۇ: ھەر ئىككىسى كۈچكە ئىگە/قالغان ۋاقىت تامغىسى بىلەن ساقلىنىدۇ، supersede ئىشلىتىلىدۇ، پەقەت ھازىرقىسى ئەسلىتىلىدۇ. يۈخاڭغا قايتسىڭىز ئۆزى قايتىدۇ، تارىخ ھەر ۋاقىت بار. بىلىم ئامبىرى ئەسلى تېكىستىنى ئۆزگەرتىشكە بولمايدۇ، ئەسلەتمە تارىخىنى يوقىتىشقا بولمايدۇ؛ ئوخشاش ئەستايىدىللىق ئىككى سانلىق مەلۇماتتا باشقا شەكىلدە.
▸ مۇھىملىق ئۆزىنى تۈزىتىدۇ. ئەسلەتمىنىڭ مۇھىملىقى ئامبارغا كىرگەندە LLM بەرگەن مۇقىم نومۇر ئەمەس، ئەسلەنگەن HitCount چاستوتىسىغا قارىدۇ. قايتا ئىشلىتىلگەن ئەسلەتمە ئۆزى يۇقىرىغا چىقىدۇ. بىلىم ئامبىرى مەنبە بىلەن، ئەسلەتمە «لازىم بولۇش» بىلەن ئۆزىنى ئىسپاتلايدۇ.
▸ رەتلەش، يەنى «چۈش كۆرۈش» ئىككى باسقۇچلۇق. يېنىك باسقۇچ ساپ مېخانىكىلىق، نۆل LLM: تەكرار چىقىرىش، ئورۇن بېسىش، ئۆستۈرۈش/تۆۋەنلىتىش ۋە ئارخىپلاش، توقۇلما چىقىرالمايدۇ. چوڭقۇر باسقۇچلا LLM بىلەن بىرىكتۈرىدۇ، توپ چوڭلۇقى ۋە ھەر ئايلانمىدىكى توپ سانى چەكلىك. بۇ بىلىم ئامبىرىدىكى Contextual خۇلاسىسىگە خامچوت قويۇش بىلەن ئوخشاش: مودېل سانلىق مەلۇماتنى قايتا يازىدىغان ھەر يەرگە ئاۋۋال قەپەس قويۇلىدۇ.
▸ ھەممىسى يەرلىك Markdown، git diff قىلىشقا بولىدۇ. ھەر رەتلەش ھۆججەت ئۆزگىرىشى، تەكشۈرگىلى ۋە قايتۇرغىلى بولىدۇ. بۇ بىلىم ئامبىرىدىكى «جاۋاب مەنبەگە قايتالايدۇ»نىڭ ئەسلەتمە تەرەپتىكى ئەكسى: رەتلەش ھەرىكەتكە قايتالايدۇ.
بۇ تۆت لايىھە ئەسلەتمىنىڭ تەبىئىتىگە ماس: سىز ھەققىدىكى پاكىت ئۆزگىرىدۇ، خاتا ياكى ۋاقتى ئۆتكەن بولالايدۇ؛ شۇڭا ئۇنىڭ توغرىلىقى تارىخ ساقلاش ۋە ئۆزىنى تۈزىتىش. ھۆججەتنى مودېل قايتا يازماسلىقى كېرەك، شۇڭا بىلىم ئامبىرىنىڭ توغرىلىقى ئەسلى تېكىست ۋە مەنبە. ئىككى مېخانىزم قايتا قۇرۇش ئەمەس، Context Engineering نىڭ ئىككى مەنبەدە ئوخشاش «نېمىگە ئاساسەن ئىشىنىمىز؟» دېگەن سوئالغا جاۋاب بېرىشى.

بىلىم ئامبىرىنىڭ ئۆزىدىكى ۋاقىت ئۆلچىمىمۇ ئايرىم باشقۇرۇلىدۇ. ئىزدەشتىكى 30 كۈنلۈك يېرىم ئۆمۈر ئاجىزلىشىشىدىن باشقا، ئاسان نەزەردىن ساقىت بولىدىغان كىرىش بار: ۋاقىتلىق ۋەزىپە ھەر كۈنى قىزىق ئىزدەش، ئامبار يۇلتۇز سانى ياكى باھا كۆزىتىش نەتىجىسىنى بىلىم ئامبىرىغا يازىدۇ. بۇ بىر ھۆججەت ئەمەس، ۋاقىت قاتارى: بۈگۈنكى قىزىق تىزىملىك تۈنۈگۈنكىنى قاپلىماسلىقى، تۈنۈگۈنكىمۇ مەڭگۈ قالماسلىقى كېرەك. HexClaw ھەر يىغىش ھۆججىتىنىڭ ماۋزۇسىغا ۋاقىت تامغىسى قوشۇپ، ھەر ئايلانمىنى مۇستەقىل ھۆججەت قىلىدۇ. شۇنىڭ بىلەن «ئۆتكەن چارشەنبە قىزىق ئىزدەش نېمە ئىدى؟» دېگەندەك ۋاقىتلىق ئىزدەش تەبىئىي قوللىنىدۇ. ھەر قاتار سۈكۈتتىكى ھالەتتە پەقەت يېقىنقى 100 snapshot نى ساقلايدۇ، سائەتتە ئىجرا بولىدىغان ۋەزىپە بىلىم ئامبىرىنى پاتقاققا ئايلاندۇرمايدۇ. يىغىلغىنى ماتېرىيال، باشقۇرۇلغاندىن كېيىن دەلىل بولىدۇ.
ئۈچ نەشر دەرۋازىسى ۋە تېخى توردا ئىجرا زەنجىرىگە كىرمىگەنلىرى
يۇقىرىقىلار توردا ھەر سوئالدا ھەقىقەتەن ئىجرا بولىدىغان كود. ئەمما «بۇ ئېقىم ياخشىمۇ؟»نى ھېسسىيات بىلەن بېكىتكىلى بولمايدۇ. بىلىم ئامبىرى كودىدا يەنە ئۈچ باھالاش قوغدىغۇچىسى بار. ئۇلار توردا زەنجىردە ئەمەس، نەشر دەرۋازىسىدا ئىجرا بولىدۇ: ئىزدەش لوگىكىسى ئۆزگەرسە ئاۋۋال بۇ ئۈچتىن ئۆتىدۇ.
بىرىنچى: recall دەرۋازىسى. مۇقىم golden ماتېرىيال ۋە سوئال توپلىمى recall@k بىلەن MRR نى مىقدارلاشتۇرىدۇ، ھېساب پۈتۈنلەي ئېنىق. ئۇ «بۇ ئۆزگىرىش بۇرۇن تېپىلغان نەرسىنى يوقىتىپ قويدىمۇ؟» دېگەن تۆۋەن چەكنى قۇلۇپلايدۇ.
ئىككىنچى: precision دەرۋازىسى. بۇ بىۋاسىتە ماقالە تېمىسىغا قارىغان. كود ئىزاھى ئالدى بىلەن ساھەدىكى نۇقساننى كۆرسىتىدۇ: «مەۋجۇت باھالاش recall، مۇناسىۋەتلىك ھۆججەت top-k دامۇ دېگەننى ئېغىر ئالىدۇ؛ precision، top-k غا قانچىلىك مۇناسىۋەتسىز يېقىن مەنىلىك توسقۇن كىرگەنلىكىنى يېنىك ئالىدۇ». شۇڭا مەخسۇس توسقۇن ماتېرىيال قۇرۇلغان: ھەر سوئالغا ھەقىقىي مۇناسىۋەتلىك ھۆججەت، ئاندىن تېمىسى يېقىن ئەمما جاۋابى خاتا ھۆججەت قەستەن قوشۇلىدۇ. مەسىلەن بايرام بىلەن دەم ئېلىش، مۇناسىۋەتلىك سانلىق مەلۇمات ئامبىرى بىلەن cache ۋە message queue ئوخشاش ساھەگە كىرىدۇ. ئاندىن precision@k بىلەن top-k نىڭ ساپلىقى ۋە توسقۇن ئۆتۈش مىقدارى ئۆلچىنىدۇ. بۇ The Power of Noise دىكى «ئەڭ زەھەرلىك شاۋقۇن»غا نىشانلىق تەكشۈرۈش.
ئۈچىنچى: سادىقلىق دەرۋازىسى. RAGAS رامكىسىغا ماس، كۈچلۈك مودېل ھۆكۈمچى بولۇپ، سوئال، ئىزدەش context ى ۋە ھاسىل بولغان جاۋاب ئۈچلۈكىگە ئۈچ نومۇر بېرىدۇ: Faithfulness، جاۋابتىكى پاكىت بايانلىرىنىڭ قانچە نىسبىتى context تىن قوللاش تاپالايدۇ؛ AnswerRelevance، سوئالغا ماسمۇ؛ ContextRelevance، context نىڭ ئۆزى مۇناسىۋەتلىكمۇ. ھۆكۈمچى context قوللىمىدى دەپ قارىغان بايانلارمۇ بىرمۇبىر تىزىلىپ، توقۇلما گۇمانى دەلىلى قىلىنىدۇ. بۇ نومۇر سىستېمىسىدا مەن ئەڭ ياخشى كۆرىدىغان بىر لايىھە بار:
جاۋاب رەت قىلىپ، ماتېرىيال يېتەرلىك ئەمەسلىكىنى ئېيتسا ۋە ھېچقانداق پاكىت بايان قىلمىسا، Faithfulness = 1.0، تولۇق نومۇر.
بۇ سىستېمىدا «بىلمەيمەن»نى ئېتىراپ قىلىش مەغلۇبىيەت ئەمەس، سادىقلىقنىڭ ئەڭ يۇقىرى شەكلى. توقۇش نۆل نومۇر.
ئەمدى چەكلىرىنىمۇ تولۇق ئېيتاي. بىرىنچى، بۇ ئۈچ دەرۋازا نەشر دەرۋازىسى، توردا دەرۋازا ئەمەس. ھەر ھەقىقىي سوئال-جاۋابتا «بۇ قېتىمقى جاۋاب»قا سادىقلىق ھۆكۈمچىسى ئىشلىمەيدۇ. توردا زەنجىرنىڭ ئاخىرقى مۇداپىئەسى «ماتېرىيال يېتەرلىك بولمىسا راستىنى ئېيت» دېگەن prompt چەكلىمىسى. ھۆكۈمچىنى توردا زەنجىرگە يۆتكەش ھەر جاۋابقا قوشۇمچە كېچىكىش ۋە چىقىم قوشىدۇ؛ بۇ ھېساب تېخى تاماملانمىغاچقا قىلىنمىدى.
ئىككىنچى، مەنبە context تا توختايدۇ. پايدىلانما ماۋزۇسى ۋە مەنبەسى مودېلغا بېرىلگەن، ئەمما «جاۋابتىكى بۇ جۈملە قايسى پايدىلانمىدىن» دېگەن مەھسۇلاتلاشقان قايتىش، جۈملىنى چېكىپ ئەسلىگە بېرىش، تېخى يوق. ئىزدەش يۈزىدە citation-aware context builder نىڭ دەسلەپكى شەكلى بار، ئاخىرقى مەھسۇلاتلاشتۇرۇش كەم. ھازىر مەنبە مودېلغا كۆرسىتىلىدۇ، سىز تەكشۈرۈشكە تېخى ئەمەس.
ئاخىرىدا، توسقۇن ماتېرىيال يەنىلا قولدا قۇرۇلغان ۋە كىچىك. ئۇ «بۇ ئۆزگىرىش شاۋقۇنغا چىدامچانلىقنى بۇزدى» دېگەن قايتىشنى توسالايدۇ، ئەمما «سىزنىڭ ھەقىقىي ماتېرىيالىڭىزدا شاۋقۇنغا چىداملىق» دېگەننى ئىسپاتلاشقا تېخى يىراق. بۇ ماتېرىيال داۋاملىق بېقىلىشى كېرەك. يەنە بىر ھېساب: ماقالىدىكى 49% ۋە 67% Anthropic نىڭ ئۆز ماتېرىيالىدىكى نەتىجە؛ HexClaw نىڭ بۇ زەنجىرىدە تېخى سىرتقا نەقىل قىلىدىغان ئۆز سىناق سېلىشتۇرما سانى يوق. بوش قالدۇرغاندىن بۇنى ئېتىراپ قىلىش ياخشى.
چەكلەر ئېيتىلدى. ئەمدى بارلىق تاللاشنى بىر قوبۇل قىلىش تىزىملىكىگە يىغايلى. HexClaw ئىشلىتىڭ ياكى ئىشلىتىمەڭ، RAG قۇرغاندا بىرمۇبىر سېلىشتۇرالايسىز:
□ 2 پەقەت ۋېكتور ساقلاپ ئەسلىنى ساقلىماسلىق نەقىل، قايتا ئىندېكسلاش ۋە تەكشۈرۈشتىن تەڭ ۋاز كېچىش.
□ 3 (doc_id, chunk_index) غا بىردىنبىرلىك شەرتى قوشۇڭ، قايتا كىرگۈزۈش ۋە قايتا ئىندېكسلاش سايە تەكرار ھاسىل قىلمىسۇن.
□ 4 سۈزۈش topK دىن بۇرۇن كۈچكە ئىگە بولسۇن، بولمىسا ھەقىقىي ماسلىق نامزات كۆلچىكىدىن جىمجىت سىقىپ چىقىرىلىدۇ.
□ 5 BM25 ۋە ۋېكتور نومۇرىنىڭ ئۆلچىمى سېلىشتۇرۇلمايدۇ؛ بىۋاسىتە قوشماڭ، ئاۋۋال نورماللاشتۇرۇڭ ياكى RRF ئىشلىتىڭ.
□ 6 مۇناسىۋەت تۆۋەن چېكى پەقەت «ساپ ئاجىز ۋېكتور ماسلىقى»نى كەسسۇن، ئاچقۇچلۇق سۆز ماسلىقىنى خاتا ئۆچۈرمىسۇن؛ ھەممىسى كېسىلسە شەرت يۇمشىتىلىپ قايتۇرۇلسۇن.
□ 7 قايتا رەتلەش زاپىسىدا كەم دېگەندە MMR بولسۇن، يېقىن تەكرار chunk لار topK نى تولدۇرمىسۇن.
□ 8 پەقەت recall ئۆلچىمەڭ؛ top-k غا قانچىلىك «تېمىسى يېقىن توسقۇن» كىرگەنلىكىنى مەخسۇس ماتېرىيال بىلەن ئۆلچەڭ.
Loop قا قايتىش: تاللاش ھوقۇقىنى تەكشۈرگىلى بولىدىغان ئېقىمغا بېرىش
ئالدىنقى ماقالە تۆت ئەندىزىنى كونترول يۈزىنىڭ سىرتقا كېڭىيىشى دەپ ئېيتقان. ھەر بىر قاتلام سىرتقا كېڭەيگەندە بىر قاتلام قارار ھوقۇقىنى بېرىسىز. Context قاتلىمىدا بېرىدىغىنىڭىز ئۇچۇر تاللاش ھوقۇقى: مودېل ھەر ئايلانمىدا نېمىنى كۆرىدۇ، نېمىنى كۆرمەيدۇ، ئەمدى ھەممىسىنى ئۆزىڭىز بىرمۇبىر باشقۇرمايسىز.
بۇ ماقالىدىن كېيىن ئۇ گەپنىڭ داۋامىنى قوشالايمىز: ھوقۇق بېرىشكە بولىدۇ، ئەمما نېمىگە بەرگەنلىكىڭىزنى كۆرۈڭ. «پۈتۈن ئامبارنى كۆزنەككە تىقىش»قا بېرىش بىلىشتىكى ئاسانچىلىق؛ ھەر جەرياننىڭ سەۋەبى، تۇراقلىق قىممىتى، تۆۋەنلەش يولى ۋە نەشر دەرۋازىسى بار ئېقىمغا بېرىشلا ئىنژېنېرلىق. ئىزدەش خاتالىقى Loop دا قوشۇلما ئۆسۈم؛ ئەكسىمۇ توغرا، شاۋقۇن توسقان ھەر دەرۋازا Loop دا ئوخشاش كۆپىيىدىغان پايدا.
بۇ ئېقىمدا ساھەدىن ئۆگەنگەنلىرى بىلەن ئۆزىمىز قىلغان ئىشلار ئېنىق ئايرىلىدۇ: Contextual Retrieval، RRF، HyDE ۋە RAGAS ئاشكارا ئەمەلىيەتنىڭ مۈرىسىدە تۇرۇش. نومۇر ئېغىرلىقى قوشۇلغان RRF تۈزىتىشى، CJK bigram بىلەن LIKE نىڭ ئىككى قەۋەت سۆزلۈك زاپىسى، «رەت جاۋاب = تولۇق نومۇر» لايىھىسى، ۋاقىتلىق يىغىشقا ۋاقىت قاتارى snapshot باشقۇرۇشى، ئەسلەتمىدىكى تارىخ ساقلاپ ئورۇن بېسىش ۋە ئىككى باسقۇچلۇق چۈش كۆرۈش بولسا بۇ سىستېما ئۆزى ئازگالغا چۈشۈپ تاپقان ئۇسۇللار. ئىنژېنېرلىقنىڭ پەرقلەندۈرۈش كۈچى يېڭى ئەندىزە كەشىپ قىلىشتا ئەمەس، ھەر تاللاشنىڭ نېمىشقىسىنى ئېيتالايدىغانلىقتا.
تۆت ئەندىزىدىن يەنە ئىككى قاتلام قالدى. كېيىنكى ماقالە Harness ھەققىدە. لۇغەتتىن قارىسىڭىز، بۇ سۆزنىڭ ئەسلى مەنىسى مالغا تاقىلىدىغان جابدۇق؛ بۇ يۈرۈشلۈكتە Agent نى «تور ئىش كۈچى» دەپ ئاتىغان ماقالىمۇ بار. بۇ تاسادىپىي ئەمەس، كېيىنكى ماقالىنىڭ ئۆزىكى: ئەقىلنى مودېل بېرىدۇ، ئىشقا قويۇش جۈرئىتىنى جابدۇق بېرىدۇ. بۇ گەپنى ھازىر مۇشۇ يەردە قويۇپ، كېيىنكىدە ئەمەلىيلەشتۈرىمىز. Prompt ماقالىسى ئاخىرىدا تاماملايدۇ.
تۆت ئەندىزە يۈرۈشلۈكى
▸ Loop، ئاساسىي ماقالە ئوچۇق كودلۇق Agent نىڭ كودىنى ئېچىپ، Prompt تىن Loop قىچە تۆت ئەندىزىنى قاتلاممۇقاتلام سېلىشتۇرۇش
▸ Context، ئەسلەتمە تەرەپ چۈش كۆرىدىغان Agent ئەسلەتمىسى: HexClaw ئۆز كومپيۇتېرىڭىزدا چۈش كۆرىدۇ
▸ Harness، كېيىنكى ماقالە «تور ئىش كۈچى»نىڭ ئەقىللىقى مودېلدىن، ئىشقا قويۇش جۈرئىتى «جابدۇق»تىن، يېزىلىۋاتىدۇ
باشقا ماقالىلەر
▸ HexClaw نىڭ «تور ئىش كۈچى»: بىر جۈملىنى ئۆزلۈكىدىن ئەسلىگە كېلىدىغان sandbox سكرىپتىغا تۈزۈش
▸ HexClaw AI ئارقىسىدىكى Claude Code SOP: لايىھە يېتەكچىلىكى، سىناق يېپىق ھالقىسى ۋە كۆپ Agent ھەمكارلىقى
پايدىلانغان مەنبەلەر
· Andrej Karpathy، X، 2025-06، «context engineering» ئاتالغۇسىغا ئاشكارا قوللاش
· Tobi Lütke، X، 2025-06، context engineering ئېنىقلىمىسى
· Anthropic، AI Agent ئۈچۈن ئۈنۈملۈك context engineering، 2025-09
· Anthropic، Contextual Retrieval نى تونۇشتۇرۇش، 2024-09
· Chroma Research، Context Rot: كىرگۈزۈش token ى كۆپىيىشى LLM ئىپادىسىگە قانداق تەسىر قىلىدۇ؟، 2025-07
· Cormack، Clarke ۋە Buettcher، Reciprocal Rank Fusion، SIGIR 2009
· Cuconasu قاتارلىقلار، The Power of Noise: RAG سىستېمىسى ئۈچۈن ئىزدەشنى قايتا ئېنىقلاش، SIGIR 2024
· Liu قاتارلىقلار، Lost in the Middle: تىل مودېللىرى ئۇزۇن context نى قانداق ئىشلىتىدۇ؟، TACL 2024
· Gao قاتارلىقلار، مۇناسىۋەت بەلگىسىز ئېنىق zero-shot زىچ ئىزدەش، HyDE، 2022
· Es قاتارلىقلار، RAGAS: ئىزدەش كۈچەيتىلگەن ھاسىل قىلىشنى ئاپتوماتىك باھالاش، 2023
· ماقالىدىكى بارلىق HexClaw مېخانىزم ۋە تۇراقلىق قىممىتى 2026-07-02 كۈنى ئامبارنىڭ main شاخچىسىغا قاراپ تەكشۈرۈلگەن.