ಹೆಚ್ಚಿನ ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡಗಳು retrieval-augmented generation (RAG) ವಿಷಯದಲ್ಲಿ ಒಂದೇ ರೀತಿಯ ಅಡೆತಡೆಗಳನ್ನು ಎದುರಿಸುತ್ತವೆ. ಅವರು ಟ್ಯುಟೋರಿಯಲ್ ಪ್ಲೇಬುಕ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತಾರೆ: ದಾಖಲೆಗಳನ್ನು 512 ಅಥವಾ 1024 ಟೋಕನ್ಗಳ ನಿಗದಿತ ಚಂಕ್ಗಳಾಗಿ (fixed chunks) ವಿಂಗಡಿಸುವುದು, ಅವುಗಳನ್ನು ಒಂದೇ ಎಂಬೆಡ್ಡಿಂಗ್ ಮಾಡೆಲ್ ಮೂಲಕ ಕಳುಹಿಸುವುದು ಮತ್ತು ಸರಳ top-k ಲುಕ್ಅಪ್ನೊಂದಿಗೆ ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬಳಸುವುದು. ಒಂದು ಸ್ಲೈಡ್ ಡೆಕ್ನಲ್ಲಿ ಇದು ಸರಿಯಾಗಿ ಕಾಣಿಸಬಹುದು, ಆದರೆ ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಇದು ವಿಫಲವಾಗುತ್ತದೆ.
ನಿಗದಿತ ಚಂಕ್ಗಳಿಗೆ ವಿಷಯದ (content) ಬಗ್ಗೆ ಕಾಳಜಿಯಿಲ್ಲ. ಅವು ಕಾನೂನು ಒಪ್ಪಂದವನ್ನು (legal contract) ವಾಕ್ಯದ ಮಧ್ಯದಲ್ಲೇ ವಿಭಜಿಸಬಹುದು, ಇದರಿಂದ ಹೊಣೆಗಾರಿಕೆಯ ಕಲೌಸ್ಗಳು (liability clauses) ಸಂಬಂಧವಿಲ್ಲದ ಎರಡು ಪಠ್ಯದ ಭಾಗಗಳ ನಡುವೆ ಅತಂತ್ರವಾಗಿ ಉಳಿಯುತ್ತವೆ. ಇಡೀ API ಎಂಡ್ಪಾಯಿಂಟ್ ವಿವರಣೆಯನ್ನು ಒಂದೇ ದೊಡ್ಡ ಚಂಕ್ನಲ್ಲಿ ಹಾಕಬಹುದು, ಇದರಿಂದ ಬಳಕೆದಾರರು ಕೇಳಿದ ನಿರ್ದಿಷ್ಟ ಪ್ಯಾರಾಮೀಟರ್ ಶಬ್ದಗಳ ಗದ್ದಲದಲ್ಲಿ ಕಳೆದುಹೋಗಬಹುದು. ಮತ್ತು ರಿಟ್ರಿವಲ್ (retrieval) ನಿಧಾನವಾದಾಗ, ಪ್ರತಿ ಮಿಲಿಸೆಕೆಂಡ್ನ ವಿಳಂಬವು (latency) ನೇರವಾಗಿ ಬಳಕೆದಾರರ ಅನುಭವದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ನಾವು ಇದನ್ನು ಕಷ್ಟಪಟ್ಟು ಕಲಿತೆವು. ನಂತರ ನಾವು ನಮ್ಮ ರಿಟ್ರಿವಲ್ ಲೇಯರ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಿ ಮರುನಿರ್ಮಿಸಿದೆವು. ನಮ್ಮ recall at ten ಶೇ. 78 ರಿಂದ ಶೇ. 95 ಕ್ಕೆ ಏರಿತು. ವಿಳಂಬವು (latency) ಹೆಚ್ಚಾಗಲಿಲ್ಲ, ಬದಲಾಗಿ ಅದು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆಯಾಯಿತು.
ಕಾಪಿ-ಪೇಸ್ಟ್ RAG ನಲ್ಲಿರುವ ಸಮಸ್ಯೆ
ಪ್ರಮಾಣಿತ RAG ಸ್ಟ್ಯಾಕ್ ಒಂದು ರೀತಿಯ ಡಿಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್ ಆಗಿಬಿಟ್ಟಿದೆ. ಸಣ್ಣ ಚಂಕ್ಗಳು, ಒಂದು ಎಂಬೆಡ್ಡಿಂಗ್ ಮಾಡೆಲ್, ವೆಕ್ಟರ್ ಸರ್ಚ್ - ಅಷ್ಟೇ. ಈ ವಿಧಾನವು ಡೆಮೋಗಳಲ್ಲಿ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ ಏಕೆಂದರೆ ಡೆಮೋಗಳಲ್ಲಿ ಸ್ಪಷ್ಟವಾದ ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ವ್ಯವಸ್ಥಿತವಾದ ದಾಖಲೆಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಆದರೆ ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾ ಎಂದಿಗೂ ವ್ಯವಸ್ಥಿತವಾಗಿರುವುದಿಲ್ಲ.
ಕಾನೂನು ದಾಖಲೆಗಳು ಶ್ರೇಣೀಕೃತ ರಚನೆಯನ್ನು (hierarchical structure) ಹೊಂದಿರುತ್ತವೆ. ವಿಭಾಗಗಳು (sections) ಉಪ-ವಿಭಾಗಗಳನ್ನು (subsections) ಹೊಂದಿರುತ್ತವೆ, ಉಪ-ವಿಭಾಗಗಳು ಕಲೌಸ್ಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಇವುಗಳನ್ನು ಕೇವಲ ಟೋಕನ್ ಕೌಂಟರ್ ಬಳಸಿ ಕತ್ತರಿಸಿದರೆ, ಮಾಡೆಲ್ ತರ್ಕಿಸಲು ಅಗತ್ಯವಿರುವ ಸಂಬಂಧಗಳನ್ನೇ ನೀವು ನಾಶಪಡಿಸಿದಂತೆ. API ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಕೂಡ ಒಂದು ರಚನೆಯನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ಅದು ವಿಭಿನ್ನವಾಗಿದೆ. ಒಂದು ಫಂಕ್ಷನ್ ಸಿಗ್ನೇಚರ್, ಅದರ ಪ್ಯಾರಾಮೀಟರ್ಗಳು, ಅದರ ರಿಟರ್ನ್ ವ್ಯಾಲ್ಯೂ ಮತ್ತು ಒಂದು ಉದಾಹರಣೆಯು ಒಂದು ತಾರ್ಕಿಕ ಘಟಕವನ್ನು (logical unit) ರೂಪಿಸುತ್ತವೆ. ಇದನ್ನು ನಿಗದಿತ ಟೋಕನ್ ವಿಂಡೋಗೆ ಒತ್ತಾಯ的に ತಳ್ಳಿದರೆ, ನೀವು ಉದಾಹರಣೆಯನ್ನು ಅರ್ಧಕ್ಕೆ ಕತ್ತರಿಸುತ್ತೀರಿ ಅಥವಾ ಚಂಕ್ ಅನ್ನು ಸಂಬಂಧವಿಲ್ಲದ ಫಂಕ್ಷನ್ಗಳಿಂದ ತುಂಬುತ್ತೀರಿ. ಸಪೋರ್ಟ್ ಟಿಕೆಟ್ಗಳು ಗೊಂದಲಮಯವಾಗಿರುತ್ತವೆ, ಸಂಭಾಷಣಾತ್ಮಕವಾಗಿರುತ್ತವೆ ಮತ್ತು ವಿಷಯದ ದಿಕ್ಕಿನ ಬದಲಾವಣೆಗಳಿಂದ ಕೂಡಿರುತ್ತವೆ. ವಿಕಿ ಪುಟಗಳು ವಿಸ್ತಾರವಾಗಿರುತ್ತವೆ ಮತ್ತು ಪರಸ್ಪರ ಉಲ್ಲೇಖಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಒಂದೇ ಚಂಕಿಂಗ್ ತಂತ್ರವು ಇವೆಲ್ಲವನ್ನೂ ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದರೂ ತಂಡಗಳು ಅಂತಹದ್ದನ್ನೇ ಬಳಸುತ್ತವೆ. ಅದು ಸಾಧ್ಯ ಎಂದು ನಂಬುವುದನ್ನು ನಾವು ನಿಲ್ಲಿಸಿದೆವು.
ಕಾರ್ಯತಂತ್ರದ ಚಂಕಿಂಗ್: ವಿಧಾನವನ್ನು ವಿಷಯಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಹೊಂದಿಸಿ
ನಾವು ಕಂಟೆಂಟ್-ಅವೇರ್ ಚಂಕಿಂಗ್ (content-aware chunking) ಗೆ ಬದಲಾಯಿಸಿದೆವು. ಕಾನೂನು ದಾಖಲೆಗಳಿಗಾಗಿ, ನಾವು ದಾಖಲೆಯ ಶ್ರೇಣೀಕೃತ ರಚನೆಯನ್ನು ಗೌರವಿಸುವ 'ರಿಕರ್ಸಿವ್ ಚಂಕಿಂಗ್' (recursive chunking) ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಇದು ಕಲೌಸ್ಗಳನ್ನು ಅಖಂಡವಾಗಿಡುತ್ತದೆ ಮತ್ತು ವಿಭಾಗಗಳ ನಡುವಿನ ಪೇರೆಂಟ್-ಚೈಲ್ಡ್ ಸಂಬಂಧಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. API ಡಾಕ್ಯುಮೆಂಟೇಶನ್ಗಾಗಿ, ನಾವು ಪ್ರತಿಯೊಂದು ಫಂಕ್ಷನ್ ಅಥವಾ ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು ಒಂದು ಗಡಿ ಎಂದು ಪರಿಗಣಿಸುವ 'ಫಂಕ್ಷನ್-ಅವೇರ್ ಚಂಕಿಂಗ್' ಅನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ. ಒಂದು ಪ್ಯಾರಾಮೀಟರ್ ವಿವರಣೆ ಉದ್ದವಾಗಿದ್ದರೆ, ಚಂಕ್ ಆ ಫಂಕ್ಷನ್ ಸುತ್ತ ವಿಸ್ತರಿಸುತ್ತದೆ, ಟೋಕನ್ ಮಿತಿಯ ಸುತ್ತ ಅಲ್ಲ. ಸಪೋರ್ಟ್ ಟಿಕೆಟ್ಗಳಿಗಾಗಿ, ನೈಸರ್ಗಿಕ ವಿಷಯದ ಗಡಿಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವ 'ಸೆಮ್ಯಾಂಟಿಕ್ ಚಂಕಿಂಗ್' ಅನ್ನು ನಾವು ಬಳಸುತ್ತೇವೆ. ಗ್ರಾಹಕರು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಬಿಲ್ಲಿಂಗ್ ದೂರುವಿನಿಂದ ತಾಂತ್ರಿಕ ದೋಷಕ್ಕೆ ಬದಲಾದಾಗ, ವಿಭಜನೆಯು ಆ ತಿರುವಿನಲ್ಲೇ ನಡೆಯುತ್ತದೆ. ವಿಕಿಗಳು ಮತ್ತು ಅಸಂಘಟಿತ ಜ್ಞಾನ ಕೋಶಗಳಿಗಾಗಿ (unstructured knowledge bases), ನಾವು 'ಏಜೆಂಟಿಕ್ ಚಂಕಿಂಗ್' ಅನ್ನು ಬಳಸುತ್ತೇವೆ, ಅಲ್ಲಿ ಲೈಟ್ವೇಟ್ LLM ಪಠ್ಯವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ ಅರ್ಥಪೂರ್ಣ ಗಡಿ ಎಲ್ಲಿರಬೇಕು ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಇದು ಕ್ಯಾರೆಕ್ಟರ್ ಸ್ಪ್ಲಿಟ್ (character split) ಗಿಂತ ಹೊಂದಿಸಲು ನಿಧಾನವಾಗಿದೆ, ಆದರೆ ಇದು ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುವ ರಿಟ್ರಿವಲ್ ಮತ್ತು ಕೇವಲ ಊಹಿಸುವ ರಿಟ್ರಿವಲ್ ನಡುವಿನ ವ್ಯತ್ಯಾಸವಾಗಿದೆ.
ಹೈಬ್ರಿಡ್ ರಿಟ್ರಿವಲ್: ವೆಕ್ಟರ್ ಸರ್ಚ್ ಮಾತ್ರ ಏಕೆ ಸಾಕಾಗುವುದಿಲ್ಲ
ವೆಕ್ಟರ್ ಸರ್ಚ್ ಅರ್ಥವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಅದು ನಿಖರವಾದ ಹೊಂದಾಣಿಕೆಗಳನ್ನು (exact matches) ತಪ್ಪಿಸಬಹುದು. ಬಳಕೆದಾರರು ERR_CONNECTION_RESET_0x5F3 ನಂತಹ ಎರರ್ ಕೋಡ್ ಅನ್ನು ಪೇಸ್ಟ್ ಮಾಡಿದರೆ, ಸೆಮ್ಯಾಂಟಿಕ್ ಸಾಮ್ಯತೆಯು (semantic similarity) ಕೇವಲ ಸಾಮಾನ್ಯ ನೆಟ್ವರ್ಕ್ ದೋಷಗಳ ಬಗ್ಗೆ ಚರ್ಚಿಸುವ ಪ್ಯಾರಾಗ್ರಾಫ್ಗಳಿಗೆ ಹೆಚ್ಚಿನ ರ್ಯಾಂಕ್ ನೀಡಬಹುದು. ಇನ್ನೊಂದೆಡೆ, BM25 ನಿಖರವಾದ ಸ್ಟ್ರಿಂಗ್ಗಳನ್ನು ಹುಡುಕುತ್ತದೆ ಆದರೆ ಪರಿಕಲ್ಪನಾ ಸಂಬಂಧವನ್ನು (conceptual relatedness) ತಪ್ಪಿಸಿಕೊಳ್ಳುತ್ತದೆ. ನಿಮಗೆ ಇವೆರಡೂ ಬೇಕು.
ನಾವು ವೆಕ್ಟರ್ ಸರ್ಚ್ ಮತ್ತು BM25 ಅನ್ನು ಸಮಾಂತರವಾಗಿ (in parallel) ನಡೆಸುತ್ತೇವೆ. ನಂತರ ನಾವು ಫಲಿತಾಂಶಗಳನ್ನು Reciprocal Rank Fusion ಅಥವಾ RRF ಮೂಲಕ ಸಂಯೋಜಿಸುತ್ತೇವೆ, ಇದು ಎರಡು ವಿಭಿನ್ನ ಸರ್ಚ್ ಸ್ಪೇಸ್ಗಳಿಂದ ಬಂದ ಸ್ಕೋರ್ಗಳನ್ನು ಒಂದೇ ಸ್ಕೇಲ್ಗೆ ತರದೆ ನಾರ್ಮಲೈಸ್ ಮಾಡುತ್ತದೆ. ಫ್ಯೂಷನ್ ನಂತರ, ನಾವು ಟಾಪ್ ಅಭ್ಯರ್ಥಿಗಳನ್ನು cross-encoder reranker ಮೂಲಕ ಕಳುಹಿಸುತ್ತೇವೆ. ಇದು ಸ್ವಲ್ಪ ವಿಳಂಬವನ್ನು (latency) ಹೆಚ್ಚಿಸುತ್ತದೆ, ಆದರೆ ನಿಖರತೆಯಲ್ಲಿ (precision) ಸಿಗುವ ಲಾಭ ಗಮನಾರ್ಹವಾಗಿದೆ. reranker ಎಂಬುದು ಕ್ವೇರಿ ಮತ್ತು ಪ್ರತಿಯೊಂದು ಅಭ್ಯರ್ಥಿಯನ್ನು ಒಟ್ಟಿಗೆ ಓದುತ್ತದೆ ಮತ್ತು ಆರಂಭಿಕ ಎಂಬೆಡ್ಡಿಂಗ್ನ cosine similarity ಗಿಂತ ಹೆಚ್ಚು ನಿಖರವಾದ ಸಂಬಂಧದ ಸ್ಕೋರ್ ಅನ್ನು ನೀಡುತ್ತದೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಈ ಸಂಯೋಜನೆಯು ಕೇವಲ ವೆಕ್ಟರ್ ಸರ್ಚ್ ತಪ್ಪಿಸುವ ನಿಖರವಾದ ಎರರ್ ಕೋಡ್ಗಳನ್ನು ಹಿಡಿಯುತ್ತದೆ ಮತ್ತು ಕೀವರ್ಡ್ ಸರ್ಚ್ ನಿರ್ಲಕ್ಷಿಸುವ ಪರಿಕಲ್ಪನಾ ಸಂಬಂಧಿತ ಟ್ರಬಲ್ಶೂಟಿಂಗ್ ಹಂತಗಳನ್ನು ಎತ್ತಿ ತೋರಿಸುತ್ತದೆ.
ಕ್ವೇರಿ ಎಕ್ಸ್ಪ್ಯಾನ್ಶನ್: ಇಂಡೆಕ್ಸ್ ತಲುಪುವ ಮುನ್ನ ಬಳಕೆದಾರರ ಇನ್ಪುಟ್ ಅನ್ನು ಸರಿಪಡಿಸುವುದು
ಬಳಕೆದಾರರು ಪರಿಪೂರ್ಣವಾದ ಸರ್ಚ್ ಕ್ವೇರಿಗಳನ್ನು ಬರೆಯುವುದಿಲ್ಲ. ಅವರು "ನನ್ನ ಕೊನೆಯ ಡಿಪ್ಲಾಯ್ ಏಕೆ ವಿಫಲವಾಯಿತು ಮತ್ತು ಅದನ್ನು ನಾನು ಹೇಗೆ ರೋಲ್ ಬ್ಯಾಕ್ ಮಾಡುವುದು?" ಎಂಬಂತಹ ಮಲ್ಟಿ-ಹೋಪ್ (multi-hop) ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುತ್ತಾರೆ, ಇದಕ್ಕೆ ಎರಡು ಪ್ರತ್ಯೇಕ ಜ್ಞಾನದ ಮೂಲಗಳನ್ನು ಹುಡುಕಿ ಅವುಗಳನ್ನು ಸಂಪರ್ಕಿಸಬೇಕಾಗುತ್ತದೆ. ಅಥವಾ ಅವರು ಇಂಡೆಕ್ಸ್ಗೆ ಸರಿಯಾಗಿ ಹೊಂದಿಕೆಯಾಗದ ಅಸ್ಪಷ್ಟ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುತ್ತಾರೆ.
ನಾವು ಹುಡುಕುವ ಮೊದಲು ಪ್ರಶ್ನೆಗಳನ್ನು (queries) ಪರಿವರ್ತಿಸುತ್ತೇವೆ. ಮಲ್ಟಿ-ಹೋಪ್ (multi-hop) ಪ್ರಶ್ನೆಯನ್ನು ಉಪ-ಪ್ರಶ್ನೆಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗುತ್ತದೆ. ಅಸ್ಪಷ್ಟ ಉದ್ದೇಶವನ್ನು ಹಲವಾರು ನಿರ್ದಿಷ್ಟ ಹುಡುಕಾಟದ ಪ್ರಶ್ನೆಗಳಾಗಿ ವಿಸ್ತರಿಸಲಾಗುತ್ತದೆ. ಒಬ್ಬ ಬಳಕೆದಾರರ ಒಂದು ಪ್ರಶ್ನೆಯನ್ನು ಐದು ವಿಭಿನ್ನ ಹುಡುಕಾಟದ ಪ್ರಶ್ನೆಗಳಾಗಿ ವಿಸ್ತರಿಸುವುದರಿಂದ ರಿಕಾಲ್ (recall) ಶೇ. 78 ರಿಂದ ಶೇ. 96 ಕ್ಕೆ ಏರಬಹುದು ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ಇದು LLM ಗೆ ಕಠಿಣವಾಗಿ ಪ್ರಾಂಪ್ಟ್ (prompt) ನೀಡುವುದರ ಬಗ್ಗೆ ಅಲ್ಲ. ಇದು ರಿಟ್ರಿವಲ್ ಸಿಸ್ಟಮ್ಗೆ (retrieval system) ಸರಿಯಾದ ಸಂದರ್ಭವನ್ನು (context) ಹುಡುಕಲು ಹೆಚ್ಚಿನ ಅವಕಾಶಗಳನ್ನು ನೀಡುವುದರ ಬಗ್ಗೆ ಆಗಿದೆ. ಪ್ರತಿಯೊಂದು ಸೃಷ್ಟಿಸಿದ ಪ್ರಶ್ನೆಯು ವಿಭಿನ್ನ ಕೋನ ಅಥವಾ ತಾಂತ್ರಿಕ ಪದವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಮತ್ತು ವಿಲೀನಗೊಳಿಸಿದ ಫಲಿತಾಂಶಗಳು ಸಂಪೂರ್ಣ ಚಿತ್ರಣವನ್ನು ನೀಡುತ್ತವೆ.
Bayesian Optimization: ಊಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ
ನೀವು ಹಲವಾರು ಚಂಕಿಂಗ್ ತಂತ್ರಗಳು (chunking strategies), ಹೈಬ್ರಿಡ್ ರಿಟ್ರಿವಲ್ (hybrid retrieval) ಮತ್ತು ಕ್ವೇರಿ ಎಕ್ಸ್ಪಾನ್ಶನ್ (query expansion) ಹೊಂದಿದ ನಂತರ, ನೀವು ಹೊಸ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸುತ್ತೀರಿ. ಇಲ್ಲಿ ನಿಯಂತ್ರಿಸಲು ಅತಿಯಾದ ಆಯ್ಕೆಗಳಿವೆ (knobs). ಚಂಕ್ ಸೈಜ್ (Chunk size), ಓವರ್ಲ್ಯಾಪ್ ಶೇಕಡಾವಾರು (overlap percentage), ವೆಕ್ಟರ್ ತೂಕ ಮತ್ತು BM25 ತೂಕದ ನಡುವಿನ ವ್ಯತ್ಯಾಸ, ರೀರಾಂಕಿಂಗ್ ಮಿತಿಗಳು (reranking thresholds) ಮತ್ತು top-k ಮೌಲ್ಯಗಳು ಎಲ್ಲವೂ nonlinear ರೀತಿಯಲ್ಲಿ ಪರಸ್ಪರ ಸಂಬಂಧ ಹೊಂದಿವೆ. ಮ್ಯಾನುಯಲ್ ಟ್ಯೂನಿಂಗ್ (Manual tuning) ಒಂದು ಊಹಾಪೋಹದ ಆಟವಾಗುತ್ತದೆ.
ನಾವು ಊಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದೆವು. ನಾವು...