Семантичният кеш пести LLM заявки — TTL пази от остарели отговори

Семантичният кеш връща готов отговор при достатъчно сходен въпрос и така спестява нова заявка към LLM. Документацията на Redis описва запис, който съхранява въпроса, векторното му представяне, целия отговор и метаданни за контекста. Ползата идва от пропуснатото генериране; коректността зависи от това дали готовият отговор още важи за новия въпрос.

Използвайте точен кеш за еднакви заявки, семантичен кеш за перифрази с един и същ отговор и пропускайте кеша на целия отговор, когато резултатът зависи от текущо състояние. Прагът на сходство ограничава приеманите перифрази, филтрите отделят потребители и версии, а TTL задава срок на съхранение. Тези проверки решават различни проблеми и трябва да се прилагат заедно.

Кой отговор изобщо допуска повторно използване

Първият въпрос е дали приложението би дало един и същ отговор при един и същ контекст. При напълно еднакъв вход точният кеш търси по ключ и не изисква векторно сравнение. Ключът обаче трябва да включва и параметрите, които променят резултата: например езика, инструкциите към модела и версията на използваните знания. Съвпадението на потребителския текст само по себе си не е достатъчно.

Семантичният кеш е подходящ за устойчиви отговори, задавани с различни думи. Условен пример са „Как да върна поръчка?“ и „Каква е процедурата за връщане на поръчка?“, ако и двата въпроса се отнасят до едни и същи публикувани условия. Отговор за статуса на конкретна поръчка има друга граница: двама клиенти могат да зададат почти еднакъв въпрос, но да се нуждаят от различни данни.

При текуща наличност, последно плащане или друго бързо променящо се състояние обикновено е по-разумно да се извика приложението и моделът отново. Ако отговорът смесва устойчиво обяснение с актуална стойност, може да се кешира само устойчивата стъпка. Така промяната в текущите данни няма да остави привидно завършен, но неверен отговор в кеша.

Прагът трябва да различава перифраза от нов въпрос

Векторната близост посочва възможен запис за повторно използване, но не доказва равнозначност. Изследване за семантичното кеширане разглежда цената на несъответствието между нова заявка и вече съхранен отговор. За едно приложение тази цена може да бъде погрешна инструкция или отговор, който е верен само при различни условия.

Настройте прага с двойки въпроси от реалното натоварване. Едните трябва да могат да споделят отговор; другите трябва да останат разделени въпреки близките си формулировки. Включете отрицание, сменен период, число, продукт и действие. Например „Мога ли да отменя поръчката?“ и „Не мога да отменя поръчката — какво следва?“ са по една тема, но искат различни отговори.

Изберете праг, при който опасните двойки не стават попадения, и измерете колко полезни перифрази остават извън кеша. По-строгият праг води до повече нови LLM заявки; по-свободният допуска повече кандидати, включително грешни. Не пренасяйте числова стойност между различни модели за векторно представяне или групи въпроси без повторна проверка: разпределението на разстоянията може да се промени.

Потребителят и версиите определят къде да се търси

Определете допустимите записи преди избора на най-близкия въпрос. За персонален отговор идентификаторът на потребителя или организацията трябва да участва в ключа или във филтъра при запис и търсене. При общодостъпни отговори може да няма потребителска граница, но езикът, версията на модела и системните инструкции пак могат да променят отговора.

Версията на базата знания е отделна граница. Ако условията за връщане се променят, стар запис не бива да отговаря на заявки към новата версия, дори формулировката да е същата. Версия или хеш на извлечените данни може да отдели тези записи. Ако приложението използва инструменти или правила за форматиране, включете и онези от тях, които влияят върху крайния отговор.

Филтрирането след векторното търсене е лош ред на операциите. Най-близкият запис в общ индекс може да принадлежи на друг потребител и да измести допустимия кандидат. Търсенето трябва да обхваща само записите в правилната потребителска, езикова и версионна група; проверка след намирането на резултат не замества тази граница.

TTL ограничава остаряването, но следете възрастта на записа

Задайте TTL според валидността на информацията, която стои зад отговора. Ръководството за RedisVL SemanticCache показва праг за векторно разстояние, TTL и филтър по потребител; то уточнява, че успешно търсене с check() подновява TTL на всички намерени записи. При такава настройка често използван отговор може да остане наличен дълго след създаването си.

Ако правилото е „отговорът да не е по-стар от допустимата възраст“, плъзгащият се TTL не изпълнява сам това условие. Запазете момента на създаване и проверявайте възрастта при попадение. Когато приложението знае, че базата знания е обновена, сменете версията ѝ в ключа или филтъра и обезсилете старите записи. Това прекъсва използването им при самата промяна, вместо да се чака изтичането на срока.

Един общ TTL е удобен, но често е неточен. Обяснение от стабилна документация и отговор от обновяван каталог имат различен полезен живот. Дори кратък срок оставя прозорец между промяната на данните и изтичането на записа. Когато няма надежден срок или събитие за обезсилване, не съхранявайте завършения отговор.

Редът на проверките определя резултата

При нова заявка първо решете дали типът отговор допуска кеширане. Изградете ключа и филтрите за потребител, език и версии, после потърсете точно съвпадение. Ако няма такова, сравнете по смисъл само допустимите записи. Върнете кандидат единствено ако преминава прага и проверката за възраст; иначе извикайте LLM и съхранете новия отговор с нужния контекст.

Измервайте точните и семантичните попадения поотделно, заедно с избегнатите LLM заявки и забавянето. Преглеждайте и случаите, в които сходен въпрос е получил неправилен стар отговор: високият дял попадения сам по себе си не показва дали кешът върши правилната работа. Именно тези случаи дават основание да промените прага, границите на търсене или срока на валидност.

Прочетете също:

• Perplexity срещу ChatGPT: повече източници не значи по-точен отговор